bitbucket-pipelines.yml を設定する

bitbucket-pipelines.yml ファイルは、Pipelines のビルド構成を定義します。Pipelines に馴染みが薄い場合、こちらで詳細をご確認ください。 


基本構成

基本構成では、プロジェクトをビルドおよびデプロイするためのスクリプトを作成したり、キャッシュを構成してビルドを高速化するなどの設定を行うことができます。また、ステップごとに異なるイメージを指定して、パイプラインで実行しているアクション間で異なる依存関係を管理することもできます。

パイプラインはステップの一覧として構成され、構成ファイル内で複数のパイプラインを定義できます。次のグラフでは、default セクションで設定されたパイプラインを確認できます。パイプライン構成ファイルには、特定のキーワードで識別される複数のセクションを含めることができます。

はじめる前に

  • ファイルには少なくとも、1 つ以上のステップを含む 1 つのパイプライン セクションと、ステップ内に 1 つのスクリプトを含める必要があります。
  • 各ステップでは 4 GB のメモリを使用可能です。
  • 1 つのパイプラインに、最大 100 のステップを含めることができます。
  • パイプラインの各ステップは、別の Docker コンテナを実行します。必要に応じて別のイメージを選択することで、各ステップで別のタイプのコンテナを使用できます。

手順 

1. yaml ファイルを構成するには、Bitbucket でリポジトリ > [Pipelines] に移動し、 をクリックします。Bitbucket のインターフェイスを使用せずに yaml ファイルを構成することもできます。

2. 言語を選択します。

注意: Pipelines は、任意の言語で記述されたプロジェクトのビルドまたはデプロイ用に構成できます。言語ガイド

3. イメージを選択します。

注意: Pipelines を初めて利用したときに製品から直接編集するか、 をクリックしてパイプライン内からいつでも、またはリポジトリから編集できます。

ファイルには少なくとも、1 つ以上のステップを含む 1 つ以上のパイプライン セクションと、ステップ内に 1 つのスクリプトを含める必要があります。

セクション                                                                 説明


default - 他のセクションのパイプライン定義に一致しないすべてのブランチのパイプライン定義が含まれます。

default パイプラインは、ブランチ固有のパイプラインが定義されている場合を除き、リポジトリへのプッシュのたびに実行されます。ブランチ パイプラインは branch セクションで定義できます。

: default パイプラインはタグまたはブックマークでは実行されません。



branches - すべてのブランチ固有のビルド パイプラインのセクションを定義します。このセクションの名前または表現は、次の情報と照合されます。

  • Git リポジトリのブランチ
  • Mercurial リポジトリの名前付きブランチ

リポジトリで特定のブランチをビルドするためのパイプライン構成の詳細については、「ブランチ ワークフロー」を参照してください。

(grey lightbulb) glob パターンのチート シートを利用してブランチ名を定義できます。



tags - すべてのタグ固有のビルド パイプラインを定義します。このセクションの名前または表現は、Git リポジトリのタグや注釈付きタグと照合されます。

(grey lightbulb) glob パターンを確認してタグを定義します。

bookmarks - すべてのブックマーク固有のビルド パイプラインを定義します。このセクションの名前または表現は、Mercurial リポジトリのブックマーク名に照合されます。

image: node:10.15.0
   
pipelines:
  default:
    - step:
        name: Build and test
        script:
          - npm install
          - npm test
  bookmarks:                      # add the 'bookmarks' section
    release-*:                    # specify the bookmark
      - step:                     # define the build pipeline for the bookmark
          name: Build and release
          script:
            - npm install
            - npm test
            - npm run release
  branches:
    staging:
      - step:
          name: Clone
          script:
            - echo "Clone all the things!"

(grey lightbulb) glob パターンのチート シートを確認してブックマークを定義できます。


pull-requestsリポジトリから開始されたプル リクエストでのみ実行される特別なパイプラインです。実行前に宛先ブランチを作業ブランチにマージします。フォークされたリポジトリからのプル リクエストは、パイプラインをトリガーしません。マージが失敗すると、パイプラインが停止します。

重要

プル リクエスト パイプラインは定義されている任意の branch および default パイプラインに加えて実行されるため、定義が重複すると 2 つのパイプラインが同時に実行される場合があります。

構成にすでにブランチがあり、すべてのブランチをプル リクエストでのみ実行したい場合、キーワード branchespull-requests. に置き換えます。

pipelines:
  pull-requests:
    '**': #this runs as default for any branch not elsewhere defined
      - step:
          script:
            - ...
    feature/*: #any branch with a feature prefix
      - step:
          script:
            - ...
branches:    #these will run on every push of the branch
    staging:
      - step:
          script:
            - ...

(grey lightbulb) glob パターンのチート シートを確認してブックマークを定義できます。

customBitbucket Cloud インターフェイスから手動またはスケジュール実行でのみトリガーできるパイプラインを定義します。

image: node:10.15.0
    
pipelines:
  custom: # Pipelines that are triggered manually
    sonar: # The name that is displayed in the list in the Bitbucket Cloud GUI
      - step:
          script:
            - echo "Manual triggers for Sonar are awesome!"
    deployment-to-prod: # Another display name
      - step:
          script:
            - echo "Manual triggers for deployments are awesome!"
  branches:  # Pipelines that run automatically on a commit to a branch
    staging:
      - step:
          script:
            - echo "Auto pipelines are cool too."

上記のような構成の場合、Bitbucket Cloud の [パイプラインの実行] ダイアログに次のパイプラインが表示されます。

詳細は、「パイプラインを手動で実行する」を参照してください。


例:

image: node:10.15.0
   
pipelines:
  default:
    - step:
        name: Build and test
        script:
          - npm install
          - npm test
  tags:                         # add the 'tags' section
    release-*:                  # specify the tag
      - step:                   # define the build pipeline for the tag
          name: Build and release
          script:
            - npm install
            - npm test
            - npm run release
  branches:
    staging:
      - step:
          name: Clone
          script:
            - echo "Clone all the things!"


高度な設定

サービスを実行し、テストを並行して実行するには、詳細オプションを使用します。手動ステップの構成や各ステップの最大時間の設定、2x ステップを構成した 8 GB メモリの使用なども行えます。

はじめる前に

  • パイプラインの YAML ファイルには、キーワードと 1 つ以上のステップを含むセクションが少なくとも 1 つ必要です。
  • 各ステップでは 4 GB のメモリを使用可能です。
  • 1 つのパイプラインに、最大 100 のステップを含めることができます。
  • パイプラインの各ステップは、別の Docker コンテナを実行します。必要に応じて別のイメージを選択することで、各ステップで別のタイプのコンテナを使用できます。

グローバル構成オプション

キーワードの一覧

キーワード                                                                説明


variables(カスタム パイプラインのみ) パイプラインの起動時に提供される変数が含まれます。変数を有効にするには、パイプラインを実行するときに入力するカスタム パイプラインの下に変数を定義します。

pipelines:
  custom:
    custom-name-and-region: #name of this pipeline
      - variables:          #list variable names under here
          - name: Username
          - name: Region
      - step: 
          script:
            - echo "User name is $Username"
            - echo "and they are in $Region"

[ブランチ] > [...] > [ブランチのパイプラインを実行] > [カスタム] でカスタム パイプラインを実行すると、それらを渡すことができます。

キーワード variables は、サービスの定義の一部にすることもできます。


nameキーワード名が yaml の variables セクションにある場合、このキーワードはカスタム パイプラインを実行するときに追加または更新できる変数を定義します。Pipelines は、ステップ内でキーワード name を使用できます。

parallel -  並行ステップを使用すると、一連のステップを同時に実行して、ビルドやテストを迅速に行えます。ステップを平行にした場合も、パイプラインが使用する合計のビルド時間数は変わりません。ただし、結果はより早く表示されます。

並列または単独のどちらで実行されているかにかかわらず、パイプラインで実行できるステップの合計数は 100 に制限されています。

同時に実行するステップをインデントで定義します。

pipelines:
  default:
    - step: # non-parallel step
        name: Build
        script:
          - ./build.sh
    - parallel: # these 2 steps will run in parallel
        - step:
            name: Integration 1
            script:
              - ./integration-tests.sh --batch 1
        - step:
            name: Integration 2
            script:
              - ./integration-tests.sh --batch 2
    - step:          # non-parallel step
        script:
          - ./deploy.sh

並行ステップについての詳細情報

step - ビルドの実行単位を定義します。ステップは bitbucket-pipelines.yml ファイルで読み込まれる順序で実行されます。パイプラインでは最大 100 ステップを使用できます。

パイプラインの各ステップは個別の Docker コンテナを起動し、script で構成されたコマンドを実行します。各ステップは次のように構成できます。

  • 別の Docker イメージを使用する。
  • カスタムの max-time を構成する。
  • 固有のキャッシュとサービスを使用する。
  • 後のステップで使用できるアーティファクトを生成する。

ステップは、実行前に手動トリガーを待機するように構成できます。ステップを手動として定義するには、bitbucket-pipelines.yml ファイルのステップに trigger: manual を追加します。手動ステップには次のような特徴があります。

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

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

: パイプラインの最初ステップを手動ステップに設定することはできません。

name - ステップで実行される内容をわかりやすく表示するため、ステップの名前を定義します。


image - Bitbucket Pipelines では、Docker コンテナを使用してビルドを実行します。

  • Bitbucket が提供する デフォルト イメージ (atlassian/default-image:2) を使用するか、カスタム イメージを定義できます。プライベート ネットワークでホストされていない、任意の公開または非公開の Docker イメージを指定できます。
  • イメージは、グローバルまたはステップ レベルで定義できます。ブランチ レベルでは定義できません。

イメージを指定するには、次のイメージを使用します: <your_account/repository_details>:<tag>

イメージの使用および作成の詳細については、「Docker イメージをビルド環境として使用する」を参照してください。

pipelines:
  default:
    - step:          # non-parallel step
        name: Build
        script:
          - ./build.sh
    - parallel:      # these 2 steps will run in parallel
        - 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


triggerSpecifies whether a step will run automatically or only after someone manually triggers it. You can define the trigger type as manual or automatic. If the trigger type is not defined, the step defaults to running automatically. The first step cannot be manual. If you want to have a whole pipeline only run from a manual trigger then use a custom pipeline.

pipelines:
  default:
    - step:
        name: Build and test
        image: node:10.15.0
        script:
          - npm install
          - npm test
          - npm run build
        artifacts:
          - dist/**
    - step:
        name: Deploy
        image: python:3.7.2
        trigger: manual
        script:
          - python deploy.py


deployment -  
Sets the type of environment for your deployment step, and it is used in the Deployments dashboard. The Valid values are: test, staging, or production.

次のステップが Deployments ビューの test 環境に表示されます。

有効な値: teststaging、または production

- step:
    name: Deploy to test
    image: aws-cli:1.0
    deployment: test
    script:
      - python deploy.py test

size - You can allocate additional resources to a step, or to the whole pipeline. By specifying the size of 2x, you'll have double the resources available (eg. 4GB memory → 8GB memory).

現時点では、有効なサイズは 1x および 2x です。

2x パイプラインは、倍のビルド時間数 (分) を使用します。

例: 1 つのステップのサイズをオーバーライドする
pipelines:
  default:
    - step:
        script:
          - echo "All good things..."
    - step:
        size: 2x # Double resources available for this step.
        script:
          - echo "Come to those who wait."

script連続して実行されるコマンドの一覧が含まれています。スクリプトは、ステップに記載された順序で実行されます。大規模なスクリプトは個別のスクリプト ファイルに移動し、それらを bitbucket-pipelines.yml から呼び出すことをおすすめします。

pipePipes make complex tasks easier, by doing a lot of the work behind the scenes. This means you can just select which pipe you want to use, and supply the necessary variables. You can look at the repository for the pipe to see what commands it is running. Learn more about pipes.

Opsgenie にメッセージを送信するパイプは次のようになります。

pipelines:
  default:
    - step:
        name: Alert Opsgenie
        script:
          - pipe: atlassian/opsgenie-send-alert:0.2.0
            variables:
              GENIE_KEY: $GENIE_KEY
              MESSAGE: "Danger, Will Robinson!"
              DESCRIPTION: "An Opsgenie alert sent from Bitbucket Pipelines"
              SOURCE: "Bitbucket Pipelines"
              PRIORITY: "P1"

独自のパイプを作成することもできます。その場合、次の構文を使用して Docker ベースのパイプを指定できます。

 pipe: docker://<DockerAccountName>/<ImageName>:<version>

after-scriptafter-script セクション内のコマンドは、ステップが成功または失敗した時に実行されます。これは、特に after-script が BITBUCKET_EXIT_CODE の値を使用している場合、クリーンアップ コマンド、テスト カバレッジ、通知、またはロールバックの実行に便利です。

: after-script セクションのコマンドが失敗した場合、次のようになります。

  • そのセクションでは以降のコマンドは実行されません。
  • ステップに対して報告されているステータスには影響しません。
pipelines:
  default:
    - step:
        name: Build and test
        script:
          - npm install
          - npm test
        after-script:
          - echo "after script has run!"

artifactsDefines files that are produced by a step, such as reports and JAR files, that you want to share with a following step.

アーティファクトは glob パターンを使用して定義できます。

pipelines:
  default:
    - step:
        name: Build and test
        image: node:10.15.0
        script:
          - npm install
          - npm test
          - npm run build
        artifacts:
          - dist/**
    - step:
        name: Deploy to production
        image: python:3.7.2
        script:
          - python deploy-to-production.py

詳細については、「アーティファクトをステップで使用する」を参照してください。

optionsすべてのパイプラインに適用するグローバル設定を含みます。ここで使用する主なキーワードは max-time です。

max-timeステップを実行できる最大時間 (分単位) をグローバル レベルまたはステップ レベルで定義できます。0 〜 120 の整数を使用します。

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

max-time を指定しない場合、既定で 120 に設定されます。

clone - リポジトリのクローンをコンテナに作成した時の設定を含みます。ここでの設定には以下が含まれます。

  • lfs - Git lfs のサポート
  • depth - Git クローンの深度

lfs (GIT only)Enables the download of LFS files in your clone. Ifs defaults to false if not specified. Note that keyword is supported only for Git repositories.

clone:
  lfs: true
   
pipelines:
  default:
    - step:
        name: Clone and download
        script:
          - echo "Clone and download my LFS files!"

depth (Git のみ)すべてのパイプラインの Git クローンの深度を定義します。このキーワードは Git リポジトリでのみサポートされます。

深度を指定する際は、0 より大きい整数を使用します。フル クローンには full を使用します。Git クローンの深度を指定しない場合、既定で 50 に設定されます。

clone:
  depth: 5       # include the last five commits
  
pipelines:
  default:
    - step:
        name: Cloning
        script:
          - echo "Clone all the things!"

definitionsパイプライン構成の別の場所で使用されているリソースを定義します。リソースには以下を含めることができます。

servicesPipelines は、サービス用に別々の docker コンテナをスピンアップできます。これによりビルドが高速化され、サービスを容易に編集できるようになります。

完全に構成されたサービスの例

MySQL のサービス コンテナ (既定のデータベース pipelines、ユーザー root、パスワード let_me_in を持つ、localhost:3306 で利用可能な空のデータベース) が必要な場合、次のように追加できます。

definitions:
  services:
    mysql:
      image: mysql
      variables:
        MYSQL_DATABASE: pipelines
        MYSQL_ROOT_PASSWORD: let_me_in
pipelines:
  default:
   - step:
      services:
        - docker
        - mysql
      script:
        - ...
definitions:
  services:
    mysql: mysql:latest

サービスの使用方法の詳細についてはこちらをご覧ください。

cachesビルドの各ステップでインターネットから依存関係を再度ダウンロードすると、長い時間がかかる場合があります。キャッシュを使用すると、これらの依存関係はサーバーへ 1 回ダウンロードされ、ビルドのたびにローカルに読み込まれます。

definitions:
  caches:
    bundler: vendor/bundle
pipelines:
  default:
   - step:
      caches:
        - npm
      script:
        - npm install


YAML anchorsYAMLアンカー - yaml のチャンクを定義して使いやすくする方法。「YAML アンカー」を参照してください。







最終更新日 2020 年 1 月 12 日

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

はい
いいえ
この記事についてのフィードバックを送信する
Powered by Confluence and Scroll Viewport.