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

ステージ オプション

ステージを使用すると、パイプライン ステップを共有プロパティで論理的にグループ化できます。たとえば、同じデプロイ環境のステップをグループ化したり、デプロイ環境を複数のステップでロックしたり (他のパイプラインがそれと相互作用しないようにするため)、複数の連続したステップでデプロイ変数を共有したりできます。

概要

ステージをセットアップする

パイプラインにステージを追加するには、stage プロパティを追加し、そのステージ内に 1 つ以上のステップをグループ化します。次に例を示します。

pipelines: default: - stage: name: Build and test steps: - step: name: Build app script: - sh ./build-app.sh - step: name: Run unit tests script: - sh ./run-tests.sh

デプロイにステージを使用する

デプロイ ステージを使用すると、次のことが可能になります。

  • ステップを組み合わせて論理的に構造化されたデプロイを形成する。

  • デプロイのどの部分が失敗したかを簡単に確認する。

  • 完全な再デプロイを実行するのではなく、デプロイの失敗した部分のみを再実行する。

  • 同じステージ内の複数のステップにわたってデプロイ変数を共有します。

  • 同じステージで複数のステップにわたってデプロイ環境をロックします。

Deployment stages will also benefit from deployment permissions and concurrency control.

デプロイ ステージを作成するには、次の手順に従います。

  1. パイプラインに stage を追加します。

  2. ステージに deployment プロパティを追加します。

  3. ステージに適切な steps を追加します。

例:

pipelines: default: - step: name: Build and test script: - sh ./build-app.sh - stage: name: Deploy to staging deployment: staging steps: - step: name: Deploy script: - sh ./deploy-app.sh - step: name: Run end-to-end tests script: - sh ./run-e2e-tests.sh

このデプロイ ステージは次の 2 つのステップで構成されています。

  1. 最初のステップでは、アプリをステージング環境にデプロイします。

  2. 2 つ目のステップでは、ステージング環境に対してエンドツーエンドのテストを実行し、デプロイによって問題が発生しなかったことを確認します。

環境にステージを使用する

ステージで環境を使用すると、次のことが可能になります。

  • ステージ内のすべてのステップに同じ環境を設定する (環境のすべての権限が設定どおりに適用される)。

  • 同じステージ内の複数のステップにわたってデプロイ変数を共有する。

ステージに環境を設定するには、次の手順を実行します。

  1. パイプラインに stage を追加します。

  2. ステージに environment プロパティを追加します。

  3. ステージに適切な steps を追加します。

例:

pipelines: default: - step: name: Build and test script: - sh ./build-app.sh - stage: name: Steps using staging environment environment: staging steps: - step: name: Run end-to-end tests slice 1 script: - sh ./run-e2e-tests.sh - step: name: Run end-to-end tests slice 2 script: - sh ./run-e2e-tests.sh

未完了のデプロイ ステージを再実行する

デプロイ ステージ内で失敗、一時停止、または停止したステップを再実行することは、ステップを再実行することと似ています。ただし、追加で次のような条件があります。

  • The pipeline artifacts need to be still available (not expired).

  • ステージ内のステップを再実行できるのは、同じ環境で新しいデプロイや今後のデプロイがない場合のみです。

デプロイ ステージを再デプロイする

以前に成功したデプロイ ステージを再デプロイするには、次の手順に従います。

  • Ensure the pipeline artifacts need to be still available (not expired).

  • デプロイ ステージ全体を再実行します。

デプロイ ステージの未完了の再デプロイを再実行する

デプロイ ステージ内で失敗または停止したステップを再実行するには、次の手順に従います。

  • The pipeline artifacts need to be still available (not expired).

  • ステージ内のステップを再実行できるのは、同じ環境で新しいデプロイや今後のデプロイがない場合のみです。ステージは最初のステップから再デプロイできます。

制限事項

  • ステージに含めることができるステップの最大数は次のとおりです。

  • 並行ステージはサポートされていません。

  • ステージには並行ステップを含めることはできません。

  • ステージには手動でトリガーされるステップを含めることはできませんが、ステージを手動でトリガーするように設定することは可能です。

  • ステージには条件付きステップを含めることはできませんが、ステージを条件付きとして設定することは可能です。

  • ステージ内でのアーティファクト ダウンロードの無効化はサポートされていません。

  • ステップではステージに設定されているプロパティを上書きすることはできません。

  • 部分的に完了したデプロイ ステージは、それ以降に同じ環境に別の変更がデプロイされた場合は続行できなくなります。

ステージ オプション

次のオプションはステージを設定するために使用できます。

段階

ステージを使用すると、共有プロパティを持つパイプライン ステップをグループ化できます。たとえば、ステージを使用して、デプロイに必要なステップ (アプリのデプロイやデプロイの成否の確認など) をグループ化できます。

For information on creating and using Pipelines Stages, see Stages.

プロパティ — stage

必須 — いいえ

Data type — Block of new-line separated key-value pairs (YAML spec - Block Mapping)

Allowed parent properties — default, branches, pull-requests, tags, and custom

Allowed child properties — steps (required), name, deployment, environment, trigger, condition, and on-fail

例 — stage を使用して、パイプライン ステップをグループ化する

pipelines: default: - stage: name: Build and test steps: - step: name: Build app script: - sh ./build-app.sh - step: name: Run unit tests script: - sh ./run-tests.sh

手順

steps プロパティには、stage または parallel の step のリストが含まれます。ステップ リストには少なくとも 1 つの step が必要です。

プロパティ — steps

必須 — はい

Data type — Block of new-line separated key-value pairs (YAML spec - Block Mapping)

Allowed parent properties — parallel and stage

Allowed child properties — step (required)

例 — step プロパティを使用して、並行グループのステップをリストする

pipelines: default: - step: # sequential step name: Build script: - ./build.sh - step: # sequential step name: Build script: - ./build.sh - parallel: # these 2 steps will run in parallel steps: - step: name: Integration 1 script: - ./integration-tests.sh --batch 1 - step: name: Integration 2 script: - ./integration-tests.sh --batch 2 - step: # non-parallel step script: - ./deploy.sh

例 — step プロパティを使用して、ステージのステップをリストする

pipelines: default: - stage: name: Build and test steps: - step: name: Build app script: - sh ./build-app.sh - step: name: Run unit tests script: - sh ./run-tests.sh

条件

condition オプションは、条件またはルールが満たされた場合を除き、step や stage が実行されないようにします。Bitbucket Pipelines は changesets と state の 2 つの条件タイプをサポートしています。両方が指定されている場合、ステップまたはステージを実行するには両方の条件を満たす必要があります。changesets が最初に評価され、次に state が評価されます。

条件 changesets

次のいずれかに該当する場合、changesets を使用して step または stage を実行します。

  • 変更されたファイルのいずれかが includePaths の式と一致する。

  • 変更されたファイルのいくつかが excludePaths の式と一致しない。

The file match pattern specified in the includePaths and excludePaths is relative to the $BITBUCKET_CLONE_DIR directory.

考慮される変更内容

In a pull-requests pipeline, all commits are taken into account, and if you provide an list of patterns to includePaths or excludePaths, the step or stage will be executed when at least one commit change matches one of the conditions. The format for pattern matching follows the glob patterns.

その他のタイプのパイプラインでは最後のコミットのみが考慮されます。複数のコミットを同時にブランチにプッシュしたり、特定のブランチに複数回プッシュしたりすると、失敗している step または stage は次の実行でスキップされるため、失敗しているパイプラインのみが緑色に変わり、感覚的に不自然な動作が生じることがあります。

条件 state

state 条件を使用すると、ブール式が true と評価されたときのみ step または stage が実行されます。

条件が評価されるタイミングを理解する

  • 自動トリガー ステップの場合: ステップの開始準備が完了したとき、つまり前のステップが終了したときに条件が評価されます。

  • 手動トリガー ステップの場合:

    • 唯一の条件が changesets の場合、ステップを開始する準備ができたときに評価されます。

    • 条件に state 条件が含まれる場合、ユーザーが Run ボタンまたは Deploy ボタンを選択したときに評価されます。

特別なケース:

  • 再試行戦略を使用したステップ: ステップが再試行されるたびに条件が再評価されます。

  • ステップは開始されましたが停止しました: ステップが停止から再開されたときに再評価は行われません。

プロパティ — condition

必須 — いいえ

Data type — Block of new-line separated key-value pairs (YAML spec - Block Mapping)

Allowed parent properties — step and stage

Allowed child properties — changesets or state (required)

例 — condition オプションを使用して、特定のファイルの変更時のみにステップを実行する

pipelines: default: - step: name: step1 script: - echo "failing paths" - exit 1 condition: changesets: includePaths: # only xml files directly under path1 directory - "path1/*.xml" # any changes in deeply nested directories under path2 - "path2/**"

例 — condition オプションを使用して、特定のファイルの変更時のみにステージを実行する

pipelines: default: - stage: name: Build and test condition: changesets: includePaths: # only xml files directly under path1 directory - "path1/*.xml" # any changes in deeply nested directories under path2 - "path2/**" steps: - step: name: Build app script: - sh ./build-app.sh - step: name: Run unit tests script: - sh ./run-tests.sh

例 — 条件オプションを使用して、ブール式が true と評価された場合にのみステップを実行する

変数 prod_deployment_enabled は、環境、ワークスペース、リポジトリ、パイプライン変数で定義できます。

pipelines: default: - step: name: Deployment script: - echo "only deploy if variable prod_deployment_enabled is true" condition: state: prod_deployment_enabled == true

例 — 条件オプションを使用して、ブール式が true と評価された場合にのみステージを実行する

変数 prod_deployment_enabled は、環境、ワークスペース、リポジトリ、パイプライン変数で定義できます。

pipelines: default: - stage: name: Production Deployment condition: state: true steps: - step: name: Deployment script: - echo "only deploy if variable prod_deployment_enabled is true"

 

changesets

条件チェンジセット

changesets オプションは、step または stage の condition が特定の 1 つ以上のファイルでの変更であることを示すために使用されます。

プロパティ — changesets

Required — Required when using the condition option.

Data type — Block of new-line separated key-value pairs (YAML spec - Block Mapping)

Allowed parent properties — condition

Allowed child properties — either includePaths or excludePaths (required)

例 — condition オプションを使用して、特定のファイルの変更時のみにステップを実行する

pipelines: default: - step: name: step1 script: - echo "failing paths" - exit 1 condition: changesets: includePaths: # only xml files directly under path1 directory - "path1/*.xml" # any changes in deeply nested directories under path2 - "path2/**"
例 — condition オプションを使用して、特定のファイルの変更時のみにステージを実行する

pipelines: default: - stage: name: Build and test condition: changesets: includePaths: # only xml files directly under path1 directory - "path1/*.xml" # any changes in deeply nested directories under path2 - "path2/**" steps: - step: name: Build app script: - sh ./build-app.sh - step: name: Run unit tests script: - sh ./run-tests.sh
includePaths

condition および changesets オプションと一緒に使用すると、includePaths オプションによって、変更を確認するためのファイルまたはディレクトリのリストを提供できます。リスト内のファイルがコミットによって変更されている場合は step または stage が実行され、それ以外の場合はステップがスキップされます。

プロパティ — includePaths

必須 — いいえ

Data type — A list of file paths (glob patterns are allowed) (YAML spec - Sequence)

Allowed parent properties — changesets

例 — condition オプションを使用して、特定のファイルの変更時のみにステップを実行する
pipelines: default: - step: name: step1 script: - echo "failing paths" - exit 1 condition: changesets: includePaths: # only xml files directly under path1 directory - "path1/*.xml" # any changes in deeply nested directories under path2 - "path2/**"
例 — condition オプションを使用して、特定のファイルの変更時のみにステージを実行する
pipelines: default: - stage: name: Build and test condition: changesets: includePaths: # only xml files directly under path1 directory - "path1/*.xml" # any changes in deeply nested directories under path2 - "path2/**" steps: - step: name: Build app script: - sh ./build-app.sh - step: name: Run unit tests script: - sh ./run-tests.sh
excludePaths

condition および changesets オプションと一緒に使用すると、excludePaths オプションによって、変更を確認するためのファイルまたはディレクトリのリストを提供できます。コミットによって変更されているすべてのファイルがリストに含まれている場合は step または stage がスキップされ、それ以外の場合はステップが実行されます。

プロパティ — excludePaths

必須 — いいえ

Data type — A list of file paths (glob patterns are allowed) (YAML spec - Sequence)

Allowed parent properties — changesets

例 — condition オプションを使用して、特定のファイルの変更時にステップをスキップする

pipelines: default: - step: name: step1 script: - echo "failing paths" - exit 1 condition: changesets: excludePaths: # only xml files directly under path1 directory - "path1/*.xml" # any changes in deeply nested directories under path2 - "path2/**"
例 — condition オプションを使用して、特定のファイルの変更時にステージをスキップする

pipelines: default: - stage: name: Build and test condition: changesets: excludePaths: # only xml files directly under path1 directory - "path1/*.xml" # any changes in deeply nested directories under path2 - "path2/**" steps: - step: name: Build app script: - sh ./build-app.sh - step: name: Run unit tests script: - sh ./run-tests.sh

状態

条件 state

state オプションは、step または stage の condition がブール式であり、実行するには true と評価する必要があることを示すために使用されます。

プロパティ — state

Required — Required when using the condition option without specifying changesets condition

データ タイプ — 文字列

Allowed parent properties — condition

指定可能な子プロパティ — なし

例

  • (var_1 > 100 && var_1 <= 200) || var_2 == "ok" && var_3 == true

Expression language — specifications

コンテキスト変数

  • サポートされているソース: 環境、ワークスペース、リポジトリ、パイプライン変数

  • 保護された変数とボールト変数はサポートされていません。

  • リテラルと比較する場合の変数の動的タイプ推論:

    • var_1 == true var_1 はブール値 (真/偽) でなければなりません

    • var_2 > 100 var_2 は数値でなければなりません

    • var_3 == "hello world" var_3 は任意の文字列にすることができます

変数は既定で文字列として扱われます (ブール値または数値でない限り)。そのため、コンテキスト変数に文字列を割り当てるときは、二重引用符を追加しないでください。次に例を示します。

  • 変数値が hello の場合、

    • 条件 var_3 == "hello" は true として評価されます

  • 変数値が "hello" の場合 (二重引用符が明示的に使用されます)

    • 条件 var_3 == "hello" は false として評価されます

    • 条件 var_3 == "\"hello\"" は true として評価されます

制限

  • 式の最大長: 1000 文字

changesets と組み合わせた場合の評価順序

  • changesets と state の両方が存在する場合、ステップを実行するには両方が true でなければなりません

  • changesets が最初に評価されます。false の場合、state は評価されません

例 — ステート条件を使用して、変数が true の場合にのみステップを実行する
pipelines: default: - step: name: Plan Step script: - echo "has_change=true" >> $BITBUCKET_PIPELINES_VARIABLES_PATH output-variables: - has_change - step: name: Deployment Step condition: state: has_change == true script: - echo "deploying..."
例 — ステート条件を使用して、リポジトリ変数が true の場合にのみステージ内のステップを実行する
pipelines: default: - stage: name: Deployment condition: state: repo_var_deployment_enabled == true steps: - step: name: Build app script: - sh ./build-app.sh - step: name: Deploy app script: - sh ./deploy.sh

デプロイメント

Deployment の stage または step の環境を設定し、Deployment ダッシュボードを整理するために使用されます。Deployment ステージに属するすべてのステップが Deployment ステップになります。既定の環境: test、staging、または production。step または stage のデプロイ環境を設定するには、環境名を含めます。

詳細情報

プロパティ — deployment

必須 — いいえ

データ タイプ — 文字列

Allowed values — The name of a Deployment environment

Allowed parent properties — step and stage

例 — deployment を使用して、ステップのデプロイ環境を設定する

pipelines: default: - step: name: Deploy to production deployment: production env 1 script: - python deploy.py prod_env_1

例 — deployment を使用して、ステージのデプロイ環境を設定する

pipelines: default: - stage: name: Build and test deployment: staging steps: - step: name: Build app script: - sh ./build-app.sh - step: name: Run unit tests script: - sh ./run-tests.sh - stage: name: Deploy to Production deployment: prod trigger: manual steps: - step: name: Build app script: - sh ./build-app.sh - step: name: Run unit tests script: - sh ./run-tests.sh

環境

ステップまたはステージの環境を設定します。これにより、ブランチと管理者の権限のチェックに合格すれば、その環境を使用するステップが環境変数にアクセスできるようになります。

ステージで指定すると、そのステージ内のすべてのステップに同じ環境が割り当てられます。

step または stage の環境を設定するには、環境名を含めます。

詳細情報

プロパティ — environment

必須 — いいえ

データ タイプ — 文字列

Allowed values — The name of an Environment

Allowed parent properties — step and stage

例 — environment を使用してステップの環境を設定する

pipelines: default: - step: name: Deploy to production environment: production env 1 script: - python deploy.py prod_env_1

例 — environment を使用してステージの環境を設定する

pipelines: default: - stage: name: Build and test for staging environment: staging steps: - step: name: Build app script: - sh ./build-app.sh - step: name: Run unit tests script: - sh ./run-tests.sh - stage: name: Build and test for production environment: prod steps: - step: name: Build app script: - sh ./build-app.sh - step: name: Run unit tests script: - sh ./run-tests.sh

名前

step または stage の名前。名前は、Bitbucket Pipelines のログと Bitbucket UI に表示されます。名前は (パイプライン内で) 一意であり、ステージ内のステップを説明するものでなければなりません。

プロパティ — name

必須 — いいえ

データ タイプ — 文字列

Allowed parent properties — step and stage

例 - name を使用して 1 つのステージと 2 つのステップにラベルを付ける

pipelines: default: - stage: name: Build and test steps: - step: name: Build app script: - sh ./build-app.sh - step: name: Run unit tests script: - sh ./run-tests.sh - step: script: - pipe: atlassian/slack-notify:latest variables: WEBHOOK_URL: $SLACK_WEBHOOK PRETEXT: 'Hello, Slack!' MESSAGE: 'Hello, Slack!!'

トリガー

Sets the stage to run automatically (default behavior) or only when manually triggered by a user in the Bitbucket user interface. The first stage in a pipeline can't be manual. To set a whole pipeline to run manually, use a custom pipeline trigger. Manual steps and stages:

  • 最初の step または stage にはできません。

  • 設定されている順序でのみ実行できます。手動の step または stage はスキップできません。

  • 前の step または stage が正常に完了した場合のみ実行できます。

  • リポジトリへの書き込みアクセス権限を持つユーザーのみがトリガーできます。

  • Pipelines の Web インターフェイス経由でトリガーされます。

If your build uses both manual steps and artifacts, the artifacts are stored for 14 days following the execution of the step that produced them. After this time, the artifacts expire and any manual steps and manual stages in the pipeline can no longer be executed.

プロパティ — trigger

必須 — いいえ

データ タイプ — 文字列

指定可能な値 — automatic および manual

既定値 — automatic

Allowed parent properties — step and stage

例 — trigger を使用して、ステップを手動に設定する

pipelines: default: - step: name: Build script: - npm run build artifacts: - dist/** - step: name: Deploy trigger: manual script: - ./deploy.sh

例 — trigger を使用してステージを手動に設定する

pipelines: default: - stage: name: Linting steps: - step: script: - sh ./run-linter.sh - stage: name: Build and test trigger: manual steps: - step: name: Build app script: - sh ./build-app.sh - step: name: Run unit tests script: - sh ./run-tests.sh

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

アトラシアン コミュニティをご利用ください。
コミュニティに質問
このページの内容概要ステージをセットアップするデプロイにステージを使用する環境にステージを使用する未完了のデプロイ ステージを再実行するデプロイ ステージを再デプロイするデプロイ ステージの未完了の再デプロイを再実行する制限事項ステージ オプション段階例 — stage を使用して、パイプライン ステップをグループ化する手順条件状態デプロイメント環境名前トリガー
コミュニティ質問、ディスカッション、記事