Bitbucket is getting a new navigation

We’re rolling out these changes, so the documentation may not match your experience in the Bitbucket Cloud app. Read about the new Bitbucket navigation

パイプライン構成の共有

Premium のみ

Pipelines configuration sharing is a Bitbucket Cloud Premium feature. Learn more about Bitbucket Premium

Bitbucket Pipelines で YAML 構成を共有できることで、同じワークスペース内でパイプライン定義を定義および共有できます。これにより、各パイプライン構成を繰り返し作成する必要がなくなり、パイプライン定義を効率化できます。

Create a repository in the Workspace where you’ll be adding the shared pipeline definition. For more information on creating a repository, refer to our Create a Git repository help document.
ファイルの最上位のプロパティで 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. In the repository where you want to reuse the pipeline definition, you need to use the import property in your pipeline at the location you want to import the shared pipeline configuration. You can use any of the pipelines start-conditions when importing a pipeline.

カスタムでトリガーされるパイプラインでインポートする例:

pipelines:
  custom:
    import-pipeline: 
      import: shared-pipeline:master:share-pipeline-1

main というブランチでトリガーされるパイプラインでインポートする例

pipelines:
  branches:
    main: 
      import: testing-pipelines:main:share-pipeline-1

インポートステートメントでは {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 でマークしたら、その内容はビルドログなどから推測できる可能性があるため、同じワークスペース内のどのリポジトリでもそのパイプライン構成ファイルの内容を表示できると想定してください。
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

質問: パイプライン構成を複数の異なるワークスペースで共有できますか? 共有パイプライン構成は自身のワークスペースの外からでも安全ですか?

回答: パイプライン構成の共有の範囲は、パイプライン構成のエクスポート元のワークスペースに限定されます。エクスポート対象のパイプライン構成には、同じワークスペースにないリポジトリからはアクセスできません。

質問: 別のリポジトリからインポートするときに、構成の安定性を維持するにはどうすればよいですか? エクスポート中のリポジトリの構成が変更され、ビルドが中断された場合はどうなりますか?

回答: パイプライン構成のインポートステートメントでは、インポートを Git ブランチまたは Git タグに固定できます。

ブランチをターゲットにする場合、インポートは常にそのブランチの HEAD から取得されます。つまり、エクスポート対象パイプライン構成の最新バージョンを取得することになるため、アップストリームで変更が発生しても最新性を維持したい場合は、このモデルを使用することをお勧めします。

タグをターゲットにする場合、パイプライン構成は常に、固定されたタグが参照するコミットからインポートされます。これにより、ユーザーは静的なポイントインタイム参照を作成し、パイプライン構成をバージョン管理できます。将来的には、特定のコミットへの固定をユーザーが重視している場合には、そのサポートを追加する可能性があります。

質問: パイプラインを再実行して、最初に実行されてからインポート対象構成が変更されていた場合はどうなりますか?

回答: パイプライン全体が再実行された場合、再実行が実行された時点でパイプライン構成が再インポートされます。初回実行後に構成が変更された場合、実行される構成には新しい構成が反映されます。

質問: ステップを再実行して、最初に実行されてからインポート対象構成が変更されていた場合はどうなりますか?

回答: 1 つのステップを再実行した場合、そのステップの構成は、そのステップを最初に実行したときとまったく同じになります。繰り返しになりますが、これはパイプライン全体が再実行されたときの動作とは異なります。

質問: パイプライン構成をインポートするとき、変数とシークレットはどのように処理されますか?

回答: ビルドでインポート対象パイプライン構成を実行しているときを含め、インポート対象リポジトリのすべての変数とシークレットをビルドで使用できます。インポート対象構成のスクリプトで変数が使用されていて、インポートされたリポジトリによってそれらの変数値が利用可能になっている場合、それらの変数値はビルドで実行されます。

エクスポートするリポジトリの変数値は、リポジトリのインポートでは共有も再利用もされません。

注: 共有パイプライン構成を利用するカスタムパイプラインでの変数の使用には既知の制限があります。リポジトリで共有パイプライン構成をインポートし、それをカスタムパイプラインの一部として使用する場合、UI を介して実行時に指定された変数値はパイプライン実行に渡されません。代わりに、エクスポート対象パイプライン構成で指定されている既定値が使用されます。

質問: インポート対象パイプライン構成の要素 (ステップサイズ、最大時間、イメージなど) をカスタマイズできますか?

Answer: Yes. Refer to our Dynamic pipelines help documentation for more details.

質問: ステップは 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 アンカーを使用できます。例を以下に示します。

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 ファイルがリポジトリにあるとします。

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 です。

この内容はお役に立ちましたか?

正確ではなかった明確ではなかった関係なかった

さらにヘルプが必要ですか?

アトラシアンコミュニティをご利用ください。

コミュニティに質問

Bitbucket is getting a new navigation

パイプライン構成の共有

ワークスペースに対する YAML 共有の設定

YAML 共有のフォーマットとルール

セキュリティとアクセス

FAQ

さらにヘルプが必要ですか?