パイプライン構成の共有
Premium のみ
パイプライン構成の共有は Bitbucket Cloud Premium の機能です。Bitbucket Premium の詳細
Bitbucket Pipelines で YAML 構成を共有できることで、同じワークスペース内でパイプライン定義を定義および共有できます。これにより、各パイプライン構成を繰り返し作成する必要がなくなり、パイプライン定義を効率化できます。
ワークスペースに対する YAML 共有の設定
共有パイプライン定義を追加するワークスペースにリポジトリを作成します。リポジトリの作成について詳しくは、「Git リポジトリを作成する」ヘルプ ドキュメントを参照してください。
ファイルの最上位のプロパティで
export: true
を指定してbitbucket-pipelines.yml
ファイルを作成し、パイプライン定義をそのファイルのdefinitions > pipelines
セクションの下に配置します。
definitions > pipelines
セクションで定義されているすべてのパイプラインがエクスポートされ、同じワークスペース内の他のリポジトリによってインポートできます。以下の例を確認してください。
export: true
definitions:
pipelines:
share-pipeline-1:
- step:
name: "hello world"
script:
- echo hello
「エクスポート対象」のパイプラインを他のパイプラインから分離するには、definitions
セクションの下に含めることをおすすめします。これにより、エクスポートするパイプライン定義を、実際のリポジトリ自体で実行するパイプラインから分離できます。
たとえば、エクスポート対象の .yaml を含むリポジトリに対してパイプライン内の基本的な .yaml 検証ロジックを実行するものの、実際にはその .yaml 検証ロジックを他のリポジトリにエクスポートして使用したくない場合などが考えられます。
3. パイプライン定義を再利用するリポジトリでは、共有パイプライン構成をインポートする場所にあるパイプラインで import
プロパティを使用する必要があります。
pipelines:
custom:
import-pipeline:
import: shared-pipeline:master:share-pipeline-1
YAML 共有のフォーマットとルール
インポート ステートメントでは
{repo-slug-of-exported-pipeline}:{branch/tag-to-import-from}:{pipeline-from-exported-file}
という構造を使用します。import
ステートメントは常にターゲット ブランチの HEAD コミットを参照します。The
import
statement will always exact match for pipeline name, glob pattern match is not supported.If you want to reference your exported .yaml at particular points in time for use in import statements, you can use a
tag
instead of the branch name to reference a specific commit rather than the HEAD if the branch.
これで、リポジトリで import-pipeline
をトリガーできるようになり、エクスポート対象 .yaml の構成が使用されるようになります。
セキュリティとアクセス
Important Note: Users can execute pipelines that import configurations from repositories they do not have direct access to, if that pipeline configuration has explicitly been declared as export: true
.
共有パイプラインの構成は、ユーザーに使用されるものとは異なるアクセス制御スキームに従います。
これは、共有パイプライン構成が保存されているリポジトリにユーザーがアクセスできず、権限の問題によりビルドが失敗するという複雑なシナリオを回避するためです。
We treat the importing of an external pipeline as an action taken by the repository, not the user. The pipeline is considered to be “shared” with all repo's in that Workspace if it has been set to
export: true
.Once you mark a pipeline .yaml file with
export: true
, assume that any repository in the same workspace can view the contents of that Pipeline configuration file, as the contents may be inferable via things like build logs etc.Do not store sensitive information directly within the configuration of exported Pipelines. Always leverage variables and secrets for managing sensitive information as these values are inherited from the importing repository.
注: ユーザーが UI を介して共有パイプライン構成が保存されているソース ファイルに移動しようとしても、リポジトリを表示する権限がない場合、UI でそのソース ファイルを表示することはできません。
FAQ
質問: パイプライン構成を複数の異なるワークスペースで共有できますか? 共有パイプライン構成は自身のワークスペースの外からでも安全ですか?
回答: パイプライン構成の共有の範囲は、パイプライン構成のエクスポート元のワークスペースに限定されます。エクスポート対象のパイプライン構成には、同じワークスペースにないリポジトリからはアクセスできません。
Question: How do I maintain the stability of the configuration when importing from another repository? What happens if the config in the exporting repo changes and breaks my build?
回答: パイプライン構成のインポート ステートメントでは、インポートを Git ブランチまたは Git タグに固定できます。
When targeting a branch, the import will always pull from the HEAD of that branch, meaning you will get the latest version of the exported Pipeline Configuration. We recommend using this model if you want to maintain currency with any upstream changes.
When targeting a tag, the Pipeline Configuration will always be imported from the commit referenced by the tag pinned. This allows users to create static point-in-time references and version their Pipeline Configurations. In the future, we may add support for pinning to specific commits if this is something users see value in.
質問: パイプラインを再実行して、最初に実行されてからインポート対象構成が変更されていた場合はどうなりますか?
回答: パイプライン全体が再実行された場合、再実行が実行された時点でパイプライン構成が再インポートされます。初回実行後に構成が変更された場合、実行される構成には新しい構成が反映されます。
質問: ステップを再実行して、最初に実行されてからインポート対象構成が変更されていた場合はどうなりますか?
回答: 1 つのステップを再実行した場合、そのステップの構成は、そのステップを最初に実行したときとまったく同じになります。繰り返しになりますが、これはパイプライン全体が再実行されたときの動作とは異なります。
質問: パイプライン構成をインポートするとき、変数とシークレットはどのように処理されますか?
回答: ビルドでインポート対象パイプライン構成を実行しているときを含め、インポート対象リポジトリのすべての変数とシークレットをビルドで使用できます。インポート対象構成のスクリプトで変数が使用されていて、インポートされたリポジトリによってそれらの変数値が利用可能になっている場合、それらの変数値はビルドで実行されます。
エクスポートするリポジトリの変数値は、リポジトリのインポートでは共有も再利用もされません。
Note: There is a known limitation with using variables in custom pipelines that utilize a shared Pipeline Configuration. If a repository imports a shared Pipeline Configuration and uses it as part of a custom pipeline, variable values specified at runtime via the UI will not pass to the pipeline execution. Instead, the default values specified in the exported Pipeline configuration will be used.
Question: Can I customize elements of the imported Pipeline config like step size, max time, image, etc.?
Answer: Yes. Refer to our Dynamic pipelines help documentation for more details.
質問: ステップは 1 つずつ共有できますか?
回答: はい、ステップは 1 つずつ共有できます。詳細については、次のコミュニティ投稿「Share a step across pipelines (パイプライン間でステップを共有)」にある例を参照してください。
質問: definitions
セクションに保存されている場合、shared-pipeline
の共有パイプライン構成をテストするにはどうすればよいですか?
回答: yaml アンカーを使用できます。例を以下に示します。
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
Question: What is the precedence for definitions like caches
or services
if I have it defined in 2 different repositories with the same name?
Answer: For global options( image
, clone
, max-time
, size
, docker
) and definitions like caches
, services
, we always take them from the exporting repository and not the importing repository.
たとえば、次のような bitbucket-pipelines.yml
ファイルがリポジトリにあるとします。
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
がインポート リポジトリ内にある場合は次のようになります。
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-pipeline
importing-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
です。
この内容はお役に立ちましたか?