ステップオプション

これらのオプションは、コンパイラーやテストの実行など、コマンドとスクリプトを実行するために使用される必須の 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 に設定するため。
config – to inherit a reusable set of step options from a step config definition.

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

`final` プロパティ

The final property allows you to define a final step in the YAML definition. A final step can be defined in pipeline builds that run at the end regardless of the results of other steps. The final step will still run even if one or all of the steps failed, paused, skipped, or passed in a build. The final step will run again with every new pipeline execution, including re-runs, resumes or redeploy operations.

Use the final step property for tasks that should always run at the end of a pipeline, such as cleanup, log collection, sending notifications or analytics.

Each final step can be customized using the following options:

runtime – ステップのランタイム環境をカスタマイズします。
- cloud
- atlassian-ip-ranges
image — 別の Docker イメージを使用するため。
max-time — ステップの許容最大時間を設定するため。
caches と services — 特定のキャッシュとサービス用。
artifacts — 後続のステップが使用できるアーティファクトを保持します。
clone — ステップの Git クローン操作をカスタマイズするため。

プロパティ — final

必須 — いいえ

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

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

Allowed child properties — Requires the script property. The following properties are optional: after-script, artifacts, caches, clone, config, image, name, oidc, runs-on, runtime, condition, services and size.

制限事項

The following options are available in any other steps but are not supported by the final step:

Only one final step can be defined and it must be the last step
You can define just one final section in your pipeline, and it must always be the last step.
There is a minimum step requirement
There must be at least one non-final step in the pipeline.
No grouping or parallelization available
The final step cannot be included in any group (stage) or run in parallel with other steps.
No child pipeline triggering from a final step
The final step cannot use type: pipeline to trigger a child pipeline, but it can be used inside a child pipeline.
No manual, deployment, or fail-fast options available
The final step does not support the manual trigger, deployment property, or fail-fast option.

Example - using final step

pipelines:
  default:
      - step:
          name: Build
          script:
            - ./build.sh
      - step:
          name: Test
          script:
            - ./build.sh
      - final:
          name: Sending Analytics
          script:
            - ./analytics.sh

Example – using final step with custom and parallel definitions

pipelines:
  custom:
    test-final-step-in-parallel:
      - step:
          name: Build
          script:
            - ./build.sh
      - parallel:
          steps:
            - step:
                name: Integration 1
                script:
                  - ./integration-tests.sh --batch 1
            - step:
                name: Integration 2
                script:
                  - ./integration-tests.sh --batch 2
      - step:
          script:
            - ./build.sh
      - final:
          name: Final step
          script:
           - ./analytics.sh

Example – using final step with on-fail strategy

pipelines:
  custom:
    test-final-step-with-on-fail-defined:
      - step:
          name: Build & Test
          script:
            - ./build.sh
      - step:
          name: Deployment
          script:
            - ./build.sh
      - final:
          name: Send Analytics
          on-fail: #on-fail strategy can be overriden
            strategy: retry
            maxRetryCount: 3
          script:
            - ./analytics.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"

一般的なオプション

Config

The config option makes a step inherit a named set of step options defined under definitions.step-config. Any option set on the step overrides the one it inherits. Merging happens at the top level only, so a list or block on the step replaces the inherited one rather than adding to it. For the full merge rules and examples, see Step config.

default is a reserved name. A step can set config: default even when no default step config is defined. Any other name must exist under definitions.step-config.

Property — config
Required — No
Data type — String
Allowed values — The name of a step config defined under definitions.step-config, or default
Allowed parent properties — step
Allowed child properties — None

Example — using the config option to reuse step options across steps

definitions:
  step-config:
    node:
      image: node:22
      size: 2x
pipelines:
  default:
    - step:
        config: node
        name: Build
        script:
          - npm ci
          - npm run build
    - step:
        config: node
        name: Test
        script:
          - npm test

制限事項

The config option is available on steps, including steps inside parallel and stage. It is not available on child pipeline steps (type: pipeline).
A step config cannot reference another step config.

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 ギガバイト
24 倍	48	96	256 ギガバイト
32x	64	128	256 ギガバイト

プロパティ — size

必須 — いいえ

データタイプ — 文字列

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

1x, 2x, 4x, 8x, 16x, 24x or 32x for pipeline steps run on Bitbucket Cloud.

4x, 8x, 16x, 24x, and 32x pipelines size options are only available for builds running on a paid Bitbucket Cloud plan (Standard or 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

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

プロパティ — 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 仕様 - ブロックマッピング)

Allowed parent properties — step, parallel, and 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"

Auth

The auth option sets the permissions (scopes) of the short-lived OAuth token that Bitbucket Pipelines creates for a step.

Each step gets an OAuth token that is:

limited to the repository that the pipeline runs on
limited to the scopes listed in the step
valid only while the step runs.

Note: It expires when the step finishes.

The token is available in the build as the BITBUCKET_OAUTH_TOKEN variable. Use it to call the Bitbucket Cloud REST API from your scripts, instead of storing long-lived credentials in repository variables. For agentic steps, the same scopes also control what the agent can do through the Bitbucket MCP server. For details, see Authentication and security for Agentic Pipelines.

List only the scopes the step needs. Add write scopes only to the steps that need them.

If you use self-hosted runners, upgrade them to version 6.1.0 or later. Earlier versions do not support the auth option.

Property — auth

必須 — いいえ
Data type — Block of new-line separated key-value pairs (YAML spec - Block Mapping)
Allowed parent properties — step, and step configs under definitions.step-config
Allowed child properties — system (required)

Property — system

Required — Yes, when auth is used
Data type — Block of new-line separated key-value pairs (YAML spec - Block Mapping)
指定可能な親プロパティ — auth
Allowed child properties — scopes (required)

Property — scopes

Required — Yes, when system is used
Data type — A list of strings
Allowed values — Any of the scopes below
指定可能な親プロパティ — system

Supported Scopes

These scopes follow Bitbucket’s API token scope rules

リソース	範囲	Allows
課題	`read:issue:bitbucket` `write:issue:bitbucket`	Read issues Create and update issues
パイプライン	`read:pipeline:bitbucket` `write:pipeline:bitbucket`	Read pipelines and steps Run and stop pipelines, and manage schedules and caches
Pull Request	`read:pullrequest:bitbucket` `write:pullrequest:bitbucket`	Read pull requests, comments, and tasks Create and update pull requests, comments, and tasks
Repository (git operations)	`read:git:bitbucket` `write:git:bitbucket`	Clone and fetch over Git Push over Git
Repository (Includes API access)	`read:repository:bitbucket` `write:repository:bitbucket`	Read repository content through the API, such as files, commits, and branches. Also add build statuses to commits Change the repository through the API, such as creating branches and tags, or approving commits
Runner	`read:runner:bitbucket`	Read repository and workspace runners
テスト	`read:test:bitbucket` `write:test:bitbucket`	Read tests and test results Update tests
Agent Session	`read:agent-session:bitbucket`	Read Agent Sessions

If the step lists a scope that is not in this table, the pipeline will fail with the following error: The system scopes provided contains unsupported scopes.

For detailed information on the APIs each scope allows, see the Bitbucket Cloud REST API reference.

Example — using the auth option to comment on a pull request

pipelines:
  pull-requests:
    '**':
      - step:
          name: Comment on pull request
          auth:
            system:
              scopes:
                - read:pullrequest:bitbucket
                - write:pullrequest:bitbucket
          script:
            - >
              curl -X POST
              -H "Authorization: Bearer $BITBUCKET_OAUTH_TOKEN"
              -H "Content-Type: application/json"
              "https://api.bitbucket.org/2.0/repositories/$BITBUCKET_WORKSPACE/$BITBUCKET_REPO_SLUG/pullrequests/$BITBUCKET_PR_ID/comments"
              -d '{"content": {"raw": "Build passed."}}'

Example — using the auth option to push a commit

pipelines:
  branches:
    main:
      - step:
          name: Bump version
          auth:
            system:
              scopes:
                - read:git:bitbucket
                - write:git:bitbucket
          script:
            - git commit -am "Bump version [skip ci]"
            - git push

既定のスコープ

When clone is enabled, the step always gets read:git:bitbucket so it can clone the repository. The scopes you list are added to it.

Step setup	Scopes the step gets
Clone enabled, no scopes listed	`read:git:bitbucket`
Clone disabled, no scopes listed	なし
Clone enabled, scopes listed	`read:git:bitbucket` and your scopes
Clone disabled, scopes listed	Your scopes

Until 2027-04-30, steps without an auth block get read:repository:bitbucket, write:repository:bitbucket, read:pipeline:bitbucket and write:pipeline:bitbucket. Steps with an auth block get only the scopes they list, plus read:git:bitbucket when clone is enabled

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

キャッシュ

ステップの 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 が実行されないようにします。Bitbucket Pipelines は changesets と state の 2 つの条件タイプをサポートしています。両方が指定されている場合、ステップまたはステージを実行するには両方の条件を満たす必要があります。changesets が最初に評価され、次に state が評価されます。

条件 `changesets`

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

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

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

考慮される変更内容

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

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

条件 `state`

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

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

自動トリガーステップの場合: ステップの開始準備が完了したとき、つまり前のステップが終了したときに条件が評価されます。
手動トリガーステップの場合:
- 唯一の条件が changesets の場合、ステップを開始する準備ができたときに評価されます。
- 条件に state 条件が含まれる場合、ユーザーが Run ボタンまたは Deploy ボタンを選択したときに評価されます。

特別なケース:

再試行戦略を使用したステップ: ステップが再試行されるたびに条件が再評価されます。
ステップは開始されましたが停止しました: ステップが停止から再開されたときに再評価は行われません。

プロパティ — condition

必須 — いいえ

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

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

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

例 — 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 オプションは、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

条件のステート

条件 `state`

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

プロパティ — state

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

データタイプ — 文字列

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

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

例

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

式言語 — 仕様

コンテキスト変数

サポートされているソース: 環境、ワークスペース、リポジトリ、パイプライン変数
保護された変数とボールト変数はサポートされていません。
リテラルと比較する場合の変数の動的タイプ推論:
- 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

トリガー

ステージを自動的に実行する (既定の動作) か、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 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.

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

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

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

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

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

コミュニティに質問

ステップ オプション

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

ステップのプロパティ

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

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

final プロパティ

Example - using final step

type プロパティ

script プロパティ

スクリプト

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

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

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

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

一般的なオプション

Config

Example — using the config option to reuse step options across steps

制限事項

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 オプションを使用してエクスポート可能な変数を定義する

同時実行グループ

設定例

Auth

Property — auth

Property — system

Property — scopes

Supported Scopes

Example — using the auth option to comment on a pull request

Example — using the auth option to push a commit

既定のスコープ

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

キャッシュ

例 — 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 オプション

フロー制御

条件

ステップオプション

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

`final` プロパティ

`type` プロパティ

`script` プロパティ

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

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

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

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

クラウドランタイム設定

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

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

フェイルファスト

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

条件 `changesets`

条件 `state`

条件 `state`

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

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

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