ステージ オプション

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

概要

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

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

1 2 3 4 5 6 7 8 9 10 11 12 13 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

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

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

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

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

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

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

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

また、デプロイ ステージは、デプロイ権限同時実行制御による恩恵も受けます。

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

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

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

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

例:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 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 つ目のステップでは、ステージング環境に対してエンドツーエンドのテストを実行し、デプロイによって問題が発生しなかったことを確認します。

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

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

  • パイプライン アーティファクトがまだ使用可能である必要があります (有効期限が切れていないこと)。

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

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

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

  • パイプライン アーティファクトがまだ使用可能であること (有効期限が切れていないこと) を確認します。

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

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

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

  • パイプライン アーティファクトがまだ使用可能である必要があります (有効期限が切れていないこと)。

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

制限事項

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

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

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

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

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

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

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

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

ステージ オプション

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

段階

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

パイプライン ステージの作成と使用については、「ステージ」を参照してください。

プロパティstage

必須 — いいえ

データ タイプ — 改行で区切られたキーと値のペアのブロック (YAML 仕様 - ブロック マッピング)

指定可能な親プロパティdefaultbranchespull-requeststagscustom

指定可能な子プロパティsteps (必須)、namedeploymenttriggercondition

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

1 2 3 4 5 6 7 8 9 10 11 12 13 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 または parallelstep のリストが含まれます。ステップ リストには少なくとも 1 つの step が必要です。

プロパティsteps

必須 — はい

データ タイプ — 改行で区切られたキーと値のペアのブロック (YAML 仕様 - ブロック マッピング)

指定可能な親プロパティparallelstage

指定可能な子プロパティstep (必須)

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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 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 プロパティを使用して、ステージのステップをリストする

1 2 3 4 5 6 7 8 9 10 11 12 13 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 が実行されないようにします。現在、サポートされている条件は changesets のみです。変更したファイルのいずれかが includePaths の表現と一致する場合のみ、changesets を使用して、step または stage を実行できます。includePaths に指定されたファイル一致パターンは、$BITBUCKET_CLONE_DIR ディレクトリに対して相対的です。

考慮される変更内容

pull-requests パイプラインでは、すべてのコミットが考慮され、パターンの includePath リストが提供されている場合は、少なくとも 1 つのコミットの変更が条件のいずれかに一致したときに、step または stage が実行されます。パターン マッチングの形式は、glob パターンに従います。

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

プロパティcondition

必須 — いいえ

データ タイプ — 改行で区切られたキーと値のペアのブロック (YAML 仕様 - ブロック マッピング)

指定可能な親プロパティstepstage

指定可能な子プロパティchangesets (必須)

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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 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 オプションを使用して、特定のファイルの変更時のみにステージを実行する

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 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

changesets

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

プロパティchangesets

必須condition オプションを使用する場合は必須です。

データ タイプ — 改行で区切られたキーと値のペアのブロック (YAML 仕様 - ブロック マッピング)

指定可能な親プロパティcondition

指定可能な子プロパティincludePaths (必須)

例 — condition オプションを使用して、特定のファイルの変更時のみにステップを実行する
1 2 3 4 5 6 7 8 9 10 11 12 13 14 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 オプションを使用して、特定のファイルの変更時のみにステージを実行する
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 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

必須 — いいえ

データ タイプ — パスのリスト (glob パターンを指定可能) (YAML 仕様 - シーケンス)

指定可能な親プロパティchangesets

例 — condition オプションを使用して、特定のファイルの変更時のみにステップを実行する
1 2 3 4 5 6 7 8 9 10 11 12 13 14 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 オプションを使用して、特定のファイルの変更時のみにステージを実行する
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 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

デプロイメント

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

詳細情報

プロパティdeployment

必須 — いいえ

データ タイプ — 文字列

指定可能な値デプロイ環境の名前

指定可能な親プロパティstepstage

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

1 2 3 4 5 6 7 pipelines: default: - step: name: Deploy to production deployment: production env 1 script: - python deploy.py prod_env_1

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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 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 の名前。名前は、Bitbucket Pipelines のログと Bitbucket UI に表示されます。名前は (パイプライン内で) 一意であり、ステージ内のステップを説明するものでなければなりません。

プロパティname

必須 — いいえ

データ タイプ — 文字列

指定可能な親プロパティstepstage

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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 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!!'

トリガー

ステージを自動的に実行する (既定の動作) か、Bitbucket ユーザー インターフェイスでユーザーが手動でトリガーした場合にのみ実行するように設定します。パイプライン内の最初のステージは手動にはできません。パイプライン全体を手動で実行するように設定するには、カスタム パイプライン トリガーを使用します。以下は、手動のステップとステージの特徴です。

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

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

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

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

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

ビルドが手動ステップとアーティファクトの両方を使用している場合、アーティファクトはそれらのアーティファクトを生成したステップの実行後 14 日間保存されます。この期間が過ぎると、アーティファクトは期限切れとなり、パイプラインでは以降のあらゆる手動ステップと手動ステージを実行できなくなります。

プロパティtrigger

必須 — いいえ

データ タイプ — 文字列

指定可能な値automaticmanual

既定値automatic

指定可能な親プロパティstepstage

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

1 2 3 4 5 6 7 8 9 10 11 12 13 pipelines: default: - step: name: Build script: - npm run build artifacts: - dist/** - step: name: Deploy trigger: manual script: - ./deploy.sh

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

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 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

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

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