パイプライン構成の共有

Premium のみ

パイプライン構成の共有は Bitbucket Cloud Premium の機能です。Bitbucket Premium の詳細

Bitbucket Pipelines で 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

インポートステートメントでは {repo-slug-of-exported-pipeline}:{branch/tag-to-import-from}:{pipeline-from-exported-file} という構造を使用します。
import ステートメントは常にターゲットブランチの HEAD コミットを参照します。
import ステートメントは常にパイプライン名と完全に一致します。glob パターンの一致はサポートされていません。
インポートステートメントで使用するために特定の時点でエクスポート対象 .yaml を参照する場合は、ブランチ名の代わりに tag を使用して、HEAD ではなく特定のコミットを参照できます (ブランチの場合)。

これで、リポジトリで 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.
パイプライン .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 から取得されます。つまり、エクスポート対象パイプライン構成の最新バージョンを取得することになるため、アップストリームでの変更があっても通貨を維持したい場合は、このモデルを使用することをお勧めします。

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

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

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

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

Answer: If a single step is rerun, the configuration for that step will be exactly the same as the first time the step was run. To reiterate, this is different to the behavior when the entire Pipeline is rerun.

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

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

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

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 instead.

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

回答: インポート対象パイプライン構成を設定する唯一の方法は、変数とシークレットを使用することです。一方で、将来的にパイプラインの共有と構成においてこれまでにないレベルの柔軟性をお客様に提供する、本当にエキサイティングな機能に取り組んでいますので、最新情報にご注目ください。

質問: ステップは 1 つずつ共有できますか?

回答: はい、ステップは 1 つずつ共有できます。詳細については、次のコミュニティ投稿「Share a step across pipelines (パイプライン間でステップを共有)」にある例を参照してください。

Question: How can I test shared pipeline configurations in shared-pipeline if it is stored in the definitions section?

回答: 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 them in 2 different repositories with same name?

Answer: For global options( image, clone, max-time, size, docker) and definitions like caches, services, we always 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 です。

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

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

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

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

コミュニティに質問

パイプライン構成の共有

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

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

セキュリティとアクセス

FAQ

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