[Bitrise] GitHub Checks に表示されるようにする

公式ドキュメントがすごくわかりやすくまとまっているのでそちらを見ていただくだけで十分ではありますが、今回は Bitrise で GitHub Checks に結果を表示させる方法を紹介します。

セットアップ方法

Bitrise Checks App をインストールする

Bitrise Checks をインストールします。

「Install for free」ボタン押すと確認画面後、リポジトリの選択をして「Install」しましょう。

プロジェクト設定の GitHub Checks を有効にする

Bitrise のプロジェクトから「Settings」の「Enable GitHub Checks」にチェックを入れましょう。

これでセットアップは完了です。

結果

見やすくていいですね！

と、ここで気づいたのですが iutest では iOS/Android 両方のテストをするために 2 プロジェクト作ってるのですが、PR ステータスも Checks も 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 のワークフローを見直すイイ機会になりました。
今まではただ使ってるって感じだったので、もっと使い倒していこうと思います！
（とりあえず、この記事で書いた未解決な件はもう少し考える）

では。またどこかで。

[CI] 各種 CI サービスのビルドスキップコメントまとめ (2018/3)

CIサービスの自動ビルドをスキップする方法まとめ - Qiita
こちらに Travis CI、Circle CI、Appveyor の場合がまとまっていますが、この記事では私が利用している CI サービスすべてをまとめたいと思います。

[ci skip] vs [skip ci]

CI サービスでスキップするためのコミットコメントの定番が [ci skip] と [skip ci] です。どちらにも対応しているサービスもあれば、片方だけだったり、これに加えて独自のメッセージに対応していたりします。

iutest では全部で10以上のサービスを利用しているので、すべてのサービスで共通して使えるコメントでないと困るので今回のまとめに至りました。
また、特定のサービスだけスキップしたいなどの要求もあるかもしれないので、そういった場合にも役立つまとめになっているかと思います。

前置きはこれくらいにして、まとめを見ていきましょう。

まとめ

サービス	[ci skip]	[skip ci]	その他	ユーザー定義
Travis CI	○	○
Circle CI	○	○
AppVeyor	○	○	[skip appveyor]	○
wercker	○	○
Shippable	○	○
Codeship	○	○	--skip-ci,--ci-skip
Semaphore	○	○
Codefresh				○
Bitrise	○	○
Scrutinizer	○	○	[skip Scrutinizer]
Rocro(INSPECODE)

以前は、[ci skip] 派と [skip ci] 派が分かれていたのですが、
現在は [ci skip]/[skip ci] どちらも使える派が主流のようです。
Rocro はスキップできないみたいですね。

ユーザー定義も可能な AppVeyor

AppVeyor ではユーザーが任意のスキップコメントをつけることもできます。
https://www.appveyor.com/docs/how-to/filtering-commits/#skip-commits

やり方は appveyor.yml に以下を追加するだけです。

skip_commits:
  message: /\[no appveyor\]/

これを設定しておけば、AppVeyor だけスキップするような使い方ができます。

自分ですべて設定する Codefresh

https://docs.codefresh.io/docs/build-1
Codefresh にはデフォルトでスキップコメント機能はついていませんでした。
ただ、上記リンクのようにコンディションに書けば対応が可能でした。

steps:
  BuildingDockerImage:
    title: Building Docker Image
    type: build
    image_name: srzzumix/ciskip
    working_directory: ./
    dockerfile:
      content: |-
        FROM ubuntu:latest
        COPY . /usr/src/myapp
        WORKDIR /usr/src/myapp
    tag: '${{CF_BRANCH_TAG_NORMALIZED}}'
    when:
      condition:
        all:
          noSkipCiInCommitMessage: |
            includes(lower("${{CF_COMMIT_MESSAGE}}"), "[ci skip]") == false && includes(lower("${{CF_COMMIT_MESSAGE}}"), "[skip ci]") == false

注意が必要なのは、スキップ設定はすべてのステップに記述しないといけない点です。
（前のステップがスキップされても、後続のステップはスキップされないです。前のステップに依存しているとビルドが失敗します。）

また、スキップしたと言ってもビルド回数はカウントアップされます。。。（フリーアカウントの場合ビルド回数制限があるので気をつけましょう）

Only the head/last commit message is checked!

Bitrise のドキュメントに以下の注意書きがありました。

Only the head/last commit message is checked!
If you push more than one commit, only the last ("head") commit's message will be checked for the skip ci pattern!

http://devcenter.bitrise.io/tips-and-tricks/skip-a-build/

複数のコミットをまとめて push した場合、コメントは最後のコミットのものしかチェックしないようです。つまり、途中のコミットにスキップコメントを入れてもスキップされないということです。

他のサービスではどうなのか調べてみたところ、（Travis CI を除く）他のサービスも同様の挙動をしてました。

Travis CI は全部にスキップコメントが必要

Travis CI は push したときの head だけでなく、commit 毎にビルドが実行されるようなので、全部のコミットにスキップメッセージを入れないとイケナイようです。
「Auto cancel branch builds」設定ができるようになりましたが、これは新しいビルドがキューイングされたらキャンセルする機能です。
スキップコメントの commit はキューイングされないため自動キャンセルもされません。

なので、Travis CI を使う場合は [ci skip] をスキップしたいコミットにつける必要があります。

Travis CI は、スキップしたいコミットに [ci skip] をつける。
それ以外は、スキップしたいコミットを含む push を行う場合は head のコミットに [ci skip] をつける。
ということになるので、Travis CI の方が直感的かもしれませんね。

最後に

今回調べたことは、こちらのリポジトリで検証・記録として見ることができます。
https://github.com/srz-zumix/ci-skip

他に試して欲しい CI サービスなどありましたら、連絡もしくは PR ください。
では。

[CI] Bitrise で紹介プログラムが始まってた

Extra minutes on hobby plan! | Bitrise


以前の紹介したBitrise （ブログズミ: [CI] Bitrise 始めました）で、"Referral program（紹介プログラム）"が始まりました。
このプログラムは紹介するごとに、ビルド時間の上限が +5 分され、最大 +20 分できるものです。
条件や方法については、後述します。

無料プランではビルド時間 10分 の制限がある

Bitrise Pricing

Bitrise の Hobby plan (無料プラン)では、1ビルド10分の制限があります。

10分制限は、他の CI サービスと比べると結構短いです。
参考（少し古いですが…）：「ブログズミ: 無料で使える CI サービス比較」

iutest でも、この制限回避のために iOS と Android のテストジョブを別個に用意してます。
（やりようによっては制限時間内に収められるかもしれませんし、分ける利点もあったりしますが…）

Referral program で無料プランでのビルド時間が最大 30 分になる

今回のプログラムを利用することで、ビルド時間が最大 30 分まで増やせるようになりました。
1人紹介するごとに +5 分で、4人紹介で最大の 30 分になります。
さらに、紹介人数が5人になると Bitrise Tシャツがもらえるっぽいですw

条件と方法

まず、方法ですが、
Account Settings に Referrals のタブがあるのでそこを開きます。
（今なら上のバーにもリンクがありますね）
開くと、紹介用URL が右上に書いてありますので、この URL からアクセスしてもらうのが第一条件です。

筆者の場合 https://www.bitrise.io?referrer=a9c0b9baf7536067 です。（よろしくお願いしますm(__)m）

そして、アカウント登録をしてもらうこと、
さらに、ジョブ（App）を追加して、ビルドがグリーンであること、
これらの条件をすべて満たすと、紹介したことになり、+5 分されます。

筆者はまだ 0 人なので、公式ブログをキャプチャした画像になりますが、
こんな感じで状態が表示されるようです。

最後に

Bitriseは、iOS/Android のアプリ開発では定番の CI になっているようですし、それらの開発をしている方は是非使ってみてください。
また、最近どこの CI でも見るようになってきた ワークフロー も、Bitrise では使えますので、試してみたい方も是非！
そして、私に Bitrise T-shirt をください！

I love how easy and powerful Bitrise is to test and distribute my apps - get your FREE @bitrise account now: https://t.co/R1IxfehrXJ

— ずみっくす (@srz_zumix) 2017年7月23日

今回は以上です。では！

[CI] Bitrise 始めました

今回も CI サービスの紹介でございます。
今回は「Bitrise」です。

http://devcenter.bitrise.io/

In short Bitrise is a Continuous Integration and Delivery (CI/CD) Platform as a Service (PaaS) with a main focus on mobile app development (iOS, Android, Xamarin, ...).

こちらに書かれているように Bitrise はモバイルをメインターゲットとした CI/CD サービスです。
今回、iutest では CMake で生成した Xcode プロジェクトをビルド（テスト）する CI サービスとして利用を開始しました。

このブログで紹介するということは、もちろんフリープランが存在します。


200ビルド/月、10分/ビルド、と少し制限厳し目ですが、iutest で使う分にはなんとかなりそうです。

Sign up

では、早速 Sign up しましょう。
「Start building for free」ボタンを押すと、まずは以下のようなアカウント登録画面が表示されます。
通常のメールアドレスの他、Github,Bitbucket,GitLab アカウントが選択できますので、お好きなものを選択してください。



続いて、簡単なアンケートが出ます。答えても答えなくても OK です。


次にパスワード設定をします。Github などのアカウントを利用した場合でも必須のようです。


これで登録完了です。

app 追加

Sign Up できたので早速ジョブ（app）を作っていきましょう。
「+Add first app」ボタンをクリックすると、リポジトリ選択画面になります。
目的のリポジトリを選択してください。


次はリポジトリアクセス設定です。
iutest では 「AUTOMATIC 」、 「No, auto-add SSH Key」としました。必要に応じて変更してください。


つづいて、セットアップの検証が行われます。
対象ブランチを選択して「Next」を押します。


検証が始まるので待ちます。


検証が終わるとビルドコンフィグが開きます。

Xamarin が選ばれてますが、おそらく Visual Studio の .sln ファイルを検出したからでしょう。
ただ、iutest は Xamarin 使ってません。ここは「MANUAL」で設定をします。

今回は、Xcode ビルド（とテスト）をしたいので、「macOS」とか「iOS」を選択したいところですが、プロジェクトファイルや Scheme を要求されるため、「OTHER/MAUNUAL」から「Xcode on macOS」な Stack を選択して次へ。



最後に Webhook 設定をします。
特に理由がなければ、「Register」で良いと思います。Push and PR が Bitrise に通知されます。


これで、作成完了です！

ワークフローを作成する

Bitrise では Workflow で処理を記述します。

Workflow タブをクリックすると Editor が開きます。




既存のステップがたくさんありますが、Script を使うと bash script ので目的にあったステップがない場合は、これを使えばなんとかなると思います。



フローが完成したら、SAVE ボタンを押して保存しましょう。
※ ちなみに、ワークフローは複数作成でき、master のときは A 、 develop のときは B のようなこともできますし、
ワークフロー同士をつなげることもできます。

特定ブランチを除外する

デフォルトの設定だとすべてのブランチを対象にワークフローが始まるようになってますが、特定のブランチは CI したくない場合（iutest の場合は gh-pages）は、「Workflow Editor」の「Triggers」から設定を変更できます。
Push / PR / Tag それぞれにトリガーの設定が可能で、ここでどのワークフローと連結するかも設定できます。

※ exclude 指定ができると良かったのですが…

バッジ

最後にお約束のバッジです。
バッジは「Dashboard」の上の方にある「バッジ」をクリックすると Markdown などのテキストが取得できます。

最後に

今回 iutest では CMake + Xocde build のために Bitrise を使いました。
これであれば正直 Bitrise じゃなくてもできます。（Travis CI や Circle CI は Mac OS ワーカーを使えたはず）

ただ、最初にも書いたように Bitrise はモバイルアプリをメインターゲットにしているので、
それらの開発をしている方は一度試してみてはいかがでしょうか？
きっと、他の CI サービスにはない旨味があるのではないでしょうか。

今回は以上です。では。