GO-REVISIONをGO-CDの上流パイプラインから下流パイプラインに渡す方法はありますか？

Question

GO_REVISIONを上流のパイプラインから下流のパイプラインに渡すには？

私は4つのパイプラインを持ち、GO_REVISIONに同じgitとそのバージョンタグでアプリケーショントリガを構築しました。

展開するためのパイプラインDを使用し、それは、材料は、BおよびC

しかし、私はDに、上流側パイプライン（A/B/C）からGO_REVISIONを共有する方法を知らないされてい

   +--->Pipeline A + 
       |    | 
GIT (Material)+--->Pipeline B +------>Pipeline D (How get upstream GO_REVISION) 
       |    | 
       +--->Pipeline C + 

Answer 1

によって異なります。リポジトリとのユースケースがある場合は、GIT（Material）をPipeline-Dの従属資料とする必要があります。

そうでなければ、GO_REVISIONをパイプライン-D内の環境変数$ {GO_DEPENDENCY_LABEL_A}にアクセスして、上流パイプラインのいずれかのラベル（パイプラインAを設定しようとします）にすることができます。 Image : Setting Pipeline-A label to hold GO_REVISION

$ {material_name}から$ {material_name [：6]に変更するラベルには、SHAから最初の6文字しか使用できません。リビジョンを使用して構築し表現したい場合は

Image : Accessing GO_REVISION in Pipeline D

一般的にこの種のアプローチが使用されています。

もう1つのアプローチは、それを上流のパイプラインの1つのファイルに書き込んで、下流のパイプラインでフェッチする方法です。

Answer 2

A、B、Cを1つのパイプラインに配置することを検討してください。

ABCはタスクとして並行して実行できます。なぜ私はこれを言うのですか？それはABCが常に同じGitコミットを構築するためです。 ABCが別々のパイプラインである場合、競合状態が発生する可能性があります（エージェント待ち、ビルド失敗など）。ABCがソースの異なるリビジョンにある場合、GoCDは警告にフラグを付けます。しかし、シンプルが最高です。

これで、リビジョンをDにすることは、piplineラベルを使って正しかったです。

ただし、 I 常にフラットファイルのビルドされた成果物にバージョン情報を書き込みます。余分なメタデータは、生産終了時のコードの監査能力を保証することを可能にする。また、バージョン情報をアプリケーションユーザーインターフェイスに挿入する必要があります（ある場合）。