Bitbucket Cloud の使用を開始する
Bitbucket Cloud を初めてお使いですか? 新規ユーザー用のガイドをご利用ください。
パイプライン構成の共有
Premium のみ
パイプライン構成の共有は Bitbucket Cloud Premium の機能です。Bitbucket Premium の詳細
Bitbucket Pipelines で YAML 構成を共有できることで、同じワークスペース内でパイプライン定義を定義および共有できます。これにより、各パイプライン構成を繰り返し作成する必要がなくなり、パイプライン定義を効率化できます。
ワークスペースに対する YAML 共有の設定
共有パイプライン定義を追加するワークスペースにリポジトリを作成します。リポジトリの作成について詳しくは、「Git リポジトリを作成する」ヘルプ ドキュメントを参照してください。
ファイルの最上位のプロパティで export: true を指定して bitbucket-pipelines.yml ファイルを作成し、パイプライン定義をそのファイルの definitions > pipelines セクションの下に配置します。
definitions > pipelines セクションで定義されているすべてのパイプラインがエクスポートされ、同じワークスペース内の他のリポジトリによってインポートできます。以下の例を確認してください。
1
2
3
4
5
6
7
8
9
export: true
definitions:
pipelines:
share-pipeline-1:
- step:
name: "hello world"
script:
- echo hello「エクスポート対象」のパイプラインを他のパイプラインから分離するには、definitions セクションの下に含めることをおすすめします。これにより、エクスポートするパイプライン定義を、実際のリポジトリ自体で実行するパイプラインから分離できます。
たとえば、エクスポート対象の .yaml を含むリポジトリに対してパイプライン内の基本的な .yaml 検証ロジックを実行するものの、実際にはその .yaml 検証ロジックを他のリポジトリにエクスポートして使用したくない場合などが考えられます。
3. パイプライン定義を再利用するリポジトリでは、共有パイプライン構成をインポートする場所にあるパイプラインで import プロパティを使用する必要があります。
1
2
3
4
pipelines:
custom:
import-pipeline:
import: shared-pipeline:master:share-pipeline-1YAML 共有のフォーマットとルール
インポート ステートメントでは {repo-slug-of-exported-pipeline}:{branch/tag-to-import-from}:{pipeline-from-exported-file} という構造を使用します。
import ステートメントは常にターゲット ブランチの HEAD コミットを参照します。
import ステートメントは常にパイプライン名と完全に一致します。glob パターンの一致はサポートされていません。
インポート ステートメントで使用するために特定の時点でエクスポート対象 .yaml を参照する場合は、ブランチ名の代わりに tag を使用して、HEAD ではなく特定のコミットを参照できます (ブランチの場合)。
これで、リポジトリで import-pipeline をトリガーできるようになり、エクスポート対象 .yaml の構成が使用されるようになります。
セキュリティとアクセス
重要な注意事項: パイプライン構成が export: true として明示的に宣言されていれば、ユーザーは直接アクセスできないリポジトリから構成をインポートするパイプラインを実行できます。
共有パイプラインの構成は、ユーザーに使用されるものとは異なるアクセス制御スキームに従います。
これは、共有パイプライン構成が保存されているリポジトリにユーザーがアクセスできず、権限の問題によりビルドが失敗するという複雑なシナリオを回避するためです。
外部パイプラインのインポートは、ユーザーではなくリポジトリが行うアクションとして扱われます。パイプラインは、export: true に設定されていれば、そのワークスペース内のすべてのリポジトリと「共有」されていると見なされます。
パイプライン .yaml ファイルを export: true でマークしたら、その内容はビルド ログなどから推測できる可能性があるため、同じワークスペース内のどのリポジトリでもそのパイプライン構成ファイルの内容を表示できると想定してください。
エクスポート対象パイプラインの構成に機密情報を直接保存しないでください 。機密情報の管理には常に変数とシークレットを活用してください。これらの値はインポートするリポジトリから継承されます。
注: ユーザーが UI を介して共有パイプライン構成が保存されているソース ファイルに移動しようとしても、リポジトリを表示する権限がない場合、UI でそのソース ファイルを表示することはできません。
FAQ
質問: パイプライン構成を複数の異なるワークスペースで共有できますか? 共有パイプライン構成は自身のワークスペースの外からでも安全ですか?
回答: パイプライン構成の共有の範囲は、パイプライン構成のエクスポート元のワークスペースに限定されます。エクスポート対象のパイプライン構成には、同じワークスペースにないリポジトリからはアクセスできません。
質問: 別のリポジトリからインポートするときに、構成の安定性を維持するにはどうすればよいですか? エクスポート中のリポジトリの構成が変更され、ビルドが中断された場合はどうなりますか?
回答: パイプライン構成のインポート ステートメントでは、インポートを Git ブランチまたは Git タグに固定できます。
ブランチをターゲットにする場合、インポートは常にそのブランチの HEAD から取得されます。つまり、エクスポート対象パイプライン構成の最新バージョンを取得することになるため、アップストリームでの変更があっても通貨を維持したい場合は、このモデルを使用することをお勧めします。
タグをターゲットにする場合、パイプライン構成は常に、固定されたタグが参照するコミットからインポートされます。これにより、顧客は静的なポイントインタイム参照を作成し、パイプライン構成をバージョン管理できます。将来的には、特定のコミットへの固定をユーザーが重視している場合には、そのサポートを追加する可能性があります。
質問: パイプラインを再実行して、最初に実行されてからインポート対象構成が変更されていた場合はどうなりますか?
回答: パイプライン全体が再実行された場合、再実行が実行された時点でパイプライン構成が再インポートされます。初回実行後に構成が変更された場合、実行される構成には新しい構成が反映されます。
質問: ステップを再実行して、最初に実行されてからインポート対象構成が変更されていた場合はどうなりますか?
回答: 1 つのステップを再実行した場合、そのステップの構成は、そのステップを最初に実行したときとまったく同じになります。繰り返しになりますが、これはパイプライン全体が再実行されたときの動作とは異なります 。
質問: パイプライン構成をインポートするとき、変数とシークレットはどのように処理されますか?
回答: ビルドでインポート対象パイプライン構成を実行しているときを含め、インポート対象リポジトリのすべての変数とシークレットをビルドで使用できます。インポート対象構成のスクリプトで変数が使用されていて、インポートされたリポジトリによってそれらの変数値が利用可能になっている場合、それらの変数値はビルドで実行されます。
エクスポートするリポジトリの変数値は、リポジトリのインポートでは共有も再利用もされません。
注: 共有パイプライン構成を利用するカスタム パイプラインでの変数の使用には既知の制限があります。リポジトリで共有パイプライン構成をインポートし、それをカスタム パイプラインの一部として使用する場合、UI を介して実行時に指定された変数値はパイプライン実行に渡されません 。代わりに、エクスポート対象パイプライン構成で指定されているデフォルト値が使用されます。
質問: インポート対象パイプライン構成の要素 (ステップ サイズ、最大時間、イメージなど) をカスタマイズできますか?
回答: インポート対象パイプライン構成を設定する唯一の方法は、変数とシークレットを使用することです。一方で、将来的にパイプラインの共有と構成においてこれまでにないレベルの柔軟性をお客様に提供する、本当にエキサイティングな機能に取り組んでいますので、最新情報にご注目ください。
質問: ステップは 1 つずつ共有できますか?
Answer: Yes, individual steps can be shared. See the example provided in the following community post for more information: Share a step across pipelines.
質問: definitions セクションに保存されている場合、shared-pipeline の共有パイプライン構成をテストするにはどうすればよいですか?
回答: yaml アンカーを使用できます。例を以下に示します。
1
2
3
4
5
6
7
8
9
10
11
12
export: true
definitions:
pipelines:
share-pipeline-1: &share-pipeline-1
- step:
name: "hello world"
script:
- echo hello
pipelines:
custom:
test-share-pipeline-1: *share-pipeline-1質問: 同じ名前の 2 つの異なるリポジトリで定義した場合、caches や services のような定義の優先順位はどうなりますか?
回答: グローバル オプション (image、clone、max-time、size、docker) と caches や services のような定義の場合、常にインポート リポジトリではなくエクスポート リポジトリとして扱われます。
たとえば、次のような bitbucket-pipelines.yml ファイルがリポジトリにあるとします。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
export: true
image: atlassian/default-image:3
definitions:
services:
docker:
memory: 1024
redis:
image: redis:6
memory: 512
caches:
my-custom-cache-without-key: cache
my-custom-cache:
key:
files:
- cache-key.txt
path: cache
pipelines:
export-pipeline:
- step:
services:
- docker
- redis
script:
- ls -la
- ls -la cache/ || true
- echo $BITBUCKET_BUILD_NUMBER > artifact.txt
- echo $BITBUCKET_BUILD_NUMBER > cache/cache.txt
artifacts:
- artifact.txt
caches:
- my-custom-cache
- my-custom-cache-without-keyまた、bitbucket-pipelines.yml がインポート リポジトリ内にある場合は次のようになります。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
image: maven:3.9-eclipse-temurin-11
definitions:
services:
docker:
memory: 2048
redis:
image: redis:7
memory: 1024
caches:
my-custom-cache:
key:
files:
- local.txt
path: local
my-custom-cache-without-key: local-path
pipelines:
default:
import: export_repo:master:export-pipelineimporting-repo でトリガーされた default パイプラインは shared-pipeline で定義された docker サービスと redis サービスを使用し、redis サービスには redis:6 の画像を使用します。また、my-custom-cache、my-custom-cache-without-key はインポート リポジトリからではなく、エクスポート リポジトリからです。
加えて、ステップ ビルド イメージは maven:3.9-eclipse-temurin-1 ではなく、atlassian/default-image:3 です。
この内容はお役に立ちましたか?
さらにヘルプが必要ですか?
アトラシアン コミュニティをご利用ください。