日本人唯一のGitLab Core Teamの @tnir です。GitLab.JP/GitLab Tokyoオーガナイザとして日本語圏でのマーケティングも注力しています。
統合開発ツールチェイン環境GitLab CE 10.7が2018年4月22日にリリースされました 
↑背景画像は東京のサクラの写真でした。東京のGitLabユーザにとっては少しシーズン外れだったかもしれません 
GitLabには、大きく分けてCommunity Edition (CE) とEnterprise Edition (EE) とありますが、本記事はCEで使えるCore機能のみにフォーカスしています。
2018年3・4月のGitLabトピック(一部)
その1. 4/10にGitLab Meetup Tokyo #7: 新年度応援＆GitLab 11.0が東京・サイボウズオフィスにて開催されました。私も参加しましたが、今回も100人規模の活況なイベントとなっていました。
開催中の様子。
その2. CNCFの発行するCloud Native Landscape InteractiveバージョンにGitLabおよびGitLab Runner (CI/CD)が掲載されました。
その3. 私自身もGitLab CE 10.7においてCEに16件,omnibusに5件のMRを入れてみました。
GitLabはまだまだUI/UX/機能/パフォーマンスが不十分なため、ご興味のある方はぜひコントリビューションにご参加ください。
Web IDE環境がCE(Core)に (Web IDE is now open source)
via https://docs.gitlab.com/ce/user/project/web_ide/
新しいWeb IDEはローカル環境を使うことなく、簡単な修正とMR作成を楽にそして簡単にします。
Web IDEを使うと、ブラウザだけで、複数ファイルの編集、Markdownのプレビュー、変更差分のレビュー、コミットができます。Web IDEはレポジトリ表示中、個別ファイル表示中、作成済みMRから開くことができるので、手早くフィードバックを解決したりコード修正したりすることができます。
Web IDEからMRを開くと、コミットする前にコミット差分をプレビューすることもできるので、Web IDEでMR全体を俯瞰しながらレビューできるようになります。
当初GitLab 10.4ではUltimateとしてリリースされましたが、このバージョン10.7で一般公開となりました。また、複雑で個人的なものを作るのに、IDEが有効な方法だと信じているため、このWeb IDEをOSS化する（GitLab CE (Core)に移行）ことにしました。これにより、好きなプロジェクトにコントリビュートする敷居が下がると思います。
元のリリースには記載がありませんが、ベース技術にマイクロソフトのMonaco Editor (Microsoft/monaco-editor)が利用されています。
関連ドキュメント
プロジェクト別Deployトークン (Deploy Tokens)
プロジェクトにおいて、長期間のGitレポジトリやGitLab Container Registryに置かれたDockerイメージへ読み取り専用のアクセス権が欲しいことがあります。これまでは、これを実現するためにはPersonal Access Tokens (PAT) を使う必要がありましたが、この方法では、ユーザアカウントに紐付いてしまうため、アクセス権もそれに紐付いていました（訳注：ユーザAがプロジェクトX, プロジェクトYにアクセスできる場合、プロジェクトXとプロジェクトYにアクセスできるトークン(PAT)を使うことができましたが、プロジェクトXのみにアクセスできるトークンは発行できませんでした。）
GitLab 10.7で導入された、Deployトークンでは、プロジェクト固有の永久または期限付きのトークンを発行できるようになりました。GitLabユーザは、レポジトリおよびContainer Registryに対して読み取り専用のアクセス権を有効化および失効できたり、有効期限の設定も可能です。
関連ドキュメント
'only'/ 'except' での変数サポート (Variables support in 'only' and 'except' keywords)
GitLab CI/CD設定では、特定のジョブ（タスク）を実行するかどうかを only や except キーワードを利用して、定義することができます。例えば、 master ブランチのみにおいてデプロイジョブを実行したいような場合です。
GitLab 10.7では、この条件付きジョブの文法で、特定の環境変数が設定されているか、または特定の値になっているという変数表現を許容する拡張をしました。例えば、プロジェクト変数を有効にするだけで特定のジョブを実行させたかったり、 GITLAB_USER_NAME 変数を見ることで、特定のユーザのときのみにジョブをスケジュールするというように定義できます。
関連ドキュメント
グループIssue BoardでのサブグループIssues対応 (Subgroup issues in Group Issue Board)
グループIssue Boardは一つのグループに含まれる複数のプロジェクトを横断して、一元的にイシューを管理するのに強力な機能です。これは、複数の異なるコードレポジトリで作業するチームには非常に便利です（GitLabのプロジェクトも同様です）。
今回のリリース以前では、グループIssue Boardに表示されるのは、そのグループの直下のプロジェクトのイシューのみでした。今回のリリースでは、そのグループの全てのサブグループに含まれるプロジェクトのイシューが表示されるようになりました。組織やソフトウェアプロダクトを反映させる形でGitLab上のグループやプロジェクトを構成している場合でも、その多階層のイシューを即座にグループIssue Boardで見ることができるようになります。
グループIssue Boardのこの制約により、サブグループを使うのを諦めていた、という人/組織は少なそうですが、サブグループをより気軽に使えるようになったのではないでしょうか。
関連ドキュメント
サブグループラベルによるアサインとフィルタリング (Assigning and filtering by subgroup labels)
サブグループはGitLabの強力な機能の一つですが、その機能性をラベルにも適用したいと考えていました。このリリースでは、任意のサブグループレベルにおいても、イシューやMRにグループラベルを割り当てることができるようになりました。
特に、あるイシューやMRにおいて、その親/祖先グループのグループラベルを付けられるようになりました。この自由度により、任意のグループレベルでもラベルを作成して、その下位グループで使えるようになります。
グループイシューリストやグループMRリストにおいて、個々のイシュー/MRがどのサブグループに属しているのかこれまでも確認できていたので、今回の機能強化により、親グループ/子グループに属しているグループラベルでフィルタできるようになります。つまり、GitLabはイシュー/MRに割り当て可能なラベルを強力さと自由度をユーザに提供します。
このフィルタ機能はグループIssue Boardにおける追加フィルタ機能とIssue Board設定との両方に導入されます。
関連ドキュメント
プロジェクトバッジ (Project Badges)
多くのプロジェクトで、GitLab CI/CDやshields.ioのバッジを使って、ビルドのステータスやコード品質を把握しているかと思います。一般的には、プロジェクトトップのREADMEにバッジを追加することが多いです。
今回のバージョンからはREADMEに書いてコミットするのではなく、プロジェクト設定側からプロジェクト説明のすぐ下に置けるようになります。また、プロジェクトのみならず、グループに対するバッジも設定できるようになります。
関連ドキュメント
GitLabプラグイン (GitLab Plugins)
オープンソースなので、GitLabは常に誰でも改善することができました。しかし、全GitLabユーザ組織がGitLab本体に改善を反映させたくなかったり、まず組織内のみで改善したいというニーズがありました。これまではGitLabレポジトリのフォークを動かすことで実現できましたが、この方法は継続するのが困難になりがちでした。
今回導入されたプラグイン機能では、GitLab system hooksでGitLabサーバ上に設定されたスクリプトを実行することができます。これにより、新規プロジェクトの作成時に保護ブランチのカスタマイズを自動化するといったような、ユーザ組織のニーズにあったGitLab拡張を容易にできるようになります。
関連ドキュメント
CI/CDジョブ中でHTTP(s) Gitプロトコルを有効化 (HTTP(s) Git protocol always available for CI/CD jobs)
GitLabでは、Gitレポジトリへのアクセス方法として、SSHとHTTP(s)をサポートしています。しかし、GitLab管理者はセキュリティ要件でHTTP(s)経由の通信をブロックしたいことがあります。例えば、クライアント側の設定がセキュアでないためにそのクレデンシャルが漏洩してしまうようなことを防ぎたいケースが挙げられます。しかし、HTTP(s)をブロックするということは、GitLab Runner上でGitレポジトリのクローンもできなくなりその結果CI/CDが正しく動かなくなってしまう問題がありました。
GitLab 10.7では、一般ユーザ向けにHTTP(s)ブロックしていたとしても、GitLab RunnerからのHTTP(s)プロトコルのgit clone/fetchのリクエストを許可するようになりました。常にワンタイムパスワード(OTP)を利用するため、セキュアでないクライアントからの攻撃はこれまで通り防ぐことができます。
関連ドキュメント
JSON Web Token omniauthサポート (Support for JSON Web Token OmniAuth)
GitLabはOmniAuthというライブラリを用いて、OAuth2のような標準認証サービスやTwitterやGoogleなどの第三者サービスを利用してGitLabへのログインをできるようにしています。このGitLab 10.7では、JSON Web Token (JWT) OmniAuthを追加しました。
JSON Web Tokenはコンパクトで自己完結型情報通信方式であり、サービス間の認証に幅広く使われるようになっています。
関連ドキュメント
LFSコンテンツがプロジェクトエクスポートの対象に (Project exports include LFS objects)
プロジェクトエクスポートはGitLabインスタンス間でプロジェクト（イシュー、MR、ラベル、Wiki、アップロード済みファイル）をできる機能です。今回からLFSコンテンツもプロジェクトエクスポートに含まれるようになりました。
関連ドキュメント
Runner別ジョブタイムアウト (Runner-specific job timeout)
GitLabではプロジェクトごとにCI/CDジョブの実行タイムアウトを定めることができました。設定されたタイムアウト時間を過ぎると、ジョブは停止させられ、GitLab側ではジョブ失敗として処理されます。
GitLab 10.7では、Runnerごとにタイムアウトを設定することができ、それはそのRunnerで実行されている全てのジョブに適用されます。プロジェクト別タイムアウト設定値とRunner別タイムアウト設定値とのうち、短い値が採用されます。特にshared runnerにおいて、一部のプロジェクトのジョブが長時間専有してしまうような場合に有効です。
関連ドキュメント
CI/CDジョブの失敗理由を見やすく (Easily get failure reasons for CI/CD jobs)
CI/CDジョブが失敗したら、ユーザは何が起こったのかを確認して、正しくCI/CDジョブが動くようにコミットしようとします。以前は、失敗したジョブを開いて、そのログを確認する必要がありました。
GitLab 10.7ではジョブのステータスバッジの一部にエラー理由を記載することで、デバッグを簡単に、高速にしています。
関連ドキュメント
Ubuntu 18.04 bionicサポート (Ubuntu 18.04 Bionic support)
gitlab-org/omnibus-gitlab#3275
omnibusパッケージで、Ubuntu 18.04 Bionicサポートしたものが利用可能になりました。bionic (Ubuntu 18.04)は4月26日リリース予定です。（訳注：リリースされました）
関連ドキュメント
GitLabバックアップからのリストアの改善 (Improvements to restoring GitLab backups)
GitLab 10.7では階層化されたディレクトリ構成へのリストアに対応しました。GitLab Container Registryのパスが /var/mypath/gitlab/registry であった場合でも、それはそのまま保たれます。従前は、リストアタスクは既存のディレクトリをタイムスタンプ付きディレクトリ <name>.<timestamp> としてリネームしようとしていましたが、権限がなく失敗していました。今後は tmp ディレクトリを生成することにより、リストア前に存在していたファイルをそこに移動します。
関連ドキュメント
GitLab Pagesの常時SSL対応 (GitLab Pages automatic HTTPS redirect)
GitLab PagesはHTTPまたはHTTPSプロトコルでの静的ウェブサイトホスティングをサポートしていました。全ての通信が暗号化され、インターネットを経由するコンテンツを保護できるので、通常はHTTPSが好まれます。
HTTP/HTTPSの両方が利用可能な場合、GitLab 10.7以降では、インスタンス全体で、常時SSLが設定可能になります。
関連ドキュメント
GitLab Let's Encrypt証明書の自動更新 (Automatic renewal of GitLab Let's Encrypt certificate)
gitlab-org/omnibus-gitlab#3251
GitLab 10.5で、Let's Encrypt連携により、GitLabインスタンスでHTTPSを簡単に有効化できる機能を提供しました。
GitLab 10.7では、自動更新プロセスを有効化することにより、HTTPS化がさらに簡単になりました。これにより external_url に https:// から始まるURLを指定するだけでよくなりました。
関連ドキュメント
Cloud native GitLab chartがCore提供開始（アルファ） (Cloud native GitLab chart available for Core (alpha))
Coreバージョンにおけるオブジェクトストレージのサポートのバックポートにより、アルファバージョンのcloud native GitLab chartがEEライセンスなしで利用できるようになりました。このHelm chartはこれまでよりcloud nativeなアーキテクチャを特徴としており、共有ストレージなしでGitLabコンポーネントをコンテナで運用することができます。これにより、レジリエンス（自動復元性）が高く、スケーラブルでハイパフォーマンスなGitLabがKubernetes上で動かせるようになりました。
関連ドキュメント
環境メトリックスダッシュボードの改善 (Improvements to the environment metrics dashboard)
環境メトリックスダッシュボードで概要サマリが閲覧できるようになりました。特定タイムスパンの中で、各種タイムシリーズデータの平均・最小・最大値が表示できるようになります。例えば、過去8時間の平均レスポンスタイムが簡単に見れるようになりました。
Kuberentes連携においては、全podのCPUおよびメモリの使用量も表示されるようになり、クラスタないの特定環境のリソース使用量の傾向が簡単に見れるようになっています。
関連ドキュメント
GitLab Runner 10.7
GitLab 10.7に合わせ、GitLab Runner 10.7も同日リリースしています。GitLab RunnerはGitLab CI/CDジョブを実際に実行し、結果をGitLab本体に返す役割のオープンソースソフトウェアです。
主な変更点:
- Dockerコンテナでメモリの使用量を指定できるように
- サービスヘルスチェックの改善
- Goバージョンを1.9.xから1.8.7にダウングレード
- Runner初期登録時のmax_job_timeoutパラメータ対応
すべての変更はGitLab RunnerのCHANGELOGに記載されています。
関連ドキュメント
omnibusパッケージの改善 (Omnibus improvements)
- GitLab Mattermost 4.8.1へのアップグレード。プラットフォームの改善、20MB以上のファイルをアップロードできるiOSエンドポイントなど多数。
-
Sweet32対応のため、デフォルトの
ssl_ciphersリストからECDHE-RSA-DES-CBC3-SHAおよびDES-CBC3-SHAを除外しています。 - redis_exporterを0.17.1にアップグレード。
関連ドキュメント
パフォーマンス改善 (Performance improvements)
毎月恒例のパフォーマンス改善はGitLab 10.7でも多数取り込まれています。主なものは以下です:
- Merge requestsの読み込み高速化・読み込み数削減
- MR差分表示でVue.jsを採用し、UX改善とパフォーマンス改善
- MR差分表示におけるRedis使用量を削減
- 個人プロジェクトの数をキャッシュ
- 不正なプロジェクトAPIへのアクセスで不要なクエリを実行しない
- グループのAtomフィードにおいて無駄なクエリの削減
- イシュー/MR/マイルストーン(/エピック)で発行されるIDがユニーク保証に
関連ドキュメント
本ドキュメントのライセンス
- カバーイメージ: Unsplash free license
-
その他:
CC BY-SA 4.0
お知らせ
次リリースは5/22に10.8となり、これがGitLab 10系最後のリリースとなります。