[Jenkins] 種類ごとにジョブをリストアップ

参照：

https://support.cloudbees.com/hc/en-us/articles/226941767-Groovy-to-list-all-jobs

下記をスクリプトコンソールで実行しましょう。

ジョブのクラス名付きでリストアップ

def list = Jenkins.instance.getAllItems(Job.class)
list.each{ 
  println it.name + " - " + it.class
}
return list.size()

目的のクラスでリストアップ

def list = Jenkins.instance.getAllItems(class hudson.model.FreeStyleProject)
list.each{ 
  println it.name
}
return list.size()

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回程度にしました。

最後に

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

今回は以上です。
では。

CI/CD Test Night #1/#2 に参加してきた

CI/CD Test Night #1
CI/CD Test Night #2


1日目は、補欠だったのですが当日繰り上がったので参加。
2日目は、当選してたので予定通り参加してきました。
（ブログ参加枠ではないのでテキトーに書きます）

Get pic.twitter.com/Qt3GzAzWGx

— Z.Z.ずみっくす (@srz_zumix) 2018年11月7日

(両日参加でパーカーもらえたようですが、Tシャツを着ていく必要があったようで、思いっきりネタTシャツで行ってしまいもらえなかった・・・)

感想

Bitrise の方が来日してくれたこともあって、Bitrise の話題が多かったです。
Bitrise は自分にとっては使っている CI サービスの１つくらいの認識で、モバイルに強いという印象がある程度でした。
特に自分ではその強みの恩恵を受けてはいないので（iOS/Androidアプリを作っているわけじゃないので）、LT を聞いててみんな使ってるんだなーという感想。あとは Circle CI も強いんだなという感想。

Bitrise をより深く使ってみた

公演でワークフローのヒントをいろいろもらったので、やってみました。

設定の diff と restore

ワークフローとかパイプラインとか作ってるときって、結構トライアンドエラーが多いので Restore できるのはありがたい。
他のサービスよりも diff が見やすいなーと思いました。

Bitrise, yml の diff は見やすいし、Restore できるのは便利だな pic.twitter.com/iDfz25ugga

— Z.Z.ずみっくす (@srz_zumix) 2018年11月8日

並行実行

ワークフローを直列に実行するのではなく、２つに枝分かれさせて並行実行させる方法のブログ記事が紹介されたので、試してみました。

Start multiple builds with the same trigger https://t.co/cO2PP2uD8Q

— Z.Z.ずみっくす (@srz_zumix) 2018年11月8日

方法としては、別のワークフローをキックするステップが用意されているので、それを入れ込むだけです。
上記ブログで紹介されているのは、「Bitrise Start Build」を使った方法です。
（Bitrise Start Build Step でも Trigger Bitrise workflow でも、どっちでも実現できたましたが、Start Build のほうは待ちができます。）
（Start Build の方は Personal Access Token が、Trigger workflow の方は Build Trigger Token が必要になります。）

やってみた結果としては、そもそも Free プランだと 1並列 だけなので、ビルドが詰まって無理でした。。。

parallel build, 1 CONCURRENCY だからやっても無理か・・・ pic.twitter.com/sl1k01OhLL

— Z.Z.ずみっくす (@srz_zumix) 2018年11月8日

異なるスタックのビルドを１つのワークフローで実行したい

並行実行はできたらいいなくらいだったので、Free プランでできないのは致し方ないですが、
iutest では、iOS / Android ビルドのために、Mac と Ubuntu のスタックをそれぞれ利用しています。
そのため、これまではプロジェクト自体を分けて対応していました。
ただ、1 push に 2 ビルド消費してしまうので、１つのワークフローで iOS / Android ビルドができないかなと思ってました。

ただ単純にワークフローをつないだときに、スタックの切り替えもしてくれると良かったんですが、そううまくはいかないものです。。。



（Hybrid スタック使えばいいんでしょうが、その前に Android ビルド環境を整えねば・・・）

Workflow ごとのバッジがほしい

バッジ集めが趣味なので、ワークフローごとのバッジがほしいなーと思ってます。
（ワークフローで iOS/Android を別途書くことが多いと思うのですが、それぞれでバッジを出したい）
（今は並列実行の件もあってプロジェクト自体を２つ作ってますが・・・そうすると両方の結果を加味したバッジ表示ができないので、それもまた困っているところ）


すでにできるのかもしれないですが、やり方がわからず。
情報あればコメントいただけると嬉しいです。

（ここでワークフロー選択ができるといいんですが。。。）

最後に

Jenkins 以外で CI メインの勉強会って、たぶん初めての参加だったのですが、楽しかったです。
やっぱり CI 面白いですわ。

あとは、Bitrise のワークフローを見直すイイ機会になりました。
今まではただ使ってるって感じだったので、もっと使い倒していこうと思います！
（とりあえず、この記事で書いた未解決な件はもう少し考える）

では。またどこかで。