古いXAMLビルド定義から新しいTFS 2015ビルドに移行しています。古いものでは、gated-checkがうまくいきます。新しいものでは、 "Triggers"タブでそのようなオプションがあります。しかし、ビルドをトリガーするコミットIDを使用します。 変数$(Build.SourceVersion)がこれに責任を負いますが、gated-checkのために設定されていません。 コミットがまだTFSに受け入れられていないので、正しく見えます。
質問は、ゲット・チェック・インまたはCIの後にこのコミットIDを取得する方法ですか？
私たちのソリューションをコンパイルするだけのゲーテッド・チェックイン用のビルドをもう1つ作成し、成功した場合のみCIをトリガする必要がありますか？
はこれまでのところ、私はきれいではない回避策で終わるが、それは私たちに受け入れられました。管理。 私は2つのビルド定義を作成しました.1つはゲートチェックイン用、もう1つはCI用です。 ゲイテッドチェックインで何かをチェックインすると、火災が発生します。正常に完了すると、CIビルドがトリガーされます。 UIに対応するチェックボックスに注意してください。
これはとてもきれいソリューションではありませんが、それは私のために動作します。
ゲーテッド・チェックイン時にチェックインしていないチェンジセットIDを取得する方法はありません。以下のスクリーンショットを確認してください。ゲートされた変更をチェックすることは、ビルドプロセスの最後のステップであり、制御できません。ビルドが完了すると、変数$(Build.SourceVersion)が自動的に更新されます。したがって、ビルドが完了するまでチェックインしていないチェンジセットIDを取得することはできません。
その後、「sourceVersion」をフェッチ、完了したTFS REST API to get the buildを使用する必要があります：
GET http://{instance}/DefaultCollection/{project}/_apis/build/builds/{buildId}?api-version={version}
コミットIDを使って何をしようとしていますか？私は問題が何であるか理解していない。スクリプトに渡すようなことをしない限り、コミットIDは必要ありません。 –
私は特別なフォルダ名を生成し、サーバに置くためにコミットIDが必要です。 「dev_build_c6445_20170120.1」のように。 – Alezis
@Alezis、ゲイテッド・チェックイン・トリガーまたはCIトリガーを意味しますか？ Gitチームプロジェクトでは、TFS 2015のゲーテッドチェックイントリガーはサポートされていません。また、コミットIDの代わりにチェンジセットIDを使用したいと思っていますか？ –