これが私が達成しようとしていることです：
バイナリ リリース用のビルド ジョブを含むプロジェクトがあります。バイナリはプラットフォームごとにクロスコンパイルするのに時間がかかるため、リリースがタグ付けされたときにのみリリース ビルドを実行したいのですが、ローカル ネイティブ バージョンをビルドし、チェックインされたバージョンごとにテストを実行したいと考えています。
フライトスクールのデモに基づいて...これまでのところ、私のパイプライン構成は次のようになります。
resources:
- name: flight-school
type: git
source:
uri: https://github.com/nbering/flight-school
branch: master
- name: flight-school-version
type: semver
source:
driver: git
uri: https://github.com/nbering/flight-school
branch: master
file: version
jobs:
- name: test-app
plan:
- get: flight-school
trigger: true
- task: tests
file: flight-school/build.yml
- name: release-build
plan:
- aggregate:
- get: flight-school-version
trigger: true
- get: flight-school
passed: [test-app]
- task: release-build
file: flight-school/ci/release.yml
これにより、Web UI に次のようなパイプラインが生成されます。
問題は、git リポジトリの "release" ファイルを更新すると、semver リソース "flight-school-version" が git リソース "flight-school" の前にチェックされ、リリース ビルドが git から処理されることです。以前のチェックインに割り当てられたバージョン。
リリースビルドが別のタスクとして表示されるように、これを回避する方法が欲しいのですが、バージョンがバンプされたときにのみトリガーされます。
今まで思ったことをいくつか
tag_filtersemver タグがマスターにプッシュされた場合にのみ実行されるように、セットを使用して別の git リソースを作成します。
- 長所: タグがプッシュされたときにのみジョブが実行される
- 短所: 上記の semver ベースの例と同じように、テストの切断継承の問題があります。
ビルド スクリプトの一部としてチェックアウトで git 履歴を使用して、semver タグの条件付きチェックを追加します (またはファイルの diff を変更します)。
- 長所: 基本的に、コンコースとあまり格闘することなく、やりたいことを実行します
- 短所: ビルド出力を実際に読まないと UI の違いがわからない
- 短所: バイナリ リリースで何かを行うために、他のタスクやリソース タイプと組み合わせることは難しい
リリース ビルドを手動でトリガーする
- 長所：セットアップが簡単
- 短所: 手動の介入が必要です。
API を使用して、バージョンの変更が検出されたときにテストの完了時に一時停止されたビルド ステップをトリガーする
- 短所: 他の人がこれを行っている例を見たことがなく、本当に複雑に思えます。
git リソースと semver リソースの両方が変更されたときにタスクをトリガーする方法が見つかりません。
上記の例の同時実行性の問題を解決するための答え、または同様のリリース ワークフローを生成する代替パターンのいずれかを探しています。