2018年5月24日木曜日

Travis CI から github に push する

「CI サービスでビルドした結果を github に push したい」そんなことってありますよね。
よくあるケースとしては、ドキュメントなどを github pages (github.io)に公開したい場合とかでしょうか。

今回は Travis CI の場合を紹介します。

前置き
本当は、Travis CI 以外も含めて GitHub へのデプロイ方法をまとめようと思ってましたが、
結局は ssh 鍵やアクセストークンを暗号化してリポジトリに置いておける CI サービスであれば、自分で git command を叩くことで実現可能です。
なので、まとめとしては大体のサービスが「できます」で終わってしまうのでやめました。
(CI サービスによって導入のしやすさは違うと思います。既存のステップがあるとか、管理方法とか、暗号化方法とか)

Travis CI
というわけで、Travis CIの場合です。

Travis CI の depoly ステップに Github Pages と Github Releases があります。
GitHub Pages Deployment - Travis CI
GitHub Releases Uploading - Travis CI
Pages が通常の push 、Releases はタグ付けができます。

要点としては以下な感じ

検証用リポジトリの設定はこちら
https://github.com/srz-zumix/ci-push/blob/master/.travis.yml
中身はこんな感じです。
dist: trusty
sudo: false

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

# TODO: add skip comment...
#deploy:
#  provider: pages
#  target-branch: master
#  skip-cleanup: true
#  github-token: $GITHUB_TOKEN  # Set in the settings page of your repository, as a secure variable
#  keep-history: true
#  on:
#    branch: master

env:
  global:
    - secure: t6d7HusMxzdZCXV5tGWQn0MA7aodeuK6bbKASqUuOyKUe8I+w3E3E+GKL3CyE32pGDuPGxw1NraOvVJ8uuBmJjwumyAHssR0BFGogPnbhQucl9N3eMz9BHU5j5bw/bGkmI2y+9ZsTb+9P7XtBrwC6/AbdcF/Wh0y7y32RLxda4836OvxOuuZDl+2OgPtkqyg+uKVh+6uRY+arUHOBUEjzjBBAN5/eoTqE0/HVu4YEgiq94ke0c2w2Sz+sK1yXUGrOIz5nTcMMSAwJdHaQpnBKs/5EzJCcHx5guH3Wn+XKS3LOqIxioz6wKPnkqqhFHiv83fGy9+lv67mUHcXfMDab5rm+jRJUHgZPX9sd4iAoz7ZQ3jxMW3/PWP7VJsv3SrrDjFvBH8tRzkqtVIFTmS4tGDZ2VzeYhKom4dA3CH/KCxprZJ+nCQ2TizMuNAezR1+GcZGIDc+AGILUxfPK82Z2CZtmhoOBEp8C7JN6bPNxfYYhU5rJo8dI+1HinX3JRdfW2zBlixxuIrfn2RWhuRzT4mZf7tP8EZV33wRa7W/eEKvUUfMGAzk8gEVhLKfGaGZU7IfhrwdmRgRsKX0Y53wfEjqt8tsWW3FFHfuLjO75lEJY381VJREvC76FCOa2AT4B6A6dzz/5376K/08GChfBcN1vHAxj5FxhJ1dwt4iTZE=

まとめ
gh-pages ブランチへのデプロイであれば簡単。アクセストークンを使いたくない…とか、master の docs を更新したいんじゃーとなると自分で書くことになる。
ローカル作業は必要ではあるが、ドキュメントもわかりやすく簡単。



2018年5月8日火曜日

DockerHub Automated Build を使ってみた

Google Test の過去のバージョンとの互換性テストのために、各バージョンの Google Test 環境を構築する必要が出てきました。
どこかしらの CI サービスで、毎回 git clone とか wget とかしてもよかったのですが、今回は DockerHub に各バージョンのコンテナを登録してそれを使うようにすることにしました。



DockerHub に Sign Up
まずはサインナップしましょう。
https://hub.docker.com/ にアクセスし、以下の手順で Sign Up しました。


トップページで好きなのアカウントIDとメールアドレス、パスワードを入力して、Sign Up します。



ログイン画面が出てきます。Sign Up は以上です。
登録したメールアドレスに確認メールが飛んでいるはずなので Confirm もしておきましょう。
 



ログインすると以下のようなダッシュボードが出てきます。


Github と連携する
つづいて、今回 Dockerfile の管理を GitHub で行っていますので DockerHub と GitHub を連携させます。
アカウントの Settings にある「Linked Accounts & Services」を開くと以下のような画面になるので、「Link GitHub」を選択します。


「Public and Private」か「Limited Access」の選択画面が開きます。
今回は、特に理由もないのでオススメの「Public and Private」を選びました。(Limited だと手動でなにかしないといけなさそうだったし)


「Select」ボタンを押すと連携されます。
完了すると以下のように GitHub のアカウントが表示されると思います。


自動ビルド設定
では、本丸の Automated Build をセットアップしていきます。

メニューバーの「Create」から「Create Automated Build」を選択します。


Github か Bitbucket か選択肢が出てくるので、目的の方を選択します。
(今回は GitHub)


リポジトリ一覧が出てくるので目的のリポジトリを選択します。


名前や Visibility を設定できますが、デフォルトのままで OK です。
簡易説明も任意で入力できます。(あとで変えられます)


「Create」ボタンを押して以下の画面になったら作成完了です。


では、次にビルドしていきましょう。
ビルドしてみる
Build Settings に入るとすでにトリガーが1つ設定されていますので、「Trigger」ボタンを押してビルドしてみましょう。
(もちろんリポジトリにはビルド可能な Dockerfile が push されている必要があります)


「Build Details」に移動すると、トリガーしたビルドの進捗が確認できます。


無事にビルドが成功すれば「Success」と表示されます。

使ってみて…
さて、ここからは使ってみた感想を書いていこうと思います。
パラメタライズドできない?
Docker イメージをつくるに際に latest の他に複数のバージョンを用意したいことがあると思います。また HogeHoge-alpine みたいなイメージをよく目にしますが、このようにベースイメージを変えたい場合もあると思います。
その場合、ビルドジョブ側でバージョンをパラメタライズドして、1つの Dockerfile から複数のバージョンを作れると便利だなーと思ったのですが…どうやらその機能はないもよう。

「Build Settings」でブランチや Dockerfile のパスを指定、タグ名も指定できるので、ブランチを増やすか、Dockerfile を増やせば対応できそうです。

バージョンブランチを作って各バージョンのイメージを作成する
今回は、Google Test の各バージョンの環境を作ることが目的でしたので、Google Test のバージョンごとにブランチを作成して、ブランチへの push をトリガーにビルドが走るように構築しました。
最終的な設定はこちら。



ここでのポイントは master 指定したトリガーと、指定なしのトリガーです。
master のトリガーは latest タグでビルドします。
指定なしのトリガーはブランチ名をタグにしてビルドします。

タグ名のところを空欄にすることで、ブランチ名がタグになる仕様です。

1つのブランチで複数のイメージを作成する
続いて、HogeHoge-alpine のように alpine イメージを作成する対応をしたいと思います。
ブランチを分けて対応することもできますが、今回ブランチは Google Test のバージョンで切って、alpine などのバリエーションはブランチ内の別 Dockerfile で対応することにしましたので、以下のような設定にしました。



Dockerhub では、ビルドに使用する Dockerfile のパスを指定することが可能です。
今回は、alpine 版の Dockerfile をリポジトリの alpine ディレクトリに置いて、そのパスを指定しています。

タグ名ですが、master の場合は明示的に latest-alpine としています。
バージョンブランチの方ですが、タグ名の設定ではブランチ名を {sourceref} で参照できるので {sourceref}-alpine のように後ろに -alpine がつくように設定しました。

Unexpected error...
さて、ビルド構成ができたので Google Test のイメージを作っていたのですが、たまに謎のエラーでビルドが失敗していました。
issues とか見てるとすごく不安定な時期・タイミングがあるみたいで、こちらではどうしようもない感じでした・・・
https://github.com/docker/hub-feedback/issues/1203

リビルドがめんどくさい
さて、上記理由でビルドがたまに失敗することがあり、対処方法がリトライだけでしたので、失敗したらリトライするか変更をコミットするかって感じでした。
で、リトライをするにも他の CI サービスのようにリトライボタンがビルドにはなく、空コミットを作って push してました。(ビルドトリガーを叩くでも可)

不安定な時期は何度も失敗するので、リトライボタンがほしいなーと思いました。
Webhook を受けて自動でビルドトリガー叩くってこともできるみたいですが・・・そこまでしてやりたくない・・・
https://github.com/axibase/atsd-use-cases/blob/master/how-to/docker/README.md#generate-webhook-when-docker-hub-build-fails

最後に
単純に1つのイメージをビルドするくらいなら Dockerhub で十分事足りるとは思いましたが、色々と痒いところに手が届かない感じでちょっと残念でした。(不安定なのはすごく困るし)
今は、Docker Cloud を使ったほうが良かったのかなーというお気持ち。機会があれば Docker Cloud も使ってみたいと思います。

では。

2018年5月2日水曜日

iutest v1.16.3 をリリースしました

C++ テスティングフレームワーク iutest v1.16.3 をリリースしました。
Github: https://github.com/srz-zumix/iutest/releases
OSDN: https://osdn.net/projects/iutest/releases/69492

変更点は以下の通りです。
  • 追加
    • IUTEST_ASSERT,IUTEST_EXPECT の Variadic 対応
    • iuwandbox: --iutest-use-main を追加
  • 変更
    • iuwandbox: Wandbox の std オプション変更への追従とヒント出力
  • 修正
    • バグ修正

今回も大きな機能リリースはなしです。
(単一マクロ引数だったアサーションを Variadic 対応している途中なのでその紹介は次回リリース時にでも…)
C++17 的な機能を実装して 1.17 リリースしたいなーと思ってるので、しばらく 1.16 系が続くかも…