TeamCity のクラウドサービスが始まるようでそのオープンβがやっていたので使ってみました。
TeamCity Cloud
一般リリースは年内を予定しているようです。
登録
まずは TemaCity Cloud にアカウント登録しましょうトップページからインスタンス名と登録するメールアドレスを記入して「Sign Up」を押し、インスタンスの招待状が届くのを待ちます。
招待状が届いたら、アカウント登録に進みます。
今回は GitHub アカウントで登録します。特に気をつけることなく進めて OK です。
利用規約に同意したら登録完了です。
プロジェクト作成
アカウント登録できたら、最初に決めた「インスタンス名.beta.teamcity.com」が開きます。ダッシュボードが出るのでプロジェクトを作成しましょう。
GitHub のリポジトリ一覧が出るので CI したいリポジトリを選択します。
今回は C++ 自作テスティングフレームワークの 「iutest」を選択します。
選択すると verify が始まるので少し待ちましょう。
verify 完了すると以下の画面になるので、名前を決めて Proceed します。
ビルドステップの設定では、リポジトリを解析してビルドコンフィグらしきものを自動で収集してくれます。
ビルドスクリプトなどがあればリストアップされるので、ビルドしたいコンフィグを選択しましょう。
iutest は複数プロジェクトファイルがリポジトリに入ってるのでたくさん出てきました。
ビルドコンフィルを選択すると自動でビルドステップが作成されます。
この時点でテスト実行可能になります。
iutest では最初 VS2019 のプロジェクトを選択したのですが、 "Microsoft.Cpp.Default.props" がなくてビルド失敗してたので、別のテストをするようにしました。
次の項目で設定した手順をまとめます。
Google Test 互換性テストを構築する
今回ちょうど Wercker でやっていた Google Test 互換性を引っ越したいと思っていたので、そちらを移植したいと思います。
Google Test 互換性テストでは Google Test セットアップ済みの Docker image を使って、ビルドとテストを行います。任意の Docker コンテナ上で処理をする方法が複数あるので紹介します。
Docker runner を使う方法
Docker runner でビルドステップを作成します。
「Runner type」 に「Docker」を選択し、 「Docker command」は「other」を選択します。「Command name」は「run」です。
あとは「Additiona arguments for the command」に docker run コマンドの引数を設定します。 チェックアウトディレクトリが「%system.teamcity.build.checkoutDir%」なのでそこをマウントしましょう。
また Docker run コマンドは実際にはラッパーを経由するようで、「--rm」オプションをそのラッパーが必ずつけるので不要なようです。
Command Line runner を使う方法
Command Line runner でビルドステップを作成します。
「Runner type」 に「Command Line」を選択し「Run step within Docker container」にイメージを設定します。
あとはやりたい処理を「Custom script」に書くだけです。
あとはやりたい処理を「Custom script」に書くだけです。
（「Additonal docker run arguments」に docker run のオプションを設定できるので、Docker runner と同等に使えると思います）
複数の処理を行う場合は Command Line runner を使ったほうが良さそうです。
設定は以上です。
これで Docker イメージを使ってビルド・テストの準備ができました。
プルリクエストでトリガーする
TeamCity Cloud では他の CI サービスと違ってデフォルトでは PR をトリガーにジョブがキックされません。「Build Features」で設定を追加する必要があります。プロジェクト設定の「Build Features」を開いたら Add します。
Features に「Pull Requests」があるので選択し、必要な項目を設定しましょう。
「VCS Root」に GitHub のリポジトリを選択
「VCS hosting type」を「GitHub」にすると追加の設定項目が出てきます。
「Token」は GitHub で Personal Access Token を作って設定します。
権限は「public_repo」もしくは「repo」が必要になります。
iutest は public なので「public_repo」権限のトークンを設定しました。
「public_repo」の場合はコミットステータスにレポートするためには「repo:status」も必要になるので注意してください。
「public_repo」の場合はコミットステータスにレポートするためには「repo:status」も必要になるので注意してください。
「By authors」で対象とする PR の範囲を設定します。
iutest では特に制限必要ないので「Everybody」を設定。
iutest では特に制限必要ないので「Everybody」を設定。
以上で設定完了です。「Test connection」で接続確認したら Save しましょう。
これで PR が来るとビルドが実行されるようになりました。
また、GitHub のコミットステータスに結果を表示するには「Build Features」に「Commit status publisher」を追加してください。こちらも Personal Access Token が必要です（同じトークンで問題ないです）。
設定の仕方は公式ブログでも紹介されています。そちらも参考にしてみてください。
DockerHub login
DockerHub の pull 制限に対応するためにログインしておきます。
まずは、プロジェクト設定の「Connections」で「Docker registry」を選択して「https://docker.io」のアカウントを登録します。（パスワードはアクセストークンで ok）
接続確認して保存しましょう。
続いて、「Build Features」で「Docker Support」を追加します。
レジストリに先程接続した設定を追加しましょう。
設定は以上です。
バッジ
では、パイプラインが完成したのでバッジをつけましょう。
Markdown の場合は以下のようになります。
[](https://iutest.beta.teamcity.com/viewType.html?buildTypeId=Iutest_GoogleTestCompatibleTest&guest=1)
このままだと自分以外はステータスが見られないので、ゲストアカウントにログイン権限をつけます。「Administration」の「Authentication」に「Guest user login」の項目があるのでチェックを入れましょう。
このように表示されます。
※ブランチごとに表示をしたかったのですがサーバーの設定が必要なようなのでクラウド版では現状できなそうでした。
改善したいところ
TeamCity Cloud で現状可能かわかりませんが以下の対応ができると嬉しいなと思ってます。
* Matrix Build
現状バージョン違いのビルドステップをコピーしているが、マトリックスにしたい。
* as Code
最後に
TeamCity は他の CI as a Service と比較すると設定することが多い印象でした。
その分拡張性も高い感じがするので、Jenkins おじさんを少し思い出しました。
ただ、オンプレではなくクラウド版でどこまで拡張して使えるのかはわからないのと、まだオープンベータであり、料金体系や制限がどうなってくるかが気になるところです。
とはいえ、一般リリースまでまだ少し期間があるのでそれまで使わせていただこうと思います。
一般リリースされたら、パイプラインをより精査していきたいと思います。
では。
0 件のコメント:
コメントを投稿