2018年11月26日月曜日

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

参照:

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

ジョブのクラス名付きでリストアップ
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()

2018年11月20日火曜日

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 に引っ越してすごく良かったのが、この2つのビルドを GitLab CI 1つで完結できたことです。できあがった .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 ブランチです。
なぜ、別ブランチで行っているかというと、バッジのためです。

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

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

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



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

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

今回は以上です。
では。



2018年11月14日水曜日

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

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


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


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

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


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

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


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



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

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


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

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



(Hybrid スタック使えばいいんでしょうが、その前に Android ビルド環境を整えねば・・・)
Workflow ごとのバッジがほしい
バッジ集めが趣味なので、ワークフローごとのバッジがほしいなーと思ってます。
(ワークフローで iOS/Android を別途書くことが多いと思うのですが、それぞれでバッジを出したい)
(今は並列実行の件もあってプロジェクト自体を2つ作ってますが・・・そうすると両方の結果を加味したバッジ表示ができないので、それもまた困っているところ)


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

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

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

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

では。またどこかで。

2018年11月8日木曜日

travis-ci.org から travis-ci.com に移行しました



Travis CI といえば travis-ci.org だったんですが、
GitHub Checks API を試してみようと思って調べていたら
(そのへんのことはこちら→「ブログズミ: GitHub Checks 対応 CI サービスを使ってみた」)
travis-ci.com のことを知りました。

.com の方は今までは public リポジトリ(OSS)が対応していなかったようですが、public リポジトリも .com を利用可能になりました。
そして、GitHub Checks API に対応しているのは .com の方なので、移行が必要でした。

すでに .org の方でビルドされているプロジェクトは、すぐには .com は使えなくマイグレーションが必要です。(新規の場合は .com で登録できる)
ただ、マイグレーションに関しては順次行われるようですが、遅延しているらしく、すぐに .com に移行したい場合はサポートにメールで依頼する必要があります。
iutest で Checks API を使いたかったので、メール依頼を出してみました。





マイグレーションにあたっての注意点
上記キャプチャにも書かれていますが、マイグレーションをすると .org の方の履歴は消えます。 Web config 部分も消えます。
マイグレーション依頼のメールを出すと、最初に本当にいいのかと?注意事項の確認がされます。

Migrating repos from travis.ci.org to travis-ci.com currently has the following caveats:

a) the build number will be reset to zero
b) the repo on travis-ci.com will start with a blank build history
c) the old build history will still be available on travis-ci.org
d) environment variables will not be migrated
e) environment variables will need to be recreated and, where necessary, re-encrypted by the customer for use in .travis.yml
f) repo settings such as enabled push or pull builds, auto-cancellation etc will not be migrated

iutest の場合、履歴に関しては、別に消えても特に問題がないので OK
Web config 系は cron 設定くらいなので、とりあえず .org の設定をキャプチャしておきました。



最初のビルドは4年以上前だったみたいですね。ほー

Hello Travis-CI ".COM"!
メールで注意事項に対して問題ないことを伝えると、ほどなく移行完了メールが来ると思います。
あとは、退避しておいた Web Config を戻すのと、 Encrypting environment variables を使っている場合は再生成が必要になります。
(再生成の際には、 travis login --pro で .com の方にログインして行います。エラーメッセージが出ると思うのでやってみればわかると思います)

これにて、無事に移行が完了しました。

GitHub Checks
さて、最後に一番の目的である GitHub Checks を見てみましょう。

https://github.com/srz-zumix/iutest/pull/118/checks


ちゃんと出てますね!
各 CI の結果が GitHub のページに集約されるのは、いろんなサービスを使っている自分としてはとても助かります。
対応サービスが今後も増えるといいですね。

今回は以上です。

2018年11月1日木曜日

GitHub Checks 対応 CI サービスを使ってみた

さて、お気づきの方もいらっしゃると思いますが、GitHub の PR ベージに「Checks」タブが現れました。


こちらは、最近5月頃リリースされた Checks API 用のタブのようです。
Introducing the Checks API, a better way to connect integrations and code | The GitHub Blog
サード・パーティCIツールとのより深い連携を実現する新機能「Checks API」のパブリックベータ版を公開 | The GitHub Blog

CI での指摘がこちらのタブに集約される感じでしょうか。
これまでは、CI の「成功/失敗」はすぐに確認できたものの、失敗の内容は CI サービスに飛ばないとわからない(権限ないと見ることすらできない)状態だったので、これは便利になりそうです。


実際に使ってみた(失敗 PRの例)
iutest ではいろんな CI サービスを使ってますが、その中の1つ Cirrus CI が Checks API に対応して、タブに表示されていたのでそちらを例として紹介します。

テストが失敗すると↑のように Checks タブから確認できます。
Cirrus CI では OS および -std オプションをパラメタライズドに4つのテストが実施されています。サービスのぶら下がって4つのプレートが出ていますね。
それぞれ、プレートをクリックすると結果が確認できる仕組みです。

Re-run,Re-run all があるので、環境エラーなどで失敗してた場合に PR した側でも再実行できるので、それはレビュイーとしては助かりそうです。

最後に
PR ベースの開発をあまりしていないので、まだ使ってみた機会は少ないのですが、失敗原因を1つの画面で確認できるのは便利そうな気がしました。
早く他のサービスも対応していくといいなーと思いました。

今回は以上です。





ちなみに… Travis CI の表示がありますが、iutest ではまだ結果を Checks タブで見ることはできません。
実のところ、Checks API が出た5月ころにはもうこの記事を書いていて、Travis CI で試した感想を書こうと思ってましたが、いろいろあって(略)このタイミングとなりました。

編集後記1
供養
インストール
Checks タブを開くと Marketplace へのリンクがあるので開いて、お好きなものをインストールだけです。




といっても、iutest で使っている CI サービスで、
Checks API に対応しているサービスは現在(2018/6)時点では Travis CI くらいなので、そちらをインストールしました。
(インストール手順は特につまるとこもないので省略)

ここで文章は途切れている・・・
Travis CI は Checks Api に対応しているのですがタブができるだけで特に何も表示されませんでした。

0・・・

The Travis CI Blog: Announcing support for the GitHub Checks API on travis-ci.com


OSS , will soon , ははあーんまだか・・・
(まだそうだったので、記事作成を中断・・・)

・・・3ヶ月後
おおー Cirrus CI が Checks API に対応したでぇ!

Travis CI はまだかー・・・
と思いつつ、Cirrus CI で記事の続きを書くことにしました。

編集後記2
Travis CI の状況を確認
記事の続きを書くにあたって、 Travis CI の状況をちゃんと把握しようということでドキュメントを確認しました。
https://docs.travis-ci.com/user/open-source-on-travis-ci-com/#existing-open-source-repositories-on-travis-ciorg

どうやら、移行は勝手にしてくれるみたいですが、遅れているようです。
もし、ビルド履歴や設定(環境変数を含む)が消えてもいいのであれば、リクエストメールを送ることですぐさま移行ができるみたいです。

iutest の場合、設定は特に消えても大丈夫(月一定期実行してるくらい)で、ビルド履歴も数年間歩んできた思い出くらいの意味しかないので、綺麗さっぱり移行することに決めました。
travis-ci.com への移行手順は別途記事を書いてますので、そのうち公開する予定です。

公開したらここに追記