パイプライン構成の共有

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 コミットを参照します。
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 です。

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

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

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

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

コミュニティに質問

パイプライン構成の共有

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

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

セキュリティとアクセス

FAQ

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