ステップ オプション
これらのオプションは、コンパイラーやテストの実行など、コマンドとスクリプトを実行するために使用される必須の script
プロパティを含め、パイプラインのステップを定義するために使用されます。
パイプラインのステップ オプション
ステップは、次のオプションを受け入れます。
ステップのプロパティ
step
オプションは、ビルドの実行単位を定義するために使用されます。ステップは、bitbucket-pipelines.yml
ファイルに表示される順序で実行されます。1 つのパイプラインに、最大 100 のステップを含められます。
パイプラインの各ステップは個別の Docker コンテナーを起動し、script
オプションで構成されたコマンドを実行します。各ステップは、次のようなオプションを使用してカスタマイズできます。
runtime
– ステップのランタイム環境をカスタマイズします。cloud
atlassian-ip-ranges
image
— 別の Docker イメージを使用するため。max-time
— ステップの許容最大時間を設定するため。caches
とservices
— 特定のキャッシュとサービス用。artifacts
— 後続のステップが使用できるアーティファクトを保持します。clone
— ステップの Git クローン操作をカスタマイズするため。trigger
— パイプラインを続行する前に手動にする必要がある場合に、ステップをmanual
に設定するため。
Property — step
必須 — はい
データ タイプ — 改行で区切られたキーと値のペアのブロック (YAML 仕様 - ブロック マッピング)
指定可能な親プロパティ — branches、custom、default、pull-requests、steps、tags。
Allowed child properties — Requires the script property. The following properties are optional: after-script, artifacts, caches, clone, condition, deployment, fail-fast, image, name, oidc, runs-on, runtime, services, size, and trigger.
例 — 単一ステップを使用したパイプライン
pipelines:
default:
- step:
script:
- echo "Hello, World!"
例 — 連続および並行ステップを使用したパイプライン
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
必須の script
プロパティ
スクリプト
script
プロパティは、step
に対して実行されるコマンドのリストを指定するために使用されます。コマンドのリストは、コマンド間の自動クリーンアップ操作なしで、リストされている順序で実行されます。大規模なスクリプトは個別のスクリプト ファイルに移動し、それらを bitbucket-pipelines.yml
から呼び出すことをお勧めします。
Property — script
必須 — はい
Data type — A list of Strings and/or pipe
properties (YAML spec - Sequence)
指定可能な親プロパティ — step
指定可能な子プロパティ — pipe (オプション)
例 — script プロパティを使用して、基本的なコマンドを実行する
pipelines:
default:
- step:
script:
- echo "Hello, World!"
例 — script プロパティと個別のファイルを併用して、大規模なスクリプトを実行する
pipelines:
default:
- step:
script:
- ./long-build-script.sh
例 — script プロパティを使用して、単一のステップに対して一連のコマンドを実行する
pipelines:
default:
- step:
script:
- echo "Hello,"
- echo "World!"
- ./build.sh
例 — script と pipe プロパティを併用して、パイプを実行する
pipelines:
default:
- step:
name: Alert Opsgenie
script:
- echo "Sending an alert through Opsgenie"
- pipe: atlassian/opsgenie-send-alert:latest
variables:
GENIE_KEY: $GENIE_KEY
MESSAGE: "Danger, Will Robinson!"
DESCRIPTION: "An Opsgenie alert sent from Bitbucket Pipelines"
SOURCE: "Bitbucket Pipelines"
PRIORITY: "P1"
一般的なオプション
max-time
max-time
オプションは、タイムアウトする前にステップを実行できる最大時間 (分単位) を設定します。max-time
オプションは、グローバル options
プロパティと個々のパイプライン ステップの両方で設定できます。パイプライン ステップの既定の最大時間は 120 分です。
Property — max-time
必須 — いいえ
データ タイプ — 整数
Allowed values — A positive integer between 1
and 720
Default value — 120
例 — max-time オプションを使用して、パイプラインの各ステップに指定可能な最大時間を設定する
options:
max-time: 30
pipelines:
default:
- step:
name: Sleeping step
script:
- sleep 120m # This step will timeout after 30 minutes
例 — max-time オプションを使用して、パイプラインの個別のステップに指定可能な最大時間を設定する
options:
max-time: 60
pipelines:
default:
- step:
name: Sleeping step
script:
- sleep 120m # This step will timeout after 60 minutes
- step:
name: quick step
max-time: 5
script:
- sleep 120m # This step will timeout after 5 minutes
サイズ
size
オプションは、Bitbucket Cloud インフラストラクチャまたは Linux Docker セルフホストランナーで実行する場合、ステップまたはパイプライン全体に追加のリソースを割り当てます。
このオプションは、ホストマシン上で利用可能なすべてのリソースを使用する Windows PowerShell、macOS シェル、Linux シェルランナーなどのシェルベースのランナーには影響しません。
デフォルトでは、Bitbucket Cloud インフラストラクチャまたは Linux Docker セルフホスト ランナー上で実行されるステップは、ボリュームをマウントするために、4GB のメモリ、4 つの CPU (他のタスクと共有される場合があります)、step
あたり 64 GB のディスク容量にアクセスできます。2x
のサイズを指定すると、step
またはパイプラインの空きメモリは 2 倍になります。割り当てられたメモリは step
の script
と step.
の services
の両方で共有されることに注意してください。
4x
を超える size
オプションを選択すると、追加の CPU リソースとディスク容量も確保されます。step
に 4x
以上の size
が割り当てられていると、該当する数の CPU への専用アクセスが保証され、ボリュームをマウントするためのより多くのディスク容量が得られます。
4x ステップでは 1x ステップのビルド時間の 4 倍、2x ステップは 1x ステップのビルド時間の 2 倍を使用します。
サイズに基づくリソース割り当て
サイズ | CPU | メモリ | ボリューム サイズ |
---|---|---|---|
1x | 4 (共有) | 4 | 64 ギガバイト |
2x | 4 (共有) | 8 | 64 ギガバイト |
4x | 8 (専用) | 16 | 256 ギガバイト |
8x | 16 (専用) | 32 | 256 ギガバイト |
16x | 32 (専用) | 64 | 256 ギガバイト |
Property — size
必須 — いいえ
データ タイプ — 文字列
指定可能な値 — 次のいずれか:
Bitbucket Cloud で実行されるパイプライン ステップの場合、
1x
、2x
、4x
、8x
、または16x
セルフホストのパイプライン ランナーで実行されるパイプライン ステップの場合、
1x
、2x
、4x
、8x
、または16x
4x、8x、および 16x のパイプライン サイズ オプションは、有料の Bitbucket Cloud プラン (Standard または Premium) で実行されているビルドでのみ利用できます。
Default value — 1x
例 — size オプションを使用して、すべてのパイプライン ステップで利用可能なメモリを増やす
options:
size: 2x
pipelines:
default:
- step:
script:
- echo "2x memory is probably not needed for an echo command"
例 — size オプションを使用して、パイプライン ステップで利用可能なメモリを増やす
pipelines:
default:
- step:
size: 2x
script:
- echo "This step gets double the memory!"
ランタイム
ステップに適用されるランタイム設定です。
Property — runtime
必須 — いいえ
データ タイプ — 改行で区切られたキーと値のペアのブロック (YAML 仕様 - ブロック マッピング)
指定可能な親プロパティ — options と step
指定可能な子プロパティ — cloud (必須)
例 - ランタイムを使用して、4x、8x、および 16x のすべてのステップで atlassian-ip-ranges
を、すべてのステップで arm
を有効にする
options:
runtime:
cloud:
atlassian-ip-ranges: true
arch: arm
pipelines:
default:
- step:
size: 4x
script:
- echo "I use atlassian-ip-ranges"
例 - ランタイムを使用して、特定のステップで atlassian-ip-ranges
と arm
を有効にする
pipelines:
default:
- step:
size: 4x
runtime:
cloud:
atlassian-ip-ranges: true
arch: arm
script:
- echo "I use atlassian-ip-ranges"
クラウド ランタイム設定
クラウド ステップに適用されるランタイム設定です。
Property — cloud
必須 — いいえ
データ タイプ — 改行で区切られたキーと値のペアのブロック (YAML 仕様 - ブロック マッピング)
指定可能な親プロパティ — runtime
指定可能な子プロパティ — atlassian-ip-ranges (オプション)、arch (オプション)
クラウド ランタイム設定用のアトラシアン IP 範囲
このオプションでは、入出力トラフィックのステップを実行するときに、既定の aws-ip-ranges と atlassian-ip-ranges のどちらを使用するかを指定します。
Property — atlassian-ip-ranges
必須 — いいえ
データ タイプ — ブール値
Allowed values — true
or false
Default value — false
指定可能な親プロパティ — cloud
クラウド ランタイム設定のアーキテクチャ
このオプションは、ステップを実行するときに使用するアーキテクチャを制御します
Property — arch
必須 — いいえ
データ タイプ — 文字列
Allowed values — arm
or x86
Default value — x86
指定可能な親プロパティ — cloud
arm
オプションは、Bitbucket Cloud の Standard または Premium プランで実行されているビルドでのみ利用できます。
after-script
The after-script
option lists the commands that will run after the script
in the step
is completed, regardless of whether the script
succeeds or fails. This could be useful for clean up commands, test coverage, notifications, or rollbacks you might want to run. The BITBUCKET_EXIT_CODE
pipeline variable can be used to determine if the script
in the step
has succeed or failed.
after-script
のコマンドが失敗した場合
ステップの
after-script
にリストされたそれ以降のコマンドは実行されません。ステップに対して報告されているステータスには影響しません。
Property — after-script
必須 — いいえ
Data type — A list of Strings and/or pipe
properties (YAML spec - Sequence)
指定可能な親プロパティ — step
指定可能な子プロパティ — pipe (オプション)
例 — after-script オプションを使用して、script コマンドの後にコマンドを実行する
pipelines:
default:
- step:
name: Build and test
script:
- npm install
- npm test
after-script:
- echo "after script has run!"
名前
step
または stage
の名前。名前は、Bitbucket Pipelines のログと Bitbucket UI に表示されます。名前は (パイプライン内で) 一意であり、ステージ内のステップを説明するものでなければなりません。
Property — name
必須 — いいえ
データ タイプ — 文字列
例 - 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!!'
フェイル ファスト
fail-fast
は、すべての parallel
ステップに適用することもできれば、並行ステップの特定の step
に適用することもできます。
ステップに
fail-fast: false
が含まれる場合、並行グループ全体が停止することなく、ステップが失敗することがあります。ステップに
fail-fast: true
が含まれる場合、ステップが失敗すると、並行グループ全体が停止します。
Property — fail-fast
必須 — いいえ
データ タイプ — ブール値
Allowed values — true
or false
Default value — false
例 — fail-fast を使用して、いずれかのステップが失敗した時点で並行ステップを停止する
pipelines:
default:
- step:
name: Build
script:
- ./build.sh
- parallel:
# this option allows a force stop on all running steps if any step fails
fail-fast: true
steps:
- step:
name: Integration 1
script:
- ./integration-tests.sh --batch 1
- step:
name: Integration 2
script:
- ./integration-tests.sh --batch 2
例 — fail-fast から並行ステップを除外する
pipelines:
default:
- step:
name: Build
script:
- ./build.sh
- parallel:
# this option allows a force stop on all running steps if any step fails
fail-fast: true
steps:
- step:
name: Integration 1
script:
- ./integration-tests.sh --batch 1
- step:
name: Integration 2
script:
- ./integration-tests.sh --batch 2
- step:
# option can be disabled for a step
# and its failure won't stop other steps in a group
fail-fast: false
name: Upload metadata
script:
- ./upload-metadata.sh
on-fail
on-fail
オプションはデプロイ段階/ステップでは使用できません。
on-fail
オプションでは、失敗したステップを Bitbucket Pipelines でどのように処理するかをカスタマイズできます。strategy
フィールドを使用して動作を設定できます。次の 2 つの戦略があります。
strategy: fail
: この戦略が設定されたステップが失敗すると、パイプライン全体が停止し、失敗とマークされます。これは既定の戦略で、何も指定しない場合は自動的にこの戦略が使用されます。strategy: ignore
: この戦略が設定されたステップが失敗した場合、そのステップは UI で「失敗」とマークされますが、パイプライン全体では失敗は無視され、残りのステップは引き続き実行されます。ignore
戦略を使用したステップが失敗しても、パイプライン全体は失敗とはなりません。
Only the fail
strategy is compatible with fail-fast
. ignore
strategy will be disabled if you have fail-fast
at the same step or other parallel steps within the same parallel group.
Property — on-fail
必須 — いいえ
データ タイプ — 改行で区切られたキーと値のペアのブロック (YAML 仕様 - ブロック マッピング)
指定可能な親プロパティ — step
例 — on-fail を使用してステップの失敗を無視する
pipelines:
default:
- step:
# The outcome of this step will be ignored
name: 'Run linting'
on-fail:
strategy: ignore
script:
- npm install
- npm run lint
- step:
# This step will always be executed regardless the outcome of the previous stepl.
name: 'Run tests'
script:
- npm install
- npm run test
例 — on-fail を使用して並行ステップ内のステップの失敗を無視する
pipelines:
default:
- parallel:
name: Parallel
# The outcome of this parallel step will be determined only by the second step.
steps:
- step:
name: 'Run linting'
on-fail:
strategy: ignore
script:
- npm install
- npm run lint
- step:
name: 'Run tests'
script:
- npm install
- npm run test
キャッシュとアーティファクト
キャッシュ
ステップの caches
オプションは、依存関係が外部ソース (npm や PyPI のようなパッケージ リポジトリなど) からダウンロードされるステップを示すために使用されます。これによって、外部ビルド依存関係を再度ダウンロードすることなく、以前に定義したキャッシュを作成、アップデート、または再利用できます。定義済みのカスタム キャッシュも使用できれば、定義済みのキャッシュのいずれかも使用できます。定義済みのキャッシュの完全なリストについては「 キャッシュ — 定義済みのキャッシュ」をご確認ください。
caches
オプションの使用に関する情報は、「キャッシュ」をご参照ください。
Property — caches
必須 — いいえ
データ タイプ — 文字列のリスト (YAML 仕様 - シーケンス)
指定可能な値 — 定義済みパイプライン キャッシュの名前とカスタム キャッシュの名前。
指定可能な親プロパティ — step
例 — caches オプションを使用して、Ruby プロジェクトの依存関係をキャッシュする
definitions:
caches:
my-bundler-cache: vendor/bundle
pipelines:
default:
- step:
caches:
- my-bundler-cache # Cache is defined above in the definitions section
- node # Pre-defined Pipelines cache
script:
- bundle install --path vendor/bundle
- ruby -e 'print "Hello, World\n"'
アーティファクト
artifacts
オプションは、パイプラインの後からのステップで必要なビルド アーティファクトを含むファイルまたはディレクトリをリストするために使用されます。アーティファクトのパスは BITBUCKET_CLONE_DIR
変数に対する相対パスで、glob パターンを使用して定義できます。
アーティファクトの詳細については「アーティファクトをステップで使用する」をご確認ください。
Property — artifacts
必須 — いいえ
データ タイプ — 次のいずれか:
ファイル パスのリスト (glob パターンを指定可能) (YAML 仕様 - シーケンス)
改行で区切られたキーと値のペアのブロック (YAML仕様 - ブロック マッピング)
指定可能な親プロパティ — step
指定可能な子プロパティ — download と paths
例 — artifacts を使用して、構築済みコードを次のステップに渡してテストする
pipelines:
default:
- step:
name: Build and test
script:
- npm install
- npm run build
artifacts:
- dist/**
- step:
name: Test code from build step stored in the dist/ directory
script:
- npm test
例 — artifacts、download、paths を使用して、後のステップにアーティファクトを渡す
pipelines:
default:
- step:
name: Build and test
script:
- npm install
- npm run build
artifacts: # Store build artifacts for use in the following steps
- dist/**
- step:
name: lint code and store results
script:
- npm lint > results.txt
artifacts:
download: false # Block artifacts downloading, they're not needed for this step
paths: # Store the linting result (in addition to the dist/ directory)
- results.txt
- step:
name: Test code from build step stored in the dist/ directory
script:
- npm test
アーティファクトのダウンロード
アーティファクトの download
オプションは、step
の開始時に前のステップからのアーティファクトをダウンロードするかどうかを制御するために使用されます。
download: true
— (既定の動作) ステップの開始時に前のステップからのアーティファクトが開始され、step
のscripts
で使用できるようになります。download: false
— 前のステップからのアーティファクトは、このstep
では使用できなくなります。
アーティファクトの使用方法に関する詳細については「アーティファクトをステップで使用する」をご確認ください。
Property — download
必須 — いいえ
データ タイプ — ブール値
Allowed values — true
or false
Default value — True
指定可能な親プロパティ — artifacts
例 — download オプションを使用して、ステップでアーティファクトがダウンロードされないようにする
pipelines:
default:
- step:
name: Build and test
script:
- npm install
- npm run build
artifacts: # Store build artifacts for use in the following steps
- dist/**
- step:
name: lint code and store results
script:
- npm lint > results.txt
artifacts:
download: false # Block artifacts downloading, they're not needed for this step
- step:
name: Test code from build step stored in the dist/ directory
script:
- npm test
例 — アーティファクトの download および paths オプションを併用する
pipelines:
default:
- step:
name: Build and test
script:
- npm install
- npm run build
artifacts: # Store build artifacts for use in the following steps
- dist/**
- step:
name: lint code and store results
script:
- npm lint > results.txt
artifacts:
download: false # Block artifacts downloading, they're not needed for this step
paths: # Store the linting result (in addition to the dist/ directory)
- results.txt
- step:
name: Test code from build step stored in the dist/ directory
script:
- npm test
アーティファクトのパス
アーティファクトの paths
オプションは、パイプラインの後からのステップで必要なビルド アーティファクトを含むファイルまたはディレクトリをリストするために使用されます。paths
オプションは、アーティファクトの download
オプションが定義されている場合にのみ必要で、それ以外の場合、これらのパスは artifacts
オプションの下にリストできます。アーティファクトのパスは BITBUCKET_CLONE_DIR
変数に対する相対パスで、glob パターンを使用して定義できます。
アーティファクトの詳細については「アーティファクトをステップで使用する」をご確認ください。
Property — paths
必須 — いいえ
データ タイプ — パスのリスト (glob パターンを指定可能) (YAML 仕様 - シーケンス)
指定可能な親プロパティ — artifacts
例 — アーティファクトの paths オプションを使用して、後のステップで使用するファイルを保持する
pipelines:
default:
- step:
name: Build and test
script:
- npm install
- npm run build
artifacts: # Store build artifacts for use in the following steps
- dist/**
- step:
name: lint code and store results
script:
- npm lint > results.txt
artifacts:
download: false # Block artifacts downloading, they're not needed for this step
paths: # Store the linting result (in addition to the dist/ directory)
- results.txt
- step:
name: Test code from build step stored in the dist/ directory
script:
- npm test
パイプ
pipe
パイプは多くの作業をバックグラウンドで実行して、複雑なタスクを容易にします。つまり、ユーザーは使用したいパイプを選択し、必要な変数を指定するだけです。パイプのリポジトリで、実行中のコマンドを確認できます。
カスタム Pipes の作成および使用方法を含む、Pipes の詳細については「Bitbucket Pipelines でパイプを使用する」をご確認ください。
使用可能なパイプのリストとそれらの使用方法に関する説明については「Bitbucket Pipes 統合」をご確認ください。
Property — pipe
必須 — いいえ
データ タイプ — 文字列
指定可能な値 — Docker ベースのパイプのアドレス。
指定可能な親プロパティ — script と after-script
指定可能な子プロパティ - variables (ほとんどのパイプで必須)
例 — pipe オプションとともに、公式の Opsgenie パイプを使用して Opsgenie アラートを送信する
pipelines:
default:
- step:
name: Alert Opsgenie
script:
- pipe: atlassian/opsgenie-send-alert:latest
variables:
GENIE_KEY: $GENIE_KEY
MESSAGE: "Danger, Will Robinson!"
DESCRIPTION: "An Opsgenie alert sent from Bitbucket Pipelines"
SOURCE: "Bitbucket Pipelines"
PRIORITY: "P1"
例 — pipe を使用して、Opsgenie と Slack にメッセージを送信する
pipelines:
default:
- step:
name: Alert everyone!
script:
- pipe: atlassian/opsgenie-send-alert:latest
variables:
GENIE_KEY: $GENIE_KEY
MESSAGE: 'Wake up!'
- pipe: atlassian/slack-notify:latest
name: Send alert to Slack
variables:
WEBHOOK_URL: $SLACK_WEBHOOK
PRETEXT: 'Alert Everyone!'
MESSAGE: 'We have a problem!'
例 — pipe オプションを使用して、カスタム パイプを実行する
pipelines:
default:
- step:
name: Running my custom pipe
script:
- pipe: docker://<DockerAccountName>/<ImageName>:<version>
variables:
USERNAME: $My_username
PASSWORD: $Password
パイプ変数
パイプの variables
オプションは、パイプの環境変数を設定するために使用されます。必須または使用可能な変数は、パイプによって異なります。
カスタム Pipes の作成および使用方法を含む、Pipes の詳細については「Bitbucket Pipelines でパイプを使用する」をご確認ください。
使用可能なパイプのリストとそれらの使用方法に関する説明については「Bitbucket Pipes 統合」をご確認ください。
シークレットとログイン認証情報は、漏洩を防ぐためにユーザー定義のパイプライン変数として保存する必要があります。詳細は「変数とシークレット — ユーザー定義の変数」をご参照ください。
Property — variables
必須 — パイプによって異なります
データ タイプ — 改行で区切られたキーと値のペアのブロック (YAML 仕様 - ブロック マッピング)
指定可能な親プロパティ — pipe
例 — variables を使用して、2 つのパイプを設定して実行する
次の例は、Opsgenie Send Alert パイプと Slack Notify パイプを示しています。
pipelines:
default:
- step:
name: Alert everyone!
script:
- pipe: atlassian/opsgenie-send-alert:latest
name: Send alert to Opsgenie
variables:
GENIE_KEY: $GENIE_KEY
MESSAGE: 'Wake up!'
- pipe: atlassian/slack-notify:latest
name: Send alert to Slack
variables:
WEBHOOK_URL: $SLACK_WEBHOOK
PRETEXT: 'Alert Everyone!'
MESSAGE: 'We have a problem!'
ランナー
runs-on
自社ホストのパイプライン ランナーのみが利用可能です。
自社ホスト ランナーでパイプライン ステップを実行するには、runs-on
オプションをステップに追加します。パイプラインを実行すると、ステップは、リストされたすべてのラベルを含む、次に使用可能なランナーで実行されます。一致するすべてのランナーがビジー状態の場合、1 つのランナーが再び使用可能になるまでステップは待機します。リポジトリ内にすべてのラベルに一致するオンライン ランナーがない場合、ステップは失敗します。
関連情報
自社ホスト パイプライン ランナーについては「ランナー」をご確認ください。
ランナーを使用するようにパイプライン ステップを設定する方法については「bitbucket-pipelines.yml でランナーを設定する」をご確認ください。
Property — runs-on
必須 — いいえ
データ タイプ — 次のいずれか:
文字列
文字列のリスト (YAML 仕様 - シーケンス)
Allowed values — Any Label assigned to a self-hosted Repository or Workspace Pipeline runner (such as self.hosted
).
指定可能な親プロパティ — step
例 — runs-on オプションを使用して、自社ホストランナーでステップを実行する
pipelines:
default:
- step:
name: Step 1
runs-on:
- 'self.hosted'
- 'my.custom.label'
script:
- echo "This step will run on a self-hosted runner with the 'my.custom.label' and 'self.hosted' labels.";
- step:
name: Step 2
script:
- echo "This step will run on Atlassian's infrastructure as usual.";
docker images
ステップでの image
オプションの使用方法を含め、image
オプションの詳細については「Docker イメージ オプション」をご確認ください。
Git clone オプション
ステップでの clone
オプションの使用方法を含め、clone
オプションの詳細については「Git clone の動作」をご確認ください。
フロー制御
条件
condition
オプションは、条件またはルールが満たされた場合を除き、step
または stage
が実行されないようにします。現在、サポートされている条件は changesets
のみです。変更したファイルのいずれかが includePaths
の表現と一致する場合のみ、changesets
を使用して、step
または stage
を実行できます。includePaths
に指定されたファイル一致パターンは、$BITBUCKET_CLONE_DIR
ディレクトリに対して相対的です。
考慮される変更内容
pull-requests
パイプラインでは、すべてのコミットが考慮され、パターンの includePath
リストが提供されている場合は、少なくとも 1 つのコミットの変更が条件のいずれかに一致したときに、step
または stage
が実行されます。パターン マッチングの形式は、glob パターンに従います。
その他のタイプのパイプラインでは最後のコミットのみが考慮されます。複数のコミットを同時にブランチにプッシュしたり、特定のブランチに複数回プッシュしたりすると、失敗している step
または stage
は次の実行でスキップされるため、失敗しているパイプラインのみが緑色に変わり、感覚的に不自然な動作が生じることがあります。
Property — condition
必須 — いいえ
データ タイプ — 改行で区切られたキーと値のペアのブロック (YAML 仕様 - ブロック マッピング)
指定可能な子プロパティ — 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
条件チェンジセット
changesets
オプションは、step
または stage
の condition
が特定の 1 つ以上のファイル (includePaths
) での変更であることを示すために使用されます。
Property — changesets
必須 — condition オプションを使用する場合は必須です。
データ タイプ — 改行で区切られたキーと値のペアのブロック (YAML 仕様 - ブロック マッピング)
指定可能な親プロパティ — condition
指定可能な子プロパティ — includePaths (必須)
例 — 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
条件付きチェンジセットを含むディレクトリ
condition
および changesets
オプションと一緒に使用すると、includePaths
オプションによって、変更を確認するためのファイルまたはディレクトリのリストを提供できます。リスト内のファイルがコミットによって変更されている場合は step
または stage
が実行され、それ以外の場合はステップがスキップされます。
Property — includePaths
必須 — いいえ
データ タイプ — パスのリスト (glob パターンを指定可能) (YAML 仕様 - シーケンス)
指定可能な親プロパティ — 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
トリガー
ステージを自動的に実行する (既定の動作) か、Bitbucket ユーザー インターフェイスでユーザーが手動でトリガーした場合にのみ実行するように設定します。パイプライン内の最初のステージは手動にはできません。パイプライン全体を手動で実行するように設定するには、カスタム パイプライン トリガーを使用します。以下は、手動のステップとステージの特徴です。
最初の
step
またはstage
にはできません。設定されている順序でのみ実行できます。手動の
step
またはstage
はスキップできません。前の
step
またはstage
が正常に完了した場合のみ実行できます。リポジトリへの書き込みアクセス権限を持つユーザーのみがトリガーできます。
Pipelines の Web インターフェイス経由でトリガーされます。
ビルドが手動ステップとアーティファクトの両方を使用している場合、アーティファクトはそれらのアーティファクトを生成したステップの実行後 14 日間保存されます。この期間が過ぎると、アーティファクトは期限切れとなり、パイプラインでは以降のあらゆる手動ステップと手動ステージを実行できなくなります。
Property — trigger
必須 — いいえ
データ タイプ — 文字列
Allowed values — automatic
and manual
Default value — automatic
例 — 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
サービス — サービス コンテナーと OIDC リソース
OpenID Connect (OIDC) リソース
oidc
オプションは、パイプライン ステップをリソース サーバーに接続するための OpenID Connect の使用を有効にします。oidc
の値を、true
に設定する必要があります。その後、OpenID Connect を設定します。パイプラインでの OIDC の使用方法に関する詳細については「OIDC を使用して Pipelines とリソース サーバーを統合する」をご確認ください。
Property — oidc
必須 — いいえ
データ タイプ — ブール値
Allowed values — true
or false
Default value — false
指定可能な親プロパティ — step
例 — oidc オプションを使用して、パイプライン ステップをリソース サーバーに接続する
pipelines:
default:
- step:
oidc: true
script:
- echo "I can access data through OpenID Connect!"
- aws sts assume-role-with-web-identity --role-arn arn:aws:iam::XXXXXX:role/projectx-build --role-session-name build-session --web-identity-token "$BITBUCKET_STEP_OIDC_TOKEN" --duration-seconds 1000
サービス
Bitbucket Pipelines can create separate Docker containers for services, which results in faster builds, and easy service editing. For details on creating services see Databases and service containers. This services
option is used to indicate which steps require previously defined services.
Property — services
必須 — いいえ
データ タイプ — 文字列のリスト (YAML 仕様 - シーケンス)
指定可能な値 — definitions > services の下で定義済みのサービスの名前
指定可能な親プロパティ — step
例 — ステップの services オプションを使用して、どのステップが my-service-name データベース サービスを必要としているかを示す
definitions:
services:
my-service-name:
image: mariadb:latest
variables:
MARIADB_USER: $MY_MARIADB_USER
MARIADB_PASSWORD: $MY_MARIADB_PASSWORD
MARIADB_ROOT_PASSWORD: $MARIADB_ADMIN_PASSWORD
pipelines:
default:
- step:
name: Hello world example
services:
- my-service-name
script:
- echo "Hello, World"
デプロイメント
デプロイメント
Sets the environment for a Deployment stage
or step
and is used to organize the Deployment dashboard. All steps that belong to the Deployment stage will be a Deployment step. The default environments are: test
, staging
, or production
. To set the deployment environment of a step
or stage
, include the Environment name.
詳細情報
デプロイ ステージについては「デプロイ ステージ」をご確認ください。
デプロイ環境の作成と設定については「デプロイのセットアップと監視」をご確認ください。
Property — deployment
必須 — いいえ
データ タイプ — 文字列
指定可能な値 — デプロイ環境の名前
例 — 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
この内容はお役に立ちましたか?