ステップオプション

これらのオプションは、コンパイラーやテストの実行など、コマンドとスクリプトを実行するために使用される必須の script プロパティを含め、パイプラインのステップを定義するために使用されます。

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

ステップは、次のオプションを受け入れます。

ステップのプロパティ

step オプションは、ビルドの実行単位を定義するために使用されます。ステップは、bitbucket-pipelines.yml ファイルに表示される順序で実行されます。1 つのパイプラインに、最大 100 のステップを含められます。

パイプラインの各ステップは個別の Docker コンテナーを起動し、script オプションで構成されたコマンドを実行します。各ステップは、次のようなオプションを使用してカスタマイズできます。

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、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

必須の script プロパティ

スクリプト

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

プロパティ — script

必須 — はい

データタイプ — 文字列や 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"

一般的なオプション

サイズ

size オプションは、ステップまたはパイプライン全体に追加のメモリを割り当てます。2x のサイズを指定すると、利用可能なメモリが 2 倍になります。1x (初期設定) ステップには 4 GB のメモリが割り当てられ、2x ステップには 8 GB のメモリが割り当てられます。割り当てられたメモリは、step の script と、step のすべての services の両方で共有されます。

このオプションは、Bitbucket Cloud インフラストラクチャと Linux Docker 自社ホストランナーで実行されるステップで利用できます。Windows PowerShell、macOS シェル、Linux シェルランナーなどのシェルベースのランナーは、ホストマシンで利用可能なすべてのメモリを使用します。

2x ステップは、1x ステップのビルド時間の 2 倍を使用します。

プロパティ — size

必須 — いいえ

データタイプ — 文字列

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

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

既定値 — 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!"

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

プロパティ — name

必須 — いいえ

データタイプ — 文字列

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

例 — name を使用して、ステージ、パイプ、および 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
            name: Send a message to Slack
            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:
        # these option alows to force stop 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:
        # these option alows to force stop 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

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

キャッシュ

ステップの 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 パターンを使用して定義できます。アーティファクトのパスは 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 (大半のパイプで必須) および name (オプション)

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

例 — 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 のみです。変更したファイルのいずれかが includePaths の表現と一致する場合のみ、changesets を使用して、step または stage を実行できます。includePaths に指定されたファイル一致パターンは、$BITBUCKET_CLONE_DIR ディレクトリに対して相対的です。

考慮される変更内容

pull-requests パイプラインでは、すべてのコミットが考慮され、パターンの includePath リストが提供されている場合は、少なくとも 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 つ以上のファイル (includePaths) での変更であることを示すために使用されます。

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

プロパティ — 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 日間保存されます。この期間が過ぎると、アーティファクトは期限切れとなり、パイプラインでは以降のあらゆる手動ステップと手動ステージを実行できなくなります。

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

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

正確ではなかった

明確ではなかった

関係なかった

ステップ オプション

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

ステップのプロパティ

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

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

必須の script プロパティ

スクリプト

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

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

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

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

一般的なオプション

サイズ

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

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

after-script

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

名前

例 — name を使用して、ステージ、パイプ、および 2 つのステップにラベルを付ける

フェイル ファスト

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

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

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

キャッシュ

例 — 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 オプションを使用して、特定のファイルの変更時のみにステージを実行する

トリガー

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

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

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

OpenID Connect (OIDC) リソース

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

サービス

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

デプロイメント

デプロイメント

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

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

その他のヘルプ

ステップオプション

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

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

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

フェイルファスト

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

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

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

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