ということで引っ越ししました。
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回程度にしました。
最後に
個人的に、外部依存のライブラリとのテスト構築のパターンが出来上がった、という感想。こう、カチッとハマった感じはいいですね。
今回は以上です。
では。
0 件のコメント:
コメントを投稿