ステップオプション

これらのオプションは、コンパイラーやテストの実行など、コマンドとスクリプトを実行するために使用される必須の 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 に設定するため。

プロパティ — step

必須 — はい

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

指定可能な親プロパティ — branches、custom、default、pull-requests、steps、tags。

指定可能な子プロパティ — script プロパティは必須です。次のプロパティはオプションです: after-script、artifacts、caches、clone、condition、deployment、fail-fast、image、name、oidc、runs-on、runtime、services、size、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

`type` プロパティ

type プロパティは、ステップのタイプを指定するために使用されます。既定値は、通常のインラインステップを表す type: inline です。type: inline プロパティ以外に、子パイプライン (パイプライン内で実行されるパイプライン) をトリガーするために使用される type: pipeline プロパティがあります。

パイプラインステップの詳細については、「子パイプラインステップのオプション」を参照してください。

プロパティ — type

必須 — いいえ (既定値は type:inline)

データタイプ — inline または pipeline のいずれか

指定可能な親プロパティ — step

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

`script` プロパティ

スクリプト

script プロパティは、step に対して実行されるコマンドのリストを指定するために使用されます。コマンドのリストは、コマンド間の自動クリーンアップ操作なしで、リストされている順序で実行されます。大規模なスクリプトは個別のスクリプトファイルに移動し、それらを bitbucket-pipelines.yml から呼び出すことをお勧めします。

プロパティ — script

必須 — いいえ (type = inline の場合にのみ必須)

データタイプ — 文字列や pipe プロパティのリスト (YAML 仕様 - シーケンス)

指定可能な親プロパティ — 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 分です。

プロパティ — max-time

必須 — いいえ

データタイプ — 整数

指定可能な値 — 1 ～ 720 の正の整数

既定値 — 120

指定可能な親プロパティ — options と step

例 — 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	2	4	64 ギガバイト
2x	4	8	64 ギガバイト
4x	8	16	256 ギガバイト
8x	16	32	256 ギガバイト
16x	32	64	256 ギガバイト

プロパティ — size

必須 — いいえ

データタイプ — 文字列

指定可能な値 — 次のいずれか:

Bitbucket Cloud で実行されるパイプラインステップの場合、1x、2x、4x、8x、または 16x
セルフホストのパイプラインランナーで実行されるパイプラインステップの場合、1x、2x、4x、8x、または 16x

4x、8x、および 16x のパイプラインサイズオプションは、有料の Bitbucket Cloud プラン (Standard または Premium) で実行されているビルドでのみ利用できます。

既定値 — 1x

指定可能な親プロパティ — options と step

例 — 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!"

ランタイム

ステップに適用されるランタイム設定です。

プロパティ — 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"

クラウドランタイム設定

クラウドステップに適用されるランタイム設定です。

プロパティ — cloud

必須 — いいえ

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

指定可能な親プロパティ — runtime

指定可能な子プロパティ — atlassian-ip-ranges (オプション)、arch (オプション)

クラウドランタイム設定用のアトラシアン IP 範囲

このオプションでは、入出力トラフィックのステップを実行するときに、既定の aws-ip-ranges と atlassian-ip-ranges のどちらを使用するかを指定します。

プロパティ — atlassian-ip-ranges

必須 — いいえ

データタイプ — ブール値

指定可能な値 — true または false

既定値 — false

指定可能な親プロパティ — cloud

クラウドランタイム設定のアーキテクチャ

このオプションは、ステップを実行するときに使用するアーキテクチャを制御します

プロパティ — arch

必須 — いいえ

データタイプ — 文字列

指定可能な値 — arm または x86

既定値 — x86

指定可能な親プロパティ — cloud

arm オプションは、Bitbucket Cloud の Standard または Premium プランで実行されているビルドでのみ利用できます。

after-script

after-script オプションは、script が成功したか失敗したかに関係なく、step の script が完了した後に実行されるコマンドをリストします。これは、コマンドのクリーンアップ、カバレッジのテスト、通知、ロールバックを実行する場合に役立ちます。BITBUCKET_EXIT_CODE パイプライン変数は、step の script が成功したか、失敗したかを判別するために使用できます。

after-script のコマンドが失敗した場合

ステップの after-script にリストされたそれ以降のコマンドは実行されません。
ステップに対して報告されているステータスには影響しません。

プロパティ — after-script

必須 — いいえ

データタイプ — 文字列や pipe プロパティのリスト (YAML 仕様 - シーケンス)

指定可能な親プロパティ — 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 に表示されます。名前は (パイプライン内で) 一意であり、ステージ内のステップを説明するものでなければなりません。

プロパティ — name

必須 — いいえ

データタイプ — 文字列

指定可能な親プロパティ — step と 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!!'

フェイルファスト

fail-fast は、すべての parallel ステップに適用することもできれば、並行ステップの特定の step に適用することもできます。

ステップに fail-fast: false が含まれる場合、並行グループ全体が停止することなく、ステップが失敗することがあります。
ステップに fail-fast: true が含まれる場合、ステップが失敗すると、並行グループ全体が停止します。

プロパティ — fail-fast

必須 — いいえ

データタイプ — ブール値

指定可能な値 — true または false

既定値 — false

指定可能な親プロパティ — step と parallel

例 — 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: retry: この戦略が設定されたステップが失敗すると、そのステップは自動的に再試行されます。この戦略では、on-fail に次のオプションが追加されます。
- maxRetryCount: 最大再試行回数を制限するオプションの値。1 から 10 までの整数を指定できます。値を指定しない場合の既定値は 1 です。
strategy: ignore: この戦略が設定されたステップが失敗した場合、そのステップは UI で「失敗」とマークされますが、パイプライン全体では失敗は無視され、残りのステップは引き続き実行されます。ignore 戦略を使用したステップが失敗しても、パイプライン全体は失敗とはなりません。

並行グループに関する注意事項: fail 戦略のみが fail-fast と互換性があります。ignore および retry 戦略は、同じステップ、また同じ並行グループ内の他の並行ステップに fail-fast がある場合は無効になります。

プロパティ — on-fail

必須 — いいえ

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

指定可能な親プロパティ — step、parallel、stage

例 — 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:
        # 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

例 — on-fail を使用して並行グループ内のすべての失敗を再試行する

pipelines:
  default:
    - parallel:
        on-fail:
          strategy: retry
          maxRetryCount: 3
        steps:
          - step:
              name: 'Run test set 1'
              on-fail:
                strategy: ignore 
              script:
                - npm install
                - npm run test set1
          - step:
               # This step will retry up to 10 times until it passes
              name: 'Run test set 2'
              on-fail:
                strategy: retry
                maxRetryCount: 10 # This will override the value from the parent parallel group.
              script:
                - npm install
                - npm run test set2

例 — on-fail を使用してステージ内のすべての失敗を再試行する

pipelines:
  default:
    - stage:
        name: "flaky stage"
        on-fail:
          strategy: retry
          maxRetryCount: 3
        steps:
          - step:
              # This step will retry up to 3 times until it passes
              name: 'Run test set'
              script:
                - npm install
                - npm run test

出力変数

ステップの output-variables オプションを使用して、ステップから共有パイプライン変数にエクスポートできる変数のリストを定義します。

共有パイプライン変数の使用方法については、変数とシークレットに関するヘルプドキュメントを参照してください。

プロパティ — output-variables

必須 — いいえ

データタイプ — 文字列のリスト (YAML 仕様 - シーケンス)

指定可能な値 — 有効な変数名

名前には ASCII 文字、数字、およびアンダースコアのみを含めることができます。
名前の先頭を数字にすることはできません。

指定可能な親プロパティ — step

例 — output-variables オプションを使用してエクスポート可能な変数を定義する

step:
  script:
  	- echo "VARIABLE_NAME=my-value" >> $BITBUCKET_PIPELINES_VARIABLES_PATH
  output-variables:
    - VARIABLE_NAME

同時実行グループ

concurrency-group をステップに追加すると、Bitbucket Pipelines 内の同時実行ステップのグループを定義できます。concurrency-group を指定すると、同じグループに属するステップの実行を制御して、そのグループ内のステップを一度に 1 つだけ実行することができます。これにより、リソースの使用状況を管理し、パイプライン実行での競合を回避できます。

ステップは、ステップの実行が開始された順序に基づいて、先入れ先出し (FIFO) 戦略を使用して待機します。

プロパティ — concurrency-group

必須 — いいえ

データタイプ — 文字列

指定可能な値 — 同時実行グループの名前

指定可能な親プロパティ — step

設定例

pipelines:
  default:
    - step:
        name: Build
        concurrency-group: build-group
        script:
          - echo "Building the application"

キャッシュとアーティファクト

キャッシュ

ステップの caches オプションは、依存関係が外部ソース (npm や PyPI のようなパッケージリポジトリなど) からダウンロードされるステップを示すために使用されます。これによって、外部ビルド依存関係を再度ダウンロードすることなく、以前に定義したキャッシュを作成、アップデート、または再利用できます。定義済みのカスタムキャッシュも使用できれば、定義済みのキャッシュのいずれかも使用できます。定義済みのキャッシュの完全なリストについては「キャッシュ — 定義済みのキャッシュ」をご確認ください。

caches オプションの使用に関する情報は、「キャッシュ」をご参照ください。

プロパティ — 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 パターンを使用して定義できます。

アーティファクトの詳細については「アーティファクトをステップで使用する」をご確認ください。

プロパティ — 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 では使用できなくなります。

アーティファクトの使用方法に関する詳細については「アーティファクトをステップで使用する」をご確認ください。

プロパティ — download

必須 — いいえ

データタイプ — ブール値

指定可能な値 — true または false

既定値 — 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 パターンを使用して定義できます。

アーティファクトの詳細については「アーティファクトをステップで使用する」をご確認ください。

プロパティ — 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 統合」をご確認ください。

プロパティ — 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 統合」をご確認ください。

シークレットとログイン認証情報は、漏洩を防ぐためにユーザー定義のパイプライン変数として保存する必要があります。詳細は「変数とシークレット — ユーザー定義の変数」をご参照ください。

プロパティ — 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 つのランナーが再び使用可能になるまでステップは待機します。リポジトリ内にすべてのラベルに一致するオンラインランナーがない場合、ステップは失敗します。

例 — 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 のみです。

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

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

includePaths および excludePaths に指定されたファイル一致パターンは、$BITBUCKET_CLONE_DIR ディレクトリに対して相対的です。

考慮される変更内容

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

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

プロパティ — condition

必須 — いいえ

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

指定可能な親プロパティ — step と stage

指定可能な子プロパティ — 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 つ以上のファイルでの変更であることを示すために使用されます。

プロパティ — changesets

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

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

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

指定可能な子プロパティ — includePaths または excludePaths (必須)

例 — 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 が実行され、それ以外の場合はステップがスキップされます。

プロパティ — 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

条件付きチェンジセットの除外ディレクトリ

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

プロパティ — excludePaths

必須 — いいえ

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

指定可能な親プロパティ — 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

トリガー

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

最初の step または stage にはできません。
設定されている順序でのみ実行できます。手動の step または stage はスキップできません。
前の step または stage が正常に完了した場合のみ実行できます。
リポジトリへの書き込みアクセス権限を持つユーザーのみがトリガーできます。
Pipelines の Web インターフェイス経由でトリガーされます。

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

プロパティ — trigger

必須 — いいえ

データタイプ — 文字列

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

既定値 — automatic

指定可能な親プロパティ — step と 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

サービス — サービスコンテナーと OIDC リソース

OpenID Connect (OIDC) リソース

oidc オプションは、パイプラインステップをリソースサーバーに接続するための OpenID Connect の使用を有効にします。oidc の値を、true に設定する必要があります。その後、OpenID Connect を設定します。パイプラインでの OIDC の使用方法に関する詳細については「OIDC を使用して Pipelines とリソースサーバーを統合する」をご確認ください。

プロパティ — oidc

必須 — いいえ

データタイプ — ブール値

指定可能な値 — true または false

既定値 — 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 は、サービスごとに個別の Docker コンテナーを作成できます。これによってビルドが高速化されて、サービスの編集が容易になります。サービスの作成方法について詳しくは、「データベースとサービスコンテナー」をご確認ください。この services オプションは、以前に定義されたサービスがどのステップに必要なのかを示すために使用します。

プロパティ — 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"

デプロイメント

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

詳細情報

デプロイステージについては「デプロイステージ」をご確認ください。
デプロイ環境の作成と設定については「デプロイのセットアップと監視」をご確認ください。

プロパティ — deployment

必須 — いいえ

データタイプ — 文字列

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

指定可能な親プロパティ — step と 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

必須 — いいえ

データタイプ — 文字列

指定可能な値 — 環境の名前

指定可能な親プロパティ — step と 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

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

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

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

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

コミュニティに質問

ステップ オプション

パイプラインのステップ オプション

ステップのプロパティ

例 — 単一ステップを使用したパイプライン

例 — 連続および並行ステップを使用したパイプライン

type プロパティ

script プロパティ

スクリプト

例 — script プロパティを使用して、基本的なコマンドを実行する

例 — script プロパティと個別のファイルを併用して、大規模なスクリプトを実行する

例 — script プロパティを使用して、単一のステップに対して一連のコマンドを実行する

例 — script と pipe プロパティを併用して、パイプを実行する

一般的なオプション

max-time

例 — max-time オプションを使用して、パイプラインの各ステップに指定可能な最大時間を設定する

例 — max-time オプションを使用して、パイプラインの個別のステップに指定可能な最大時間を設定する

サイズ

サイズに基づくリソース割り当て

例 — size オプションを使用して、すべてのパイプライン ステップで利用可能なメモリを増やす

例 — size オプションを使用して、パイプライン ステップで利用可能なメモリを増やす

ランタイム

例 - ランタイムを使用して、4x、8x、および 16x のすべてのステップで atlassian-ip-ranges を、すべてのステップで arm を有効にする

例 - ランタイムを使用して、特定のステップで atlassian-ip-ranges と arm を有効にする

クラウド ランタイム設定

クラウド ランタイム設定用のアトラシアン IP 範囲

クラウド ランタイム設定のアーキテクチャ

after-script

例 — after-script オプションを使用して、script コマンドの後にコマンドを実行する

名前

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

フェイル ファスト

例 — fail-fast を使用して、いずれかのステップが失敗した時点で並行ステップを停止する

例 — fail-fast から並行ステップを除外する

on-fail

例 — on-fail を使用してステップの失敗を無視する

例 — on-fail を使用して並行ステップ内のステップの失敗を無視する

例 — on-fail を使用して並行グループ内のすべての失敗を再試行する

例 — on-fail を使用してステージ内のすべての失敗を再試行する

出力変数

例 — output-variables オプションを使用してエクスポート可能な変数を定義する

同時実行グループ

設定例

キャッシュとアーティファクト

キャッシュ

例 — caches オプションを使用して、Ruby プロジェクトの依存関係をキャッシュする

アーティファクト

例 — artifacts を使用して、構築済みコードを次のステップに渡してテストする

例 — artifacts、download、paths を使用して、後のステップにアーティファクトを渡す

アーティファクトのダウンロード

例 — download オプションを使用して、ステップでアーティファクトがダウンロードされないようにする

例 — アーティファクトの download および paths オプションを併用する

アーティファクトのパス

例 — アーティファクトの paths オプションを使用して、後のステップで使用するファイルを保持する

パイプ

pipe

例 — pipe オプションとともに、公式の Opsgenie パイプを使用して Opsgenie アラートを送信する

例 — pipe を使用して、Opsgenie と Slack にメッセージを送信する

例 — pipe オプションを使用して、カスタム パイプを実行する

パイプ変数

例 — variables を使用して、2 つのパイプを設定して実行する

ランナー

runs-on

例 — runs-on オプションを使用して、自社ホストランナーでステップを実行する

docker images

Git clone オプション

フロー制御

条件

考慮される変更内容

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

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

条件チェンジセット

条件チェンジセット

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

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

条件付きチェンジセットを含むディレクトリ

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

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

条件付きチェンジセットの除外ディレクトリ

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

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

ステップオプション

パイプラインのステップオプション

`type` プロパティ

`script` プロパティ

例 — size オプションを使用して、すべてのパイプラインステップで利用可能なメモリを増やす

例 — size オプションを使用して、パイプラインステップで利用可能なメモリを増やす

例 - ランタイムを使用して、4x、8x、および 16x のすべてのステップで `atlassian-ip-ranges` を、すべてのステップで `arm` を有効にする

例 - ランタイムを使用して、特定のステップで `atlassian-ip-ranges` と `arm` を有効にする

クラウドランタイム設定

クラウドランタイム設定用のアトラシアン IP 範囲

クラウドランタイム設定のアーキテクチャ

フェイルファスト

例 — pipe オプションを使用して、カスタムパイプを実行する

サービス — サービスコンテナーと OIDC リソース

例 — oidc オプションを使用して、パイプラインステップをリソースサーバーに接続する

例 — ステップの services オプションを使用して、どのステップが my-service-name データベースサービスを必要としているかを示す