ラベル Codefresh の投稿を表示しています。 すべての投稿を表示
ラベル Codefresh の投稿を表示しています。 すべての投稿を表示

2019年9月24日火曜日

[Codefresh] PR comment に特定の文字列があったらトリガーする

Codefresh の Free Plan では1ヶ月のビルド数制限があるため、すべてのブランチや PR に対してテストを実行しないようにしています。
が、たまにこの PR でも Codefresh のテスト回したいなーというケースがあったので、PR の comment に反応してテストが実行されるようにしてみました。

(※ Codefresh の Free Plan はちょっとよくわかってないことがあるので、ビルド数制限なにそれ?な場合もあるかも。詳細:「ブログズミ: [Codefresh] Free Plan の内容がよくわからない・・」)

設定の仕方
まず、プロジェクトのパイプライン設定を開きます。
右側に「TRIGGERS」のタブがあるのでそれを開きます。


「ADD TRIGGER」を2回押します。


「GIT」を選択して、次へ。


「TRIGGER BY」は「Pull request comment added」のみを選択。


「PR COMMENT(REGEX EXPRESSION)」に特定の文字列を識別する正規表現を入力します。
今回は「run codefresh」がコメントに含まれていたら、TRIGGER されるようにしてみました。

設定は以上です。

キックしてみる
PR に「run codefresh」とコメントすると、ビルドが始まります。(CI 失敗してるのは気にしないでください)
テストリポジトリはいつもの iutest です。


まとめ
フリープランで CI を使わせていただていると、ビルド制限で困ることが多いです。
ブランチフィルターなどで実行数を減らすことができますが、逆に、フィルターアウトされるブランチでもテストを実行したいケースがでてきます。

そのようなケースに備えて、コメントトリガーに対応しておくと CI Life がより快適になります。
今回は Codefresh で行いましたが、他の(コメントトリガーできる)CI でも随時対応していきたいと思います。

では。





2019年9月17日火曜日

[Codefresh] Free Plan の内容がよくわからない・・

トップページの Pricing には Unlimited build / 1 small resource となっているが、
自分の今の Plan を見ると Free Plan ではあるが、120 build/month でマシンリソースはおそらく Medium resource になっている。

Doc:


My Plan:



120 build/month の制限は正直きついが、Samll resource になるのもきつい・・・

どっちがいいかってのはないのだが、正しい状態なのかよくわからないので正解が欲しい。
それに合わせて、パイプライン調整するので・・・

2019年7月31日水曜日

[Codefresh] Parallel 実行してみた

Codefresh で並列実行が使えるようになっていたので試してみました。
Use parallel steps in your Codefresh pipelines - Codefresh
無料プランでももちろん並列実行できます。
試してみた結果
iutest で試してみた結果がこちら。
もともとしていた、「benchmark test」に加えて、gcc の複数バージョンの docker コンテナでテストを実行しています。


YAML はこちらです。
version: '1.0'
stages:
  - checkout
  - build
  - test

steps:
  main_clone:
    title: Cloning main repository...
    type: git-clone
    stage: checkout
    repo: '${{CF_REPO_OWNER}}/${{CF_REPO_NAME}}'
    revision: '${{CF_REVISION}}'
  BuildingDockerImage:
    title: Building Docker Image
    stage: build
    type: build
    image_name: srz-zumix/iutest
    working_directory: ./
    tag: '${{CF_BRANCH_TAG_NORMALIZED}}'
    dockerfile: ./tools/docker/Dockerfile
  RunningUnitTests:
    type: parallel
    stage: test
    steps:
      BasicTest-gcc9: &basic_test
        title: Running Basic Tests - gcc9
        image: gcc:9
        environment:
          - OUTDIR=gcc9
        commands:
          - mkdir test/${OUTDIR} || true
          - make -C test clean
          - make -C test test
      BasicTest-gcc8:
        <<: *basic_test
        title: Running Basic Tests - gcc8
        image: gcc:8
        environment:
          - OUTDIR=gcc8
      BasicTest-gcc7:
        <<: *basic_test
        title: Running Basic Tests - gcc7
        image: gcc:7
        environment:
          - OUTDIR=gcc7
      BenchmarkTest:
        title: Running Benchmark Tests
        image: '${{BuildingDockerImage}}'
        working_directory: IMAGE_WORK_DIR
        entry_point:
          - /bin/sh
          - /codefresh/volume/cf-generated/unit_test_script
        create_file:
          path: /codefresh/volume/cf-generated
          name: unit_test_script
          content: |-
            cd /codefresh/volume/iutest
            cd test
            make -C benchmark
            make bench
    on_success:
      metadata:
        set:
          - '${{BuildingDockerImage.imageId}}':
              - CF_QUALITY: true
    on_fail:
      metadata:
        set:
          - '${{BuildingDockerImage.imageId}}':
              - CF_QUALITY: false

※執筆時現在は構成が異なってます。
※さらに使ってみてどうだったのかは別途書きたいと思ってます。

やり方
上記の YAML を例に説明していきます。
詳細は公式のヘルプを見てもらったほうが良いと思います。
といっても基本的には type を parallel にするだけなんですけどね。

下記のように、type: parallel にしたら steps: 以下に並列実行するステップを書くだけです。
RunningUnitTests:
    type: parallel
    stage: test
    steps:
      BasicTest-gcc9: &basic_test


ハマったこと・感想など
以下は、導入してみて躓いたところと感想を書いていきます。
git-clone したパスは共有
並列コンテナで同じ場所を使います。
なので、作業が競合するような場合は注意が必要です。

iutest でも、ビルド結果の出力先が同じだったため問題になりました。
各並列コンテナごとにワークスペースを用意するなどしたほうが良さそうです。

キャッシュ
キャッシュがあるので、クリーンビルドを想定しているとハマるかもしれません。
https://codefresh.io/codefresh-news/parallel-pipelines/
Codefresh runs a git reset and a git clean in your project repository everytime a pipeline starts. This means that all artifacts that you wish to be cached should be in your .gitignore file. A common example would be the node_modules folder. If you don’t place it in .gitignore, it will be deleted at the start of each build making it much slower.
git reset; git clean を行うので、.gitignore で無視指定されているものは残ったままになります。

iutest ではたまたまテストのビルド結果が .gitignore にかかれていたため、キャッシュされていました。
これのおかげで爆速でテストできてました。
ただ、今は clean ビルドするようにしてます。
(※現在はどの程度のテストが並列でできるか検証しているので、ゆくゆくはキャッシュ使っていきたい)


明示的にクリーンビルドをしてあげる、またはキャッシュを利用してビルド速度を上げるなど、使いみちに合わせた運用が必要です。

Join ができる

まだ使ってないんですが、Join ができるのはかなり嬉しい
wercker で join ができないのがつらくてな・・・


最後に
(なぜか)、フリートライアル中なので今のうちにいろいろ試してみたいと思います。
また、Free Plan になったときのことも考えて検証していく予定。
(すでに、SMALL RESOURCE キツイ・・・となってるので頑張る予定・・・)

2018年8月14日火曜日

依存ライブラリの GitHub を Travis CI で定期的に監視して DockerHub Automate Build を実行する(+ Codefresh ジョブを Trigger)

目的
開発中のソフトウェアがなんらかのソフトウェアに依存しており、その依存しているソフトウェアの最新の状態を常に追いたい。
具体的には、筆者が開発中の C++ テスティングフレームワーク iutest は、Google Test との互換性のために常に Google Test の最新の状態と互換性テストを行っています。

iutest では Travis CI や Circle CI といった CI サービスを利用して、変更があるたびにテストが行われる環境が整っています。
しかしながら、iutest は毎日更新があるわけではなく、最近は開発スピードも落ちているので数日変更がないこともザラです。
そのため、その間に Google Test に更新があって、いつの間にか互換性テストが通らない状態になっていたりすることがありました。

長くなりましたが、今回のゴールは
・ Google Test の更新を定期的に監視して
・ 変更があったら Docker image を更新
・ Docker image が更新されたら互換性テストが実行される
です。

構成

* 監視されるリポジトリ→ google test
* 監視するリポジトリ→docker-googletest


DockerHub Automate Build
DockerHub で Google Test の入ったイメージを作成するジョブは以下の記事で作成したものを使用します。
ブログズミ: DockerHub Automated Build を使ってみた

今回はこちらの latest イメージを毎日最新の状態にするのが目的です。
DockerHub に定期ビルド機能があればそれで良かったのですが、ないので別のサービスで実現させます。

次へ進みます。

CI の設定
必要なのは、定期ビルドが可能で、GitHub に push できるサービスです。
今回は Travis CI を使いましたが、選んだ理由は最近 GitHub push をここでやったからです。
実際使用している yml はこちらです。こちらを見ながら説明していきます。
dist: trusty
sudo: false
language: cpp

before_script:
  - git clone https://github.com/google/googletest.git ./gtest
  - cd ./gtest
  - git rev-parse HEAD > ../gtest.hash
  - cd ..

script:
  - git checkout master
  - git add -A
  - git commit -m "update head [ci skip]" || true
  - git push https://${GITHUB_TOKEN}@github.com/${TRAVIS_REPO_SLUG}.git ${TRAVIS_BRANCH}

env:
  global:
    secure: OdxIMgUsZyGyOOnV49MkJW5KrGVW7KyCwUkWgC88YmdJPCtNJ9fF69TcM8ek252+yFJsfpUrZaNH6A6igRUreveoA161zy+fsD9mMqIrrthFWx5S2fzBCsiCobreduicCDt5EJ1p8N/QlpEB2ZeUbYWqZf37r5BfYOJI86521qYMiI30IAwxsjPqhcbyFRisTKosd3LlEo4Y+K3qLgdCKEAhsaOrtIgrbxz7cM2sKh8lYTquP1XPtFwsmCoELyeRAVEJbSwADcaw3011S/NB8Kn9+sd878dxBK2iDxSilVz+3XIz+/sKZHNFGug5i2UA2yS8ZfWQhZjF9tiF3quTAzqAFzTbxDKswMLHgD8oI0saIVDmXNxc6PXLYXEjx5p5Z3E1iTb09hcp5wOqJOz+Ynie7EkVyUO2DKJhjeuGffoPxjK35L4c7/ufTNskT3+vUnGG/2U9XMA3OeXoCLp+V7BRgkZtpVZssA4viTWXPG4byaEQaiAMK0ArVOesa86m21xuKSLhdNqQ/WRT8g/eEVqs4XrT1ogIW1nsjYHv6Xmcs8QD2iQxDdWHx4pQojod8lSdwn/HFqXTOf6KxqTk5mpJmcd2ZxyDocynTEtvtt+uNtVyJh+gXt06eGD/rlbV1eC+Uc5FMQE2P1Uya3RdaZvMZjYGzVcZMrPcv/gklbY=

Google Test の更新検知
まずは肝心の Google Test (監視される側)の更新検知方法です。
いろいろやり方はあると思いますが、今回は push があるたびにトリガーするのではなく、定期的に(1日1回とか)更新があったかどうかがわかればいいので、定期ビルド実行したときの Google Test の HEAD の commit hash を自分のリポジトリに保存する方法を取りました。
更新があれば diff が出るので、これをトリガーにしています。
これを行っているのが、brfore_script の部分になります。

更新を push して他サービスをトリガーする
最新の commit hash を取得したら、それを commit/push します。
docker-googletest (監視する側)のリポジトリが更新されるので、この push をトリガーに他のサービスをキックすることができます。
監視する側のリポジトリは自身の管理下のはずなので、ここから先は自由にやることができます。

ただし、ここで注意点があります。
Travis CI のジョブもこの push をトリガーにより実行されてしまいます。
すると、この Google Test 監視ジョブが再実行されてしまい、最悪の場合は無限にジョブをキックし続けます。(監視される側の更新が止まれば止まるが、最低でも1回無駄にジョブが走る)

定期ビルド設定
最後にこれを定期ビルドするようにしましょう。
こちらは Travis CI の Web ページで設定します。
プロジェクトのページの「More options」から「Settings」を開くと、一番下に Cron Jobs があります。



DockerHub Automate Build の設定
特に必要ありません。
Google Test が更新されると、commit hash が更新されて push されるのでそれをトリガーにビルドが実行されます。

おまけ
ここまでで、当初の目的の GitHub の監視と、変更検知し DockerHub のビルドを回す、という目的は達成していますが、ついでなので、その先も紹介します。

Slack 通知
通知系は定番ですね。詳しくは過去にも記事にしているので、そちらを見てくださいmm
ブログズミ: Dockerhub Automated Build が終わったら Slack に通知する

docker-googletest の通知仲介は Zapier を使ってますが、今は Integromat もおすすめです。
そちらも記事にしているので、よければご覧ください。私的には、今後は IFTTT/Zapier よりも Integromat をメインに使っていくつもりです。

* 「ブログズミ: プレビュー "(WIP)依存ライブラリの GitHub を Travis CI で定期的に監視して DockerHub Automate Build を実行する(+ Codefresh ジョブを Trigger)"
* 「ブログズミ: CIサービスの結果を Twitter に投稿する

Codefresh のジョブを Dockerhub からの Webhook で実行する
Codefresh のトリガーに Webhook トリガーを追加します。
プロジェクトの「Pipeline」ページの真ん中あたりに「Triggers」があるので、そこで追加していきます。


「ADD TRIGGER」ボタンを押すと以下のようなウィンドウが出てくるので、「REGISTRY」を選択して次へ


続いて、「REGISTRY PROVIDER」を Dockerhub に、「NAMESPACE」と「NAME」はトリガーを発行したい Dockerhub のリポジトリを設定してください。
「ACTION」は Image 更新したときにしたいので、 「Push Image」を選択。docker-googletest にはバージョンごとのタグが複数あり、ビルド対象にしたいのは latest だけだったので、「Configure filter」を設定しました。
入力完了したら、「NEXT」ボタンを押します。


四角く囲ったところに、Webhook の URL と鍵が発行されますので、Dockerhub の Webhook に設定します。(下線のリンクから飛べます)


Dockerhub の Webhook 設定を開いたら、${ENDPOINT}&secret=${SECRET KEY} を入力します。(↑の黄色で囲った部分に出てるアドレスです)



これで完成です。


最後に
外部の依存・関係しているプロジェクトが、いつの間にか更新されていて動かなくなっていた。なんてことはよくあることなので、定期的に監視しておくのはいいことだなと思いました。
あと、この仕組がわりといい感じに組めた気がするので、iutest の Google Test 互換性テストを外部に出す対応に利用しようと思います。
では。

2018年3月19日月曜日

[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 ください。
では。

2018年2月19日月曜日

[CI] Codefresh の Use YAML from URL が便利だった

CI サービスのジョブの定義といえば YAML か WEB 上での設定がほとんどだと思います。
それぞれにメリットがあり、YAML の場合は as Code でコードと CI が紐づく点、WEB の場合は変更が容易な点でしょうか。

WEB 上で設定可能、かつ、その設定を YAML にエクスポートできるサービスもあります。
個人的には、この形がベストかなーと思っていて、
CI のステップを定義していくときはトライアンドエラーで何回も繰り返すことが多いので、WEB 上ですぐに変更・実行できるメリットが大きいです。
さらに、確定したステップを YAML としてエクスポートすれば as Code の恩恵も受けられます。
(最初から YAML 書くのはハードル高かったりしますしね)

Use YAML from URL
さて、先日 Codefresh を見直す機会ちょうどあり(その時の記事→「[CI] Codfresh で git clone に失敗した場合にすること」
そのときに気づいたのですが、Codefresh では「Use YAML from URL」で任意の URL を指定して、そこの YAML を使ってステップ定義することができます。
これは便利だなーと思いました。(公式ヘルプ

この機能を使うことで、Gist にある YAML を使うことができるようになります。
(履歴を残しつつ、リポジトリを汚さずに yaml の編集が容易にできるようになるので、個人的に嬉しい)
公式ヘルプでは、複数のパイプラインで1つの YAML を使う方法として紹介されています。
複数リポジトリで同じ YAML を使うケースでは管理が1つになるので、これまた便利です。

やり方
では、やり方を見ていきましょう。といっても、やることは簡単で、Gist で YAML を用意するのと、Codefresh の設定に Gist の URL を入れるだけです。

まずは、Gist で YAML ファイルを作成します。
作成したら、「Raw」ボタンを押します。


開いた URL を Codefresh に設定するのですが、ここで開かれるのはリビジョンを含んだ URL なので、そこの部分を削除した URL を使うと変更に追従できるようになります。

https://gist.githubusercontent.com/srz-zumix/38581f1437aa4239fcb7f7b2580cb33c/raw/0cfe000b27f15eb140bb92f3fa02215d56966303/iutest_codefresh.yml

https://gist.githubusercontent.com/srz-zumix/38581f1437aa4239fcb7f7b2580cb33c/raw/iutest_codefresh.yml


URL をコピーしたら、Codefresh の設定を変更しましょう。
「Pipelines」の「WORKFLOW」で YAML を選択し、「Use YAML from URL」をチェックします。

「YAML URL」にアドレスを入力します。先程コピーした URL を貼り付けましょう。(今回は GIst でしたが、yaml ファイルが取得できれば他のアドレスでも可能です)
設定を保存したら、完了です。

最後に
この機能便利なので、他のサービスでも使えたらうれしいですね。特に設定が YAML のみで WEB 上で設定できないサービスにあると嬉しいです。
(inline YAML より対応もしやすそうだし)
Codefresh は今無料枠を使い切ってしまって何もできないので、回復したらこの機能を積極的に使っていこうと思います。

今回は以上です。
では。

2018年2月13日火曜日

[CI] Codfresh で git clone に失敗した場合にすること

.gitattributes で EOL の設定を変えたところ、Codefresh のビルドで git clone ステップ中にローカル差分が出た影響で更新に失敗していました。


他のサービスでは特に問題がなかったのですが、Codefresh でのみ発生した問題です。
(ちゃんと理解してないのですが…)Codefresh は Docker コンテナ上でビルドされて、これがキャッシュされているのが原因と思われます。

yaml の設定で対応できるかなーと探したのですが、どうやら yaml 設定ではできそうもなく、
手動ビルドしたときの設定で対応できそうだったので、試してみました。

Disabling codefresh caching mechanisms
まずは、キャッシュを無効にしたら直るかなと思ったので、そちらから試しました。
やり方は以下のヘルプに記載されています。
Disabling codefresh caching mechanisms

Pipelines タブの下部にビルドボタンがあるので、まずそこをクリックします。


ビルドするブランチとパイプラインの選択ポップアップが出てきます。そこに、「ADVANCED OPTIONS」があるのでクリックします。


開いたオプションの中に、「Ignore cache for build」があるのでチェックを入れ、ビルドを実行します。
これでキャッシュクリアした状態でビルドがされるはずです。


結果は失敗でした。。。


Restoring data from pre-existing image hangs on
続いて、キャッシュクリアの直ぐ下にあった、ボリュームのリセットを試してみました。
ボリュームのリセットについては、以下にヘルプがあります。
Restoring data from pre-existing image hangs on

手順は先程とほぼ同じです。「ADVANCED OPTIONS」を開くときに今度は「Reset pipeline volume」にチェックを入れて、ビルドを実行します。


結果、成功しました!


最後に
なかなか git clone のステップで失敗することはないと思いますが、参考になれば幸いです。
そして、数ヶ月後に自分自身がこの記事のお世話にならないことを祈ります。
(今回は .gitattributes をいじったことが起因なのでそうそう起こらないはず…)

では。

2017年4月17日月曜日

[CI] Codefresh を始めました



Codefresh というサービスを知ったので使ってみました。
(ちょうど Google Test の互換性テストを Travis CI から引っ越ししようかなと思っていたので、タイミングが良かった)
Codefresh は Docker 対応を売りにした CI サービスのようです。
が、個人的には Docker 使ったことがないですし、iutest のテストでも使う必要がないので、全くもって Codefresh の旨味を使うことがないです。
なので、Docker 的な話は公式サイトや以下のような記事を参照してくださいm(__)m


ともあれ、そこに CI サービスがあれば使うおじさんなので(もはや、手段と目的がごっちゃになってますが)始めて行きましょう。

Pricing
ちなみに Codefresh も (オープンソースであれば) 無料から始めることができます。
フリープランでは並列ビルドなし、Environment も1つだけです。


Environment
Codefresh ではビルドした Docker イメージ(Service)からコンテナを実行することができます。
この実行環境が Environment です。
フリープランだとこれが1つに限定されます。
今回は特に使わないので、省略します。

アカウント作成
アカウント作成をしていきましょう。
最初にログインアカウントとして Github or Bitbucket の選択をします。(今回は Github を選択)


権限要求されるので問題なければ許可しましょう。


アカウント名やメールアドレスが自動で入力されます。変更が不要であれば「NEXT」をクリック。


このあとアンケートが少しありますが、飛ばしてしまっても構いません。


これでアカウント作成は完了です。

サービスの作成
Codefresh では他の CI サービスでいうジョブのことをサービスと表現します。
やることは他の CI サービスとほとんど同じです。

まずは、リポジトリを選択しましょう。



リポジトリを選択したら、サービスを何で構築するかを「YAML」「Dockerfile」「Template」から選択します。
今回は「TEMPLATE」を選択。


プラットフォームの選択画面になるので、条件に合うものを選択します。
今回は「Ubuntu」を選択。


Dockefile が作成されます。
編集はあとでもできるので次に進んでしまって問題ないです。


これでサービスが作成できました。
「BUILD」ボタンを押して実行してみましょう。
テンプレートから変更していないので成功するはずです。



テスト
Codefresh では、作成した Docker image に対してテストを実行することができます。
テストは「Unit Test Script」に記述します。


特に難しいことはなく、コマンドを書いていくだけです。
これで iutest の CI 環境としては完成です。
Codefresh の特徴を活かすのであれば、このあと Launch するのがいいのでしょうが、iutesst はサービスではないのでここまでです。

最後にお約束のバッジ
バッジは「General Settings」のバッジをクリックすると Markdown テキストなどが得られます。




今回は以上です。では。