[GitLab CI] マトリックスを組んでみた

GitLab CI でマトリックスを組んでみました。

Matrix Builds in CI - Questions & Answers / GitLab CI - GitLab Forum
方法は２つあって、YAML のアンカーを使った方法と、それと同等の extends を使った方法です。
（マトリックス分べた書きすればどんな CI サービスでも複数ジョブは実現できるが、重複する冗長な部分をまとめて簡潔に書けますよーという感じ）

Anchor を使った方法

YAML にはアンカーとエイリアス記法が存在します。
これは GitLab の YAML の機能ではなく、YAML の標準的な記法のため、別の CI サービスでも応用できると思います。

Anchors - Configuration of your jobs with .gitlab-ci.yml | GitLab
以下は公式の例を参照しています。

.job_template: &job_definition  # Hidden key that defines an anchor named 'job_definition'
  image: ruby:2.1
  services:
    - postgres
    - redis

test1:
  <<: *job_definition           # Merge the contents of the 'job_definition' alias
  script:
    - test1 project

test2:
  << *job_definition           # Merge the contents of the 'job_definition' alias
  script:
    - test2 project

&名前 でアンカーを作成し、*名前でアンカーを参照します。
また、 「<< *名前」とすると、アンカーの内容をマージしてくれます。

つまり、共有部分をアンカーとして定義し、マトリックスジョブに可変部分を定義、あとは共有部分をマージすれば簡単にマトリックスを組むことができます。
（今回は後述の extends で書いたので実例は省略）

extends を使った方法

こちらは GitLab 11.3 で導入された GitLab の機能になります。
アンカーを書かずとも、extends で指定した YAML 要素を展開できる機能のようです。
アンカー記法やその参照方法を知らなくても、より直感的に書けるのでこちらをオススメします。

extends - Configuration of your jobs with .gitlab-ci.yml | GitLab
アンカーの例を extends で書き直すと以下のようになります。」

.job_template:
  image: ruby:2.1
  services:
    - postgres
    - redis

test1:
  extends: .job_template
  script:
    - test1 project

test2:
  extends: .job_template
  script:
    - test2 project

（アンカー記法を見たあとだと、どっちでも良くない？となりますが、知らない人からしたら読みやすくなってるとは思います。）

iutest-test での実例

さて、最後に実例として iutest-test の例を紹介したいと思います。
iutest-test がどういったもので、どんな CI をしているかは以前に書いたこちらの記事を参考にしてください。
「ブログズミ: iutest のテストをするリポジトリ iutest-test を GitLab/GitLab CI に引っ越しました」

今回、マトリックスを組むことにした理由は、CI するブランチの対象を master のみから、master|develop に変更しようと思ったからです。
iutest-test でしているテストの重要度は高いわけではないので、１日１回 master ブランチを対象としていましたが、やっぱり master にマージしてからじゃないと状態がわからないのはよくないなと思い、develop でも１日１回実行すようにしました。


YAML はこちら→iutest-test / .gitlab-ci.yml


これで、定期ビルドでサブモジュールの更新が master / develop ２つに対して行われるようになりました。

最後に

今回のような定期ビルドの環境変数をマトリックスにしたいようなケースはパイプラインでなくても、トリガー固有の環境変数定義でもできると思います。
ただ、YAML のアンカーにしろ、extends にしろ、書き方を知っておくと、いざというときに役に立つのではないかと思います。

というわけで、早速アンカーを使った他の CI サービスの YAML を DRY にしようと思います。
今回は以上です。
では。

iutest のテストをするリポジトリ iutest-test を GitLab/GitLab CI に引っ越しました

iutest の外部テストリポジトリとして iutest-test を作成し、そこで Google Test との互換性テストを行ってきましたが、別リポジトリにしたのなら、GitLab に引っ越しして GitLab CI を使えるのでは？
ということで引っ越ししました。

Sign Up & Import

まずは GitLab への SignUp をしましょう。（GitLab は有名なので省略）
GitLab は GitHub からリポジトリをインポートできるので、その機能を使って iutest-test を持ってきます。


New Project から Import project を開いて、GitHub を選択（いっぱい対応してますね）


インポートしたいリポジトリを選択して、Import ボタンを押したら完了です。






簡単ですね！

.gitlab-ci.yml の作成

続いて、CI の設定をします。
もともと iutest-test では Travis-CI で定期ビルドして、iutest のサブモジュール更新を行い、
その push トリガーによって、Codefresh でテストを実行していました。
（そのときの記事はこちら→「」）

今回 GitLab に引っ越してすごく良かったのが、この２つのビルドを GitLab CI １つで完結できたことです。できあがった .gitlab-ci.yml は以下になります。


そして、Google Test 最新コミットとの互換性テストの構成はこのようになりました。


画像の上半分あたりは、
「ブログズミ: 依存ライブラリの GitHub を Travis CI で定期的に監視して DockerHub Automate Build を実行する（+ Codefresh ジョブを Trigger）」で紹介した内容とほぼ同じです。
（違いは　Webhook 先が変わったのと、Google Test の更新検知をサブモジュールにしたくらい）

サブモジュールの更新

update_submodule のパイプラインがサブモジュールの iutest の更新を担います。
こちらは、毎日1回のスケジュールトリガーで起動します。
特に難しいことはなく、サブモジュールを最新にしているだけです。
リモートに push する部分ですが、Protected な環境変数に記録した秘密鍵を使って行います。
やり方はこちらを参考にしました。
.gitlab.ci.yml for SSH with private key.

Deploy Key の登録

まずは公開鍵を登録します。
「Settings」 > 「Repository」の「Deploy Keys」から登録してください。

push のためのキーを環境変数に設定する

https://docs.gitlab.com/ee/ci/variables/#variables
「Settings」 > 「CI/CD」 に 「Variables」 があるのでそこで設定します。
Protected にしてくださいね！

> They can be protected by only exposing them to protected branches or tags. 

ちなみに、ここで設定した Protected Variable は Protected branch or tag でしか使えないので注意！
ブランチ設定は「Settings」 > 「Repository」 > 「Protected Branches」でできます。

update_submodule ブランチの意味は？

サブモジュールを更新して master ブランチに push する update_submodule パイプラインですが、これを行うのは master ブランチではなく update_submodule ブランチです。
なぜ、別ブランチで行っているかというと、バッジのためです。

サブモジュールを更新するパイプラインも立派なパイプラインの１つです。
バッジはブランチ単位で発行できますが、パイプラインでわけることができないので、同じブランチでやってしまうと「テストパイプラインは失敗している」「サブモジュール更新は成功している」ときに、正しく最新のテスト状況を表示できません。
そのため、ブランチを分けています。
（パイプラインごとにバッジ出せると嬉しいですが・・・）

テストの実行

テストの部分は前回から特に変わってません。
Google Test の最新コミットが入った docker コンテナを落としてきて、その中で iutest の互換性テストを実行しています。
前回との差分としては、DockerHub からの Webhook が latest と latest-alpine の２つが飛んでくる（release があるとそのタグも）ので、 latest のみパイプラインを起動するようにフィルタリングするようにしました。
フィルタリング部分は最近お気に入りの Integromat で行いました。
そのへんは別の記事を参考にしていただければと思います。
「ブログズミ: Travis CI の結果をツイートするのを Zapier から Integromat に引っ越した」

これで完成、あとは・・・

バッジを付けましょう！お約束ですね。
GitLab CI のバッジは、「Settings」 > 「CI / CD」 > 「General pipelines」 を展開すると、「」があるのでそちらで取得できます。



（失敗してるのは気にしないでください・・・）

ところで、そもそもなんでリポジトリを分けてるの？

（このへんもブログにしとけばよかったなーと思いつつ）・・・理由は簡単で関連先が理由でテストが失敗したままになるのが困るからです。
iutest は独立したフレームワークですが、Google Test の Add on としての機能を持っていたりするので、Google Test を使ったテストもしています。
PR とかあったときに、Fail となっても困惑を生むだけだと思ったので、テスト用にリポジトリを分け、さらに粒度も1日1回程度にしました。

最後に

個人的に、外部依存のライブラリとのテスト構築のパターンが出来上がった、という感想。
こう、カチッとハマった感じはいいですね。

今回は以上です。
では。