JFrog Pipelines はじめました

 Shippable はだいぶ前に JFrog 傘下になり JFrog Pipelines と Shippable の２つのサービスが提供されていました。
Shippable のサービス提供も続けていくよとされていましたが、とうとう終了となりました。
（マイニングの影響もあったのかはわからないけど、あれは困ったものですな）
The Next Step in the Evolution of Shippable: JFrog Pipelines

いつまで見られるかわからないですが、こちらは引越し前の Shippable ビルド履歴です。
https://app.shippable.com/github/srz-zumix/iutest/dashboard/history
5/3 まで元気に動いてました。お疲れ様でした。

さて、Shippable は終了となりましたが、JFrog Pipelines に移行できるようなのでやってみました。
移行するのは以下のリポジトリです。
https://github.com/srz-zumix/iutest

Pricing

その前に気になるのはお値段ですよね。
Shippable のときは↓な感じでしたが、

Unlimited builds for public projects
150 builds/month for private projects
Forum support

（Shippable がどんなのだったかは拙著「あつまれCIサービス」を読んで頂くのもありですよ）

JFrog Pipelines はこんな感じ。

ビルド時間無制限はこのご時世ではもう無理なんでしょうねぇ
それでも2000分/月使えるのはありがたいです。（Travis CI も毎月付与にならないかなぁ）

プランの確認ができたので、早速登録して使ってみましょう。

Get Started

Start for free などからリンク開くと以下のようなページが開きます。

日本語ページもあるのでそちらからも登録できます。

https://jfrog.com/ja/start-free/

クラウドプロバイダー（Select your cloud provider）

クラウドプロバイダーの選択が出てきて、ちょっと本当に無料の範囲でできるのかな？と不安になりますが、No Credit Card だし大丈夫だと信じて進みます。

（実際問題ない）
自分はどれもあまり詳しくないのですが、まだ多少知ってるという理由で Google Cloud を選択しました Google 選んだつもりでしたが AWS を選んでました（2021/08/02 追記）。

サーバーの詳細（Server Details）

お客様詳細情報（Create your Credentials）

メールアドレスとパスワードを記入します。

パスワードは大文字・小文字、数字、記号を含める必要があります。

ユーザー詳細（User Details）
氏名を入力します。英語（アルファベット）で記入する必要があるようです。

PROCCED して完了。

問題がなければ「JFrog Free Subscription Activation」というタイトルでメールが来ます。
「Click here to activate your JFrog subscription」のリンクを開いてアクティベートします。

待ちます。

完了したらログインできるようになるので Login しましょう。
ログインしたら↓のようなダッシュボードが開くと思います。

セットアップ

JFrog には Pipelines の他にもプロダクトがありますが、今回使うのは Pipelines です。

まずは左側メニューから「Pipelines」を選択。「Clik to Activate」をクリック。

待ちます。

君はそのページ見れないよ。とエラーっぽいメッセージが出ますが、admin なはずなのでそんなわけはありません。
おそらくまだセットアップ中なのでしょう。待ちます。

・・・zzz

一晩寝かせたことでアクセスできるようになってました。（少し時間がかかると思ったほうがよさそうですね）
※一度ログアウトしてログインし直すと見えるようです（2021/08/02 追記）
Pipelines が使えるようになったので設定の続きをしていきます。

JFrog のドキュメントに「QuickStart Guide: JFrog Cloud - JFrog - JFrog Documentation」があるのでそちらを参考に進めます。

今回は Pipelines だけまずは使いたいので Step 2/3 はスキップして「Step 4: Define a pipeline」から始めます。

Artifactory を Integrations に追加

※成果物を特に扱わない、パイプラインを試してみるだけ、という場合は飛ばして OK

先に、Artifactory 用の API Token を JFrog の User Profile から払い出しておきます。
右上のユーザーメニューから「Edit Profile」を開き、ログインパスワードを入力して Unlock します。
Unlock すると操作できるようになるので「Authentication Settings」の「Generate API Key」をクリックします。

API キーが生成されたら、コピーしておきましょう。

つづいて、「Administraion」タブの「Pipelines」から「Integrations」を開き、右上の「+ Add an Integration」をクリックします。
Pipeline から利用するので「Usage」は Pipelines を選択。

名前は任意、「Integration Type」に Artifactory を選択します。
URL と User はデフォルトのままで良いと思います。
API Key に先程コピーしたものをペーストし、「Create」をクリックして完了です。

「Assign Pipelines to this Integration」はとりあえず Any で OK です。制限かけたい場合はチェックを外すと許可する source を選択できます。（画像にはいくつか source がありますが、現時点ではまだ source 登録してないので空っぽだと思います）

GitHub を Integrations に追加

次に GitHub を Integrations に追加します。
Artifactory と同様に、右上の「+ Add an Integration」をクリックします。
Pipeline から利用したいので「Usage」は Pipelines を選択。
名前は任意、「Integration Type」に GitHub を選択します。
最後に GitHub のパーソナルアクセストークンを作成して入力したら「Create」ボタンを押します。

Node Pool にノード追加

次に実行環境を用意しておく必要があるので登録します。
「Administraion」タブの「Pipelines」から「Node Pools」を開き、右上の「+ Add Node Pool」をクリックします。
下記画面のようになるので、名前の入力とイメージを選択します。
選択可能なイメージは Ubuntu/CentOS/Windows があります。

Node Limits は同時に起動可能なノード数の制限です。1 にした場合、このノードを使うジョブは 1 つずつ順番に実行されます。

Node Idle Interval はノードが停止するまでの時間です。
ノードは常に起動しているのではなく必要なときに起動します。
commit でジョブを実行する場合、インターバルが短いと都度都度ノードを起動することになるので、使い方に合わせて時間を調整しましょう。
ちなみに、有料プランでは静的ノードが使えます。

Pipeline source を追加

ノードの準備ができたらパイプラインを登録しましょう。
「Administraion」タブの「Pipelines」から「Node Pools」を開き、右上の「+ Add Pipeline Source」をクリック、「From YAML」を選択します。

パイプライン YAML を PR で追加したいので、「Multi Branch」を選択します。
「SCM Provider」は上で追加した GitHub のインテグレーションを選びます。
ほどなくリポジトリが選択可能になるので、目的のものを選択。
「Exclude/Include Branch Pattern」で YAML の Sync をするブランチの対象を制御できます。
最後に、YAML ファイルのパスを入力して「Create Source」しましょう。
（JFrog では YAML ファイルは任意の場所におけます。）

この時点ではまだ YAML がないので Sync は失敗します。

Pipeline を記述

パイプラインを記述します。
ドキュメントや、サンプルプロジェクトがあるのでそちらを参考にすると良いと思います。

移行後の iutest の YAML はこちら
https://github.com/srz-zumix/iutest/blob/master/jfrog-pipelines.yml

他の CI サービスとちょっと使い方に特徴があるので、その点だけ説明します。

チェックアウトパス

他の CI サービスではソースとなるリポジトリがカレントディレクトリにチェックアウトされることが多いと思いますが、JFrog Pipelines は複数リポジトリをソースにできるので、それぞれのワークスペースにチェックアウトされます。
このパスは「res_{{ resource_name }}_resourcePath」環境変数で取得できるので、ディレクトリを移動してからビルドやテストを行いましょう。

シークレット環境変数

環境変数は「Generic Integration」を追加することで使用できます。
こちらも上記チェックアウトパスと同様に「int_{{ integration_name }}_{{ env_name }}」のような環境変数になっているので注意してください。

例：https://github.com/srz-zumix/ci-specs/blob/1f64ac66f635b6ffeee06db45ae1210bf0fd1c64/jfrog-pipelines.yml#L28

GitHub ステータス更新もパイプライン記述が必要

他の CI サービスでは自動的に GitHub のコミットステータスを更新してくれますが、JFrog Pipelines ではパイプラインに明記しないといけません。（仕組み上しかたがないですが）
やり方は簡単で、「update_commit_status {{ resource_name }}」で現在の execution の状態に合わせてステータスを更新してくれます。
より細かな制御も可能です。詳しくはドキュメントを参照してください。
Sending Build Status to Source Control - JFrog - JFrog Documentation

Sync

パイプラインをコミットしたら Pipeline Sources で Sync が成功するか確認しましょう。
「Pipelines」>「Pipeline Sources」を開き、Status を確認してください。
パイプラインの記述に不備がなければ「Success」になっているはずです。
問題がある場合は一番右のログボタンから何が原因か確認して修正しましょう。

パイプライン実行

Sync できたらいよいよ実行可能です。
PR トリガーは Sync が成功したあとから有効になるので、最初は手動でトリガーするか、空コミットを push するかで起動しましょう。
（パイプライン修正 PR をして修正されたパイプラインで動作を見たいときも同様。改善したい）

手動でトリガーする場合は、「My Pipelines」から実行したいパイプラインを選択し、そこからトリガーするステップを開いて実行するだけです。

結果は履歴から確認できます。

Next

ここまでで JFrog Pipelines でジョブを実行できるようになったと思います。
JFrog Pipelines は他の CI サービスと使い勝手が少し違います。
Jenkins など他の CI と連携したり、複雑なジョブを構築したりしていくことができるようです。ドキュメントがまとまっているのでそちらを参考に挑戦してみてください。
https://www.jfrog.com/confluence/display/JFROG/Get+Started

バッジ

CI サービス恒例のバッジですが、残念ながら見つけられませんでした。
バッジを付ける方法が見つかったら、このブログで紹介します。

最後に

Shippable が終了したのは残念でしたが、JFrog Pipelines で同じように CI できそうです。
また、Shippable のころに使いこなせなかった Assembly Line が使えるようになって、ドキュメントって大事だと改めて気付かされました。

今回は以上。ではでは。

[Shippable] CentOS free plan に変更した

Pricing | Shippable


Ubuntu/CentOS は Free Plan があるので、両方使えるかな？と思ったがそうではなかった。
という話。


プランの変更は 「Settings」 の 「Billing」 にあります。
ここで SKU を追加できるのですが、SKU を２つにすると請求額が $0 じゃなくなります。



SKU が１つ、かつ「Enable unlimited private repo builds」のチェックを外すと $0 になります。
（Size は L 、キャッシュもなし）



つまり、フリーで使う場合は OS は１つしか選べないようです。

残念。。
というわけで、Ubuntu から CentOS に変更しました。

今回は以上です。

[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 サービス比較（定期実行編）

SCM との連携で更新タイミングで CI が実行されるサービスがほとんどですが、ちょっと定期的に実行させたいことがあり調べたのでまとめました。

以前まとめた情報はこちら
※まとめた時期が結構前なのでもう腐った情報になってるかもしれませんので注意！

ブログズミ: 無料で使える CI サービス比較
ブログズミ: 無料で使える CI サービス比較（Artifacts）

	AppVeyor	Circle CI	Codeship	drone.io	Magnum CI	semaphore	Shippable	Snap CI	Travis CI	Wercker
定期実行	◯	△	×	×	△	◯	△	◯	◯	◯

Appveyor

Build configuration - AppVeyor
Syntax はこちら Crontab Expression · atifaziz/NCrontab Wiki
Jenkins と同じ感じです。

Circle CI

Circle CI では定期実行する仕組みはありませんが、外部から実行開始することができます。
Nightly Builds - CircleCI
なので、何かしらの cron サービスと組み合わせれば定期実行は可能というわけです。

実際に定期実行させた例が Qiita にありました。

CircleCIを使ってbundle updateを定期実行する - Qiita

Codeship

API | Codeship Documentation
API が用意されていて、リスタートはできそうなのですが、新規に実行する方法が？だったので×にしました。

Magnum CI

Circle CI と同様に外部から実行開始できるので △ にしました。
https://magnum-ci.com/docs/integration

Semaphore

Project Settings に Build Scheduler があります。
Scheduling builds - Semaphore

Shippable

API を利用して外部から実行開始できるので △ にしました。
Shippable API for Projects - Shippable Docs

Snap CI

Scheduling and skipping builds | Snap CI Documentation, FAQ, and Troubleshooting
プロジェクトのページに「Build Schedule」があるので、そこから設定できます。

Travis CI

Cron Jobs - Travis CI

Please note that cron jobs are not enabled by default. Set “Build pushes” to on in your settings, then ask us to unlock this feature for your repository: support@travis-ci.com

デフォルトでは使えません。サポートチームに連絡する必要があるようです。

Wercker

Introducing Cronetes
こちらにやり方が書いてあります。が、ちょっと面倒くさそう。

最後に

ここで×としたサービスもただ単に機能を見逃しているだけで使えるかもしれません。
また、この情報記事投稿前の情報です。今後サービスは拡充していくと思いますので、公式ページで最新の情報を確認するようにお願いします。


さて、これで一旦調べ終わったので、どこかで定期実行ジョブを作りたいと思います。
では、今回は以上。

[C++] Shippable + Wandbox でテストしてテスト結果の集計までを行う

ブログズミ: Shippable + Wandbox で C++ の CI 環境構築
以前、上記記事で Shippable + Wandbox で C++ のテスト実行をするようにしたのですが、iutest v1.15.2(v1.15.1) で Wandbox でのテスト結果を xml 出力できるように対応したので、テスト結果の集計まで行うようにしました。

iutest + Wandbox

iutest の Wandbox 実行ツールを利用することで、iutest で記述されたテストコードを Wandbox 上で実行できます。iutest v1.15.2(v1.51.1) では、このツールに xml 出力機能が追加されました。

iuwandbox.py test.cpp --xml test_result.xml

--xml コマンドラインオプションを付けると、指定のパスにテスト結果の xml を出力します。

Shippable でテスト結果 xml の集計

Shippable では junit 形式のテストレポートが集計できます。
Shippable Build Configuration - Shippable Documentation

方法としては簡単です。
shippable/testresults フォルダを作成して、そのフォルダに xml ファイルをコピーするだけです。

e.g.

build:
  ci:
    - mkdir -p shippable/testresults
    - nosetests python/sample.py --with-xunit --xunit-file=shippable/testresults/nosetests.xml

詳しくはドキュメントを確認してください。

iutest の場合

iutest では以下のようにテストをしています。
（Shippable だけでなく Wercker + Wandbox でも同様の方法でテストを実行しています。）

language: python

python: 2.7
cache: true
parallelized_test: true

branches:
  except:
    - gh-pages

install:
  - pip install requests

before_script:
  - export PYTHONDONTWRITEBYTECODE=1
  - make -C tools/fused
  - mkdir -p shippable/testresults

script:
  - cd tools/wandbox
  - python ./iuwandbox.py --list_options ${WANDBOX_COMPILER}
  - python ./iuwandbox.py ../../test/syntax_tests.cpp -c ${WANDBOX_COMPILER} -f"-DIUTEST_USE_MAIN=1" --default --boost nothing --encoding utf-8-sig --expand_include --verbose --xml ../../shippable/testresults/test_result.xml

env:
  matrix:
    - WANDBOX_COMPILER=gcc-head
    - WANDBOX_COMPILER=gcc-6.1.0
    - WANDBOX_COMPILER=gcc-5.3.0
    - WANDBOX_COMPILER=gcc-5.2.0 # travis (5.2.1)
#    - WANDBOX_COMPILER=gcc-5.1.0 # wercker
#    - WANDBOX_COMPILER=gcc-4.9.2 # circle ci
#    - WANDBOX_COMPILER=gcc-4.9.1 # wercker
#    - WANDBOX_COMPILER=gcc-4.9.0 # wercker
#    - WANDBOX_COMPILER=gcc-4.8.2 # wercker
    - WANDBOX_COMPILER=gcc-4.8.1
    - WANDBOX_COMPILER=gcc-4.7.3
#    - WANDBOX_COMPILER=gcc-4.6.4 # drone
    - WANDBOX_COMPILER=gcc-4.5.4
#    - WANDBOX_COMPILER=gcc-4.4.7 # snap ci
    - WANDBOX_COMPILER=gcc-4.3.6
    - WANDBOX_COMPILER=clang-head
#    - WANDBOX_COMPILER=clang-3.8 # travis ci
#    - WANDBOX_COMPILER=clang-3.7 # circle ci / wercker
#    - WANDBOX_COMPILER=clang-3.6 # semaphore
#    - WANDBOX_COMPILER=clang-3.5 # c++config.h not found
    - WANDBOX_COMPILER=clang-3.4
#    - WANDBOX_COMPILER=clang-3.3 # wercker
#    - WANDBOX_COMPILER=clang-3.2 # wercker
#    - WANDBOX_COMPILER=clang-3.1 # wercker
    - WANDBOX_COMPILER=clang-3.0

after_success:
  - echo OK
  
notifications:
  email:
    on_success: change
    on_failure: always

最後に

Wandbox でのテスト結果を xml ファイルに出力できるようになったことで、テストツールとして完成されてきた感じがしてきました。
iutest のテストとしてはかなり便利に使わせていただいています。
もう個人的には最強の環境になったかなと思います。

ただ、複数ファイルのコンパイルができない（ヘッダーは可能）ので、まだちょっとプロダクトのテストをするとまでは至っていませんが、ヘッダーオンリーなライブラリーとかであれば、かなり良いテスト環境になるのではないでしょうか。