Visual Studio Team Services CI/CDアドベントカレンダー：ビルドタスクの実行条件を指定する(17日目)

はじめに

これはVisual Studio Team Servicesアドベントカレンダー17日目の記事です。

qiita.com

ビルドタスクを定義してもちょっと特定の時は動いてほしくない、という場合はあります。例えば、masterブランチのビルドをCIで実施するけど、手動で実行したときはテストしたくない、というケースはありえます。

そんなときのために、ある条件を満たすと特定のビルドステップを実行しない、という機能がありますので、紹介します。

ビルド定義での条件設定

ビルドタスクの実行条件はControl Optionsをクリックして展開される、Runt this taskで設定します。標準でCustom conditionsが選択されていますが、他の物を指定することもできます。

• Only when all previous tasks have succeeded
• Even if a previous task has failed, unless the build was canceled
• Even if a previous task has failed, even if the build was canceled
• Only when a previous task has failed
• Custom conditions

それぞれ順に以下の意味になっています。

• 前のタスクが成功した時だけ実行する
• 前のタスクが失敗した時、ビルドがキャンセルされてない限り実行する
• 前のタスクが失敗した時、ビルドがキャンセルされた場合でも実行する
• 前のタスクが失敗した場合のみ
• 独自の条件を指定する

2-4番目に関しては、ビルドが失敗したとき、何らかのクリーンアップを実行するといった場合に指定するといいと思います。

本記事ではちょっとわかりにくい5番目のCustom Conditionsについて解説します。

Custom Conditionの設定

例えば、このビルド定義にはmasterへのコミットでビルドを実行する設定になっています。CIがかかったときはテストタスクを実行してほしいけど、手動で実行したときはテストをしなくてもいい、という条件を設定します。

and(succeeded(), in(variables['Build.Reason'], 'IndividualCI', 'BatchedCI'))

保存して、手動でQueue Buildをクリックします。

VsTest - testAssembliesタスクにチェックが入っておらず、実行されていないことが分かります。

masterにコミットしたときに実行されるCIではVsTest - testAssembliesにチェックが入っていて、実行されていることが分かります。

Custom Conditionsの式は以下の形式です。

論理式(判定結果, 論理式())

論理式にはand, orなどが指定できます。variablesと比較する場合、variables['値']で実行時の値と比較可能です。

docs.microsoft.com

なお、この条件は以下のように重ねることができます。

and(and(success(),...)

参考文献

公式ドキュメントはこちらにあります docs.microsoft.com

Visual Studio Team Services CI/CDアドベントカレンダー：外部レポジトリ(GitHub)をビルドする(16日目)

はじめに

これはVisual Studio Team Servicesアドベントカレンダー16日目の記事です。

qiita.com

今までVSTSの内部レポジトリのビルドについて紹介していましたが、今日は外部のレポジトリ具体的にはGitHubのビルドについて紹介します。

VSTSはオールインワンでそろっていますが、外部サービスとも連携します。VSTSもよくはなっていますが、VSTSはクローズのみなので、オープンソースの開発をするならGitHubということは多いと思います。この記事ではVSTSのビルドサービスをGitHubのレポジトリに対して実行する方法について紹介します。

前提条件

以前も書きましたが、GitHubのレポジトリをビルドする場合、ビルド定義を作る人がownerになっている必要があります。Contributorではコミット時のビルドの設定ができないので、注意してください。スケジュールビルドはできます。

GitHubへの認証を設定します。OAuthかPATを使うかお好みで。

対象のレポジトリを選択します。ちょうど先日GitHubにConnect();で使われたデモソリューションのSmartHotel 360が公開されたので、forkしてみました。

ここから先はVSTS内のレポジトリをビルドするときと変わりありません。ビルド定義を作って、ビルドキューに入れてみます。

Hosted VS2017を指定します。

普通にビルド完了ですね。ちなみにこのソリューションのビルド結構時間がかかります。10分弱使いました。

コミット時にビルドする

GitHubの特定のブランチにコードがpushされたときにビルドする、pull request時にビルドするということもできます。

ただ、pull requestのビルドで外部レポジトリを指定した場合、git pullに失敗していました。これはちょっと調べてみます。それは置いといて、GitHubでpull requestしてみましょう。

devブランチを作って、適当に編集して、自分のmasterにpull requestをだしてみます。

mergeします。

今回はpull requestとmasterへのcommitでビルドのトリガーをかけているので、ビルドが二つキューに入れられています。pull requestでCIをかける場合、このようにビルドがキューにはいるので、注意してください。

masterへのコミットでビルドトリガーを指定しているので、自動的にビルドが実行されました。

ビルド結果の見方

ビルド結果ですが、自分がCIを設定しているので、mineハブを見ればいいか…と思うのですが、実はそうではありません。

GitHubのmasterにコミットされたコードのビルド結果は20171216.3ですが、mineハブで表示されているのは20171216.1という、最初に自分で明示的にキューに入れたビルドだけです。

実はpull requestなどのVSTSが外部イベントにより自動的に発生するビルドに関しては、mineには表示されません。以前はmineにこの辺のCIによるビルド品質レポートも含められていたのですが、わかりにくいということでフィードバックにより変更されました(私も最初わからなくて聞きました)。

TFS 2017ではたぶんこのレポートはCI含めて表示されているはずなので、見るときには気を付けてください。

CIおよび、ユーザーの明示的なビルド指示を含めて全部見たい場合はDefinitionsハブで見てください。

こちらはCIやほかの人が実行したビルド結果を含めて成功率が表示されます。

Visual Studio Team Services CI/CDアドベントカレンダー：異なるエージェントを使ってビルドする(15日目)

はじめに

これはVisual Studio Team Services アドベントカレンダー15日目の記事です。

qiita.com

6日目の記事で複数段階でビルドする、という機能を紹介しました。

kkamegawa.hatenablog.jp

その時はまだなかったのですが、Sprint 127の新機能でフェーズごとに別のエージェントが指定できるようになっています。今週中に展開が完了するということなので、もう使える方も多いと思います。ちょっとやってみましょう。

docs.microsoft.com

この機能はまだプレビューなので、Enable Preview Featureで有効にしてから試してください。

別のエージェントプールを追加する

Processのところで、Add agent phaseで追加します。これは前と同じですね。

前は選択できなかった、Agent queueが変更できるようになっています。せっかくなので、Hosted macOS Previewを選択します。

こちらは従来通り、Hosted VS2017を選択します。

こんな感じで複数のエージェントが構成できました。

ビルドもそれぞれできてますね。

並列実行は？

こんな風にparallel設定がありそうなので、複数のエージェントが並列でビルドできるのか…と思いきや、実はそうではありません。これはあくまでも「一つのエージェントフェーズ内で」の並列です。

docs.microsoft.com

具体的な用途としては、多くのUnit testを並列で動かすことができるのですが、そのためと思ってもらえればいいと思います。

並行ビルドの要望は出ているので、そのうち入るかもしれません。

Visual Studio Team Services CI/CDアドベントカレンダー：Inside Build Agent(14日目)

はじめに

これはVisual Studio Team Servicesアドベントカレンダー14日目の記事です。

qiita.com

VSTSにはCircleCIやAppVeypor、Travis CI、Bambooのようなクラウドベースのビルドサービスがあります。240分/月までは無料です。ただ、テンプレートから作ったものをビルドするだけでも3-4分かかるものもあるので、無料枠はどんな感じで使えるのかという感じをつかむくらいでしょうか。

そんなVSTSのビルドエージェントですが、実は自分でたてることもできます。インストールしてどんな挙動になっているのかとか、ちょっとしたTIPSを紹介します。

VSTSエージェントのソース

github.com

VSTSは.NET Core上で動いています。なので、Windows以外にもmacOS, Linuxもサポートしています。Linuxは特にdockerイメージも公開されているので、インストールは楽です。Windows版のDockerイメージも公開してほしいみたいなフィードバックは出ているのですが、まだないようです。

Docker使う方法は以前書いたので、こちらを見てください。

kkamegawa.hatenablog.jp

DockerイメージにはVSTSで動いているソフトと同じものが入っているので、それ以外で必要なものを追加する場合は自分でdockerイメージをビルドします。node.jsや新しいJDKであればビルドタスクで追加もできるので、dockerビルドする必要はありません。

ローカルか、プライベートか。

VSTSが提供するエージェントの場合、ローカルディスクが10GBまでという制限があります(緩和してほしいというリクエストは出ています)。これを超えるとpullやビルドに失敗するので、ゲームなどで大きなコンテンツをビルドするときはレポジトリをわけるか、ローカルエージェントを使うしかありません。

後はCPUが2コアだったはずなので、大きいソリューションを並列ビルド、テストしたいときもちょっと困りますね。

そのほか、新しいXCodeをいち早く使いたいとか、ライセンス上nuget等でとってこれないライブラリをビルドするときもプライベートエージェントを使ってください。

エージェントのフォルダー構成

ビルドエージェントのフォルダー構成はこのような感じです。

_work(インストール時に変更できます)というフォルダの下に1,2,3...と数字が振られます。これがビルド毎に使われる作業フォルダです。

• a : artifact(成果物)が格納されます。publish to artifactsタスクがこのフォルダーを丸ごとVSTSにアップロードします。
• b : ビルドで一時的に使います。
• s : ソースを取得するフォルダーです。

これらのフォルダーの絶対パスを取得したい場合、VSTSのビルドエージェントの定義済みの値を使用します。

docs.microsoft.com

ビルドタスクのPowerShell, バッチファイル、シェルスクリプトで参照できます。

こちらはDeployment Group用に構成したエージェントです。_workというフォルダーの下にr1というフォルダーができており、その配下はビルドと同じ構成になってます。

aというフォルダの下にビルド定義で生成された成果物(artifact)がダウンロードされていることが分かります。ビルド定義でdropフォルダの下に生成すると指定しているのが分かると思います。

ビルドエージェントの更新

ビルドエージェントはGitHubのReleaseからダウンロードします。一部の環境でGitHubのRelease(というよりAWSのS3)へのアクセスが制限されている場合、VSTSの機能での更新はできないので気を付けてください。

Dockerみたいにmicrosoft.comドメインから配布してくれるとありがたいんですが…(フィードバックしたんですが)。

(2018/2/7更新)
ビルドエージェント 2.129(2.127も)からMicrosoft配下のドメインからダウンロードできるようになっています。おかげでAWS S3がアクセス禁止になっている組織でもダウンロードできるはずです。

docs.microsoft.com

そのほかの展開についてはこちらをみてください。ちなみに、VSTSへの接続は一台のビルドサーバーが一つのVSTSへの接続しかできない、ということはありません。リソースが許す限りいくつでもサービスを構築できます(もちろんインストール用のフォルダは別の名前にします)。

PATでの接続になりますが、PATの期限切れの通知はないので気を付けてください。

capability(ビルドエージェントで使用可能な機能)

VSTSでビルドエージェントと一口に言っても何がビルドできるのかわかりづらいでしょう。何がインストールされているかということはAgent Queueハブから対象のビルドエージェントを選択すると、Capabilityという項目でわかります。

例えばこれはVSTS AgentのLinux Dockerイメージの場合です。JDK7/8はじめいろいろ入っています。独自のDockerイメージを作るのもいいでしょう。

Hosted VS2017イメージです。実は作成方法はこちらのGitHubで公開されています。

github.com

このスクリプトを使えば理論上同じ機能を持つプライベートエージェントが作成できます。VSTSのHost agentはまだWindows Server 2012 R2のはずなので(そのうち2016になるようです)、Windows 10でなければビルドできないようなもの、例えばMixed Reality対応アプリやUnityに関しては残念ながらローカルエージェントを使ってください。

macOSのXCodeも新しいものにリアルタイムでついていきたい場合は自前で管理するしかないようです。

capabilityはエージェントの環境変数の値がそのまま出ていますが、実は自分でも特殊な値を追加できます。自分のローカルエージェント(default)のUbuntu001のcapabilityから"Add capability"で好きな値(ここではmycapabilities)を指定します。

そして、ビルド定義のDemandsにmycapabilitiesがなくてはならない(exits)と指定します。

仮に、VS2017エージェントプールを指定しても…。

このようにHosted VS2017のエージェントにはmycapabilitiesがないので、ビルドに失敗します。

これは自分で指定した追加capabilityですが、そもそもVisual Studioが必要なのに入っていないエージェントプールを指定しても同じエラーになります。

※:確か以前はキューに投入する前にDemandsと一致していないよという警告が出たはずなんですが…。

TIPS

自分で管理しているとはいえ、ソースの中に機微情報が入っているなどの理由でビルドエージェント内にファイルを残しておきたくない場合があります。

ビルドエージェント2.126(最新版)の新機能に、ビルド終了時pullしたソースコードを消してくれる、という機能が追加されました。

ビルド定義のvariableに"process.clean"を追加して、trueを指定してください。ビルド終了時にローカルのソースファイルが自動的に削除されます。

ビルドエージェントはあまり知られてないことも多いですが、ビルドタスクともどもオープンソースなので、困ったらソース見るといいと思います！