bitbucket-pipelines.yml を設定する

At the center of Pipelines is the bitbucket-pipelines.yml file. It defines all your build configurations (pipelines) and needs to be created in the root of your repository. With 'configuration as code', your bitbucket-pipelines.yml is versioned along with all the other files in your repository, and can be edited in your IDE. If you've not yet created this file, you might like to read Get started with Bitbucket Pipelines first.

YAML は読みやすいファイル形式ですが、書き込みを行う際には注意が必要です。タブ文字は使用できないため、インデントにはスペースを使用する必要があります。

パイプラインではさまざまな処理を実行するよう構成できますが、YAML ファイルで最も基本的な内容として、必須キーワードがあります。

pipelines:marks the beginning of all your pipeline definitions.

default: contains the steps that will run on every push.

step : each step starts a new Docker container that includes a clone of your repository, and then runs the contents of your script section inside it.

script : a list of commands that are executed in sequence.


Pipelines can contain any software language that can be run on Linux. We have some examples, but at its most basic a bitbucket-pipelines.yml file could look like this:

pipelines:
  default:
    - step:
        script:
          - echo 'I made a pipeline!'

You can then build on this using the keywords listed below.


If you have a complex configuration there are a couple of techniques that you might find useful:

  • You can use pipes which simplify common multi-step actions.
  • If you have multiple steps performing similar actions, you can add YAML anchors to easily reuse sections of your configuration.



主なコンセプト

パイプラインは、一連のステップで構成されます。

  • パイプラインの各ステップは、別の Docker コンテナを実行します。必要に応じて別のイメージを選択することで、各ステップで別のタイプのコンテナを使用できます。
  • ステップは、画像で示すように、環境内で指定されたコマンドを実行します。
  • 1 つのパイプラインに、最大 10 のステップを含めることができます。

コミットは、パイプラインを実行する必要があることを知らせます。実行されるパイプラインは、それが含まれるセクションによって異なります。

  • 既定 - すべてのコミットがこのパイプラインをトリガーします (他のセクションのいずれかと一致している場合を除く)
  • branch - ブランチの名前を指定するか、glob パターンを使用します。
  • タグ (Git のみ) またはブックマーク (Mercurial のみ) - タグまたはブックマークの名前を指定するか、glob パターンを使用します。
  • custom - 手動でトリガーされたときにのみ実行します。
  • pull-requests - Specify the name of a branch, or use a glob pattern, and the pipeline will only run when there is a pull request on this branch.


インデントによる論理的な "セクション" 作成の概要

キーワード

次のキーワードを選択してビルド パイプラインを定義できます。この表では、キーワードを使用頻度に応じて紹介しています。強調表示された行は、論理セクションを定義するキーワードに対応します。

キーワード 説明
pipelines すべてのパイプライン定義を含みます
default

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

ブランチ

特定のブランチのパイプライン定義が含まれます。

tags 特定の Git タグおよび注釈付きタグのパイプライン定義が含まれます。
bookmarks 特定の Mercurial ブックマークのパイプライン定義が含まれます。
カスタム Bitbucket Cloud の GUI から手動でトリガーできるパイプラインが含まれます。
pull-requests Contains pipeline definitions that only run on pull requests.
parallel 同時に実行するステップを含みます。
step

ビルドの実行単位を定義します。これは、実行されるコマンドと一意のコンテナの設定を定義します。

name ステップの名前を定義し、ステップで実行される内容を可視化します。
image ステップに使用される Docker イメージ。イメージを指定しない場合、パイプラインは既定の Bitbucket イメージで実行されます。各ステップで同じイメージ タイプを使用するよう、グローバルに定義することもできます。
trigger ステップが手動または自動のどちらであるかを指定します。trigger タイプを指定しない場合、既定で自動に設定されます。
デプロイメント

デプロイメント ステップの環境タイプを定義します。

Valid values are: test, staging, or production.

size

パイプラインとステップの追加リソースをプロビジョニングするために使用されます。

Valid values are: 1x or 2x

script ビルドを実行するためのコマンドの一覧が含まれます。
pipe

To specify that you'd like to use a particular pipe.

after-script A set of commands that will run when your step succeeds or fails
artifacts ステップで生成され、次のステップで共有できるファイル (レポートや JAR ファイルなど) を定義します。
options すべてのパイプラインに適用するグローバル設定を含みます。
max-time

ステップを実行できる最長時間 (分)。

0 〜 120 の整数を使用します。max-time を指定しない場合、既定で 120 に設定されます。

clone リポジトリのクローンをコンテナに作成した時の設定を含みます。
lfs Enables the download of LFS files in your clone. This defaults to false if not specified.
depth

すべてのパイプラインの Git クローンの深度を定義します。

Use a whole number greater than zero to specify the depth. Use full for a full clone. If you don't specify the Git clone depth, it defaults to 50.

注: このキーワードは Git リポジトリでのみサポートされます。

定義 パイプライン構成の他の場所で使用する、サービスやカスタム キャッシュなどのリソースを定義します。
services ビルドで使用するサービスを定義します。このサービスはリンクされた別のコンテナで実行されます。
caches 読み込み時間を短縮するため、サーバー上でキャッシュする依存関係を定義します。

pipelines

パイプライン定義の開始。このキーワードの下で、次のうち 1 つ以上を使用してビルド パイプラインを定義する必要があります。

  • default (以下のいずれとも一致しないすべてのブランチ)
  • ブランチ (Git および Mercurial)
  • タグ (Git)
  • ブックマーク (Mercurial)
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!" 

default

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

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


ブランチ

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

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

ブランチ名の処理には glob パターンを使用できます。

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


tags

Defines all tag-specific build pipelines. The names or expressions in this section are matched against tags and annotated tags in your Git repository. You can use glob patterns for handling the tag names.


bookmarks

Defines all bookmark-specific build pipelines. The names or expressions in this section are matched against bookmarks in your Mercurial repository. You can use glob patterns for handling the tag names.


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

カスタム

Defines pipelines that can only be triggered manually or scheduled from the Bitbucket Cloud interface.


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 "Automated pipelines are cool too."


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



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

pull-requests

A special pipeline which only runs on pull requests. Pull-requests has the same level of indentation as branches.

This type of pipeline runs a little differently to other pipelines. When it's triggered, we'll merge the destination branch into your working branch before it runs. If the merge fails we will stop the pipeline.


This only applies to pull requests initiated from within your repository; pull requests from a forked repository will not trigger the pipeline.

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:
            - ...
Tip: If you already have branches in your configuration, and you want them all to only run on pull requests, you can simply replace the keyword  branches  with  pull-requests  (if you already have a pipeline for  default  you will need to move this under  pull-requests  and change the keyword from default  to '**' to run).

Pull request pipelines run in addition to any branch and default pipelines that are defined, so if the definitions overlap you may get 2 pipelines running at the same time!


parallel

並行ステップを使用すると、一連のステップを同時に実行して、ビルドやテストを迅速に行えます。

ステップを並行した場合も、パイプラインが使用する合計のビルド時間数は変わりません。ただし、結果はより早く表示されます。

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

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

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

Defines a build execution unit. Steps are executed in the order that they appear in the bitbucket-pipelines.yml file. You can use up to 10 steps in a pipeline.

Each step in your pipeline will start a separate Docker container to run the commands configured in the script. Each step can be configured to:

Steps can be configured to wait for a manual trigger before running. To define a step as manual, add trigger: manual to the step in your bitbucket-pipelines.yml file. Manual steps:

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

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

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

name

ステップに名前を設定して、表示やレポートをわかりやすくすることができます。

名前を使用しているパイプラインのイメージj

image

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

  • You can use the default image (atlassian/default-image:latest) provided by Bitbucket or define a custom image. You can specify any public or private Docker image that isn't hosted on a private network.
  • イメージは、グローバルまたはステップ レベルで定義できます。ブランチ レベルでは定義できません。

イメージを指定するには、次のように指定します。

image: <your_account/repository_details>:<tag>

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

image: openjdk
最新の openjdk バージョンのイメージを使用
image: openjdk:8
openjdk バージョン 8 のイメージを使用
image: nodesource/node:iojs-2.0.2
バージョン iojs-2.0.2の非公式ノードバージョンを使用します。
image: openjdk 					#this image will be used by all steps unless overridden 
   
pipelines:
  default:
    - step:
      image: nodesource/node:iojs-2.0.2 #override the global image for this step
      script:
        - npm install
        - npm test
    - step: 					#this step will use the global image
	  script:
        - npm install
        - npm test


trigger

Specifies 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.5.1
        trigger: manual
        script:
          - python deploy.py


デプロイメント

[Deployments] ダッシュボードで使用される、デプロイメント ステップの環境タイプを設定します。

Valid values are test, staging, or production.

The following step will display in the test environment in the Deployments view:

    - 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).

At this time, valid sizes are 1x and 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."

パイプライン全体のリソースを増やす

グローバル サイズを使用すると、すべてのステップに "2x" サイズが継承されます。

options:
  size: 2x

pipelines:
  default:
    - step:
        name: Step with more memory
        script:
          - echo "I've got double the memory to play with!"

script

Contains a list of commands that are executed in sequence. Scripts are executed in the order in which they appear in a step. We recommend that you move large scripts to a separate script file and call it from the bitbucket-pipelines.yml.


pipes


Pipes 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.

A pipe to send a message to Opsgenie might look like:

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"


You can also create your own pipes. If you do, you can specify a docker based pipe with the syntax:

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

after-script

Commands inside an after-script section will run when the step succeeds or fails. This could be useful for clean up commands, test coverage, notifications, or rollbacks you might want to run, especially if your after-script uses the value of BITBUCKET_EXIT_CODE.

Note: If any commands in the after-script section fail:

  • we won't run any more commands in that section
  • it will not effect the reported status of the step.
pipelines:
  default:
    - step:
        name: Build and test
        script:
          - npm install
          - npm test
        after-script:
          - echo "after script has run!"


artifacts

パイプラインのあるステップから後のステップへ共有するファイルを定義します。アーティファクトは 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.5.1
        script:
          - python deploy-to-production.py

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

options

すべてのパイプラインに適用するグローバル設定を含みます。現在定義できるオプションは max-time のみです。

max-time

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

max-time を指定しない場合、既定で 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

clone

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

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

lfs

クローン時に Git LFS ファイルをダウンロードするように指定するグローバル設定です。

注: このキーワードは Git リポジトリでのみサポートされます。

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


depth

This global setting defines how many commits we clone into the pipeline container. Use a whole number greater than zero or if you want to clone everything (which will have a speed impact) use full.

If you don't specify the Git clone depth, it defaults to the last 50, to try and balance the time it takes to clone and how many commits you might need.

注: このキーワードは Git リポジトリでのみサポートされます。

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


定義

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

services

Rather than trying to build all the resources you might need into one large image, we can spin up separate docker containers for services. This will tend to speed up the build, and makes it very easy to change a single service without having to redo your whole image.

そのため、redis サービス コンテナが必要な場合は、次のように追加することができます。

definitions:
  services:
    redis:
      image: redis


caches

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

カスタム バンドル キャッシュの定義方法の例:

definitions:
  caches:
    bundler: vendor/bundle


Glob パターンのヒント

Glob patterns don't allow any expression to start with a star. Every expression that starts with a star needs to be put in quotes.

feature/*
  • feature/<any_branch> と一致します。
  • glob パターンはスラッシュ (/) とは一致しないので、feature/<任意のブランチ>/<ブランチ> などの Git ブランチは、feature/* には一致しません。
feature/bb-123-fix-links
  • ブランチ、タグ、またはブックマークの正確な名前を指定すると、特定のブランチに対して定義されたパイプラインは、そのブランチに一致する一般的な表現をすべて上書きします。
  • たとえば、feature/*feature/bb-123-fix-links のパイプラインを指定したとします。feature/bb-123-fix-links へのコミットの際、Pipelines では、feature/bb-123-fix-links に対して定義されたステップを実行しますが、feature/* で定義されたステップは実行しません。
'*'


  • すべてのブランチ、タグ、またはブックマークと一致します。アスタリスク (*) は一重引用符で囲む必要があります。
  • この glob パターンはスラッシュ (/) とは一致しないので、feature/bb-123-fix-links などの Git ブランチは '*' には一致しません。スラッシュを一致させる必要がある場合は、'*' ではなく '**' を使用します。


'**'
  • すべてのブランチ、タグ、またはブックマークと照合します。feature/bb-123-fix-links などの、スラッシュ (/) を含むブランチが含まれます。** の表現は引用符で囲む必要があります。
'*/feature'
  • この表現には引用符が必要です。

'master' and duplicate branch names

  • Names in quotes are treated the same way as names without quotes. For example, Pipelines sees master and 'master' as the same branch names.
  • In the situation described above, Pipelines will match only against one name (master or'master', never both).
  • We recommend that you avoid duplicate names in your bitbucket-pipelines.yml file.

なお、以下の説明もご覧ください:



最終更新日 2019 年 3 月 7 日

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

はい
いいえ
この記事についてのフィードバックを送信する

このセクションの項目

Powered by Confluence and Scroll Viewport.