bitbucket-pipelines.yml 구성하기

bitbucket-pipelines.yml 파일은 파이프라인 구성을 빌드 정의합니다. Pipelines를 처음 사용하는 경우 자세한 내용은 Bitbucket Pipelines 시작하기 문서를 참조하세요.

기본 구성 

기본 구성을 사용하면 스크립트를 작성하여 프로젝트를 빌드 및 배포하고 캐시를 구성하여 빌드 속도를 높일 수 있습니다. 파이프라인에서 수행하는 작업 전반에 걸쳐 서로 다른 종속성을 관리하기 위해 각 step에 서로 다른 이미지를 지정할 수도 있습니다.

파이프라인은 step 목록으로 구성되며 구성 파일에 여러 파이프라인을 정의 할 수 있습니다. 아래 제공된 다음 다이어그램에서 기본 섹션 아래에 구성된 파이프라인을 볼 수 있습니다. 파이프라인 구성 파일에는 특정 키워드로 식별되는 여러 섹션이있을 수 있습니다.

시작하기 전에

• 파일에는 Step 내에 하나 이상의 Step과 하나의 스크립트로 구성된 파이프라인 섹션이 하나 이상 있어야합니다.

• 각 Step에는 4GB의 사용 가능한 메모리가 있습니다.

• 단일 파이프라인에는 최대 100 개의 Step이 있을 수 있습니다.

• 파이프라인의 각 Step 은 별도의 Docker 컨테이너를 실행합니다. 원하는 경우 다른 이미지를 선택하여 각 Step에 대해 다른 유형의 컨테이너를 사용할 수 있습니다.

Step

1. yaml 파일을 구성하려면 Bitbucket에서 저장소로 이동 하고 왼쪽 네비게이션에서 Pipelines을 선택합니다 . Bitbucket의 인터페이스를 사용하지 않고 yaml 파일을 구성 할 수도 있습니다.

2. 언어를 선택하십시오.
   참고 :  파이프라인은 모든 언어로 프로젝트를 빌드하거나 배포하도록 구성 할 수 있습니다. 

3. 이미지를 선택합니다.
   파일에는 하나 이상의 step과 step 내에 하나의 스크립트로 구성된 파이프라인 섹션이 하나 이상 있어야합니다.

아래는 위 다이어그램에 요약 된 각 섹션에 대한 설명입니다.

default - 다른 부분의 파이프라인의 정의와 일치하지 않는 모든 브랜치에 대한 파이프 라인의 정의를 포함합니다.

기본 파이프라인은 각 브랜치 별로 파이프라인이 정의되지 않은 경우 저장소에 대한 모든 푸시에서 실행됩니다. Brnaches 섹션 에서 브랜치 파이프라인을 정의 할 수 있습니다  .

참고 :  기본 파이프 라인은 태그 또는 북마크에서 실행되지 않습니다.

branches - 다른 부분의 파이프라인의 정의와 일치하지 않는 모든 브랜치에 대한 파이프라인의 정의를 포함합니다.

tags - 모든 태그 별 빌드 파이프라인을 정의합니다. 이 섹션의 이름 또는 표현식은 Git 저장소의 태그 및 주석이 달린 태그와 일치합니다.

bookmarks -모든 북마크 관련 빌드 파이프라인을 정의합니다.

pull requests - 저장소 내에서 시작된 풀 요청에서만 실행되는 특수 파이프라인입니다. 실행하기 전에 대상 브랜치를 작업 브랜치로 병합합니다. 포크 된 저장소의 풀 요청은 파이프라인을 트리거하지 않습니다. 병합이 실패하면 파이프라인이 중지됩니다.

구성에 이미 브랜치가 있고 풀 요청에서만 실행되도록 하려면, 키워드 branches를 pull-requests로 바꿉니다.

에제

pipelines:
  pull-requests:
    '**': # 다른 곳에 정의되지 않은 브랜치에 대해 기본값으로 실행됩니다.
      - step:
          script:
            - ...
    feature/*: # feature로 시작하는 모든 브랜치
      - step:
          script:
            - ...
branches:    # 브랜치의 모든 푸시에 대해 실행됩니다.
    staging:
      - step:
          script:
            - ...

custom - 수동으로만 트리거하거나 Bitbucket Cloud 인터페이스에서 스케줄링할 수 있는 파이프라인을 정의합니다.

예제

image: node:10.15.0
    
pipelines:
  custom: # 수동으로 트리거되는 파이프 라인
    sonar: # Bitbucket Cloud GUI의 목록에 표시되는 이름
      - step:
          script:
            - echo "Manual triggers for Sonar are awesome!"
    deployment-to-prod: # 다른 표시 이름
      - step:
          script:
            - echo "Manual triggers for deployments are awesome!"
  branches:  # 브랜치 커밋시 자동으로 실행되는 파이프 라인
    staging:
      - step:
          script:
            - echo "Auto pipelines are cool too."

예제:

image: node:10.15.0
   
pipelines:
  default:
    - step:
        name: Build and test
        script:
          - npm install
          - npm test
  tags:                         # '태그' 섹션 추가
    release-*:                  # 태그 지정
      - step:                   # 태그에 대한 빌드 파이프라인 정의
          name: Build and release
          script:
            - npm install
            - npm test
            - npm run release
  branches:
    staging:
      - step:
          name: Clone
          script:
            - echo "Clone all the things!"

Advanced configuration

서비스를 실행하고 테스트를 병렬로 실행하려면 advanced options을 사용하십시오. 또한 수동 step 구성 및 각 step에 대한 최대 시간 설정과 같은 작업을 수행 할 수 있으며, 8GB 메모리를 확보하도록 2x step을 구성 할 수 있습니다.

시작하기 전에

• 파이프라인 YAML 파일에는 키워드와 하나 이상의 step이 있는 섹션이 하나 이상 있어야합니다.

• 각 step에는 4GB의 사용 가능한 메모리가 있습니다.

• 단일 파이프라인에는 최대 100 개의 step이 있을 수 있습니다.

• 파이프라인의 각 step은 별도의 Docker 컨테이너를 실행합니다. 원하는 경우 다른 이미지를 선택하여 각 step에 대해 다른 유형의 컨테이너를 사용할 수 있습니다.

Global configuration options

다음은 글로벌 구성 옵션 및 설명과 관련된 키워드 목록입니다.

variables - [사용자 지정 파이프 라인 만 해당] 파이프라인이 시작될 때 제공되는 변수를 포함합니다. 변수를 활성화하려면 파이프라인을 실행할 때 입력하려는 사용자 지정 파이프라인 아래에 변수를 정의합니다.

예제

pipelines:
  custom:
    custom-name-and-region: #이 파이프 라인의 이름
      - variables:          #여기에 변수 이름을 나열합니다
          - name: Username
          - name: Region
      - step: 
          script:
            - echo "User name is $Username"
            - echo "and they are in $Region"

그런 다음 Branches  >  ⋯  >  Run pipeline for a branch  >  Custom에 액세스하여 사용자 지정 파이프라인을 실행할 때 변수 값을 설정하여 사용자 지정 파이프라인을 실행할 수 있습니다.

키워드  variables는 서비스 정의의 일부일 수도 있습니다.

name - 키워드 이름이 YAML의 변수 섹션에있을 때, 그것은 사용자 지정 파이프라인을 실행할 때 추가 또는 업데이트 할 수있는 변수를 정의합니다. 파이프라인은 step 내에서 키워드를 사용할 수 있습니다.

parallel - 병렬 step을 사용하면 일련의 step을 동시에 실행하여 더 빠르게 빌드하고 테스트 할 수 있습니다. 파이프라인에서 사용하는 총 빌드 시간 (분)은 step을 병렬로 만들 경우 변경되지 않지만 결과를 더 빨리 볼 수 있습니다.

파이프라인 정의에서 가질 수있는 총 step 수는 병렬 또는 직렬 실행 여부에 관계없이 100개로 제한됩니다.

step을 들여 쓰기하여 동시에 실행되는 step을 정의하십시오.

예제

pipelines:
  default:
    - step: # non-parallel step
        name: Build
        script:
          - ./build.sh
    - parallel: # 해당 2 step들은 병렬로 실행됩니다.
        - 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 - 빌드 실행 단위을 정의합니다. step은 bitbucket-pipelines.yml  파일에 표시된 순서대로 실행 됩니다. 단일 파이프라인에는 최대 100개의 step이 있을 수 있습니다.

파이프라인의 각 step은 script에 구성된 명령을 실행하기 위해 별도의 Docker 컨테이너를 시작합니다. 각 step은 다음과 같이 구성 할 수 있습니다.

• 다른 Docker 이미지를 사용

• 사용자 지정 최대 시간을 구성

• 특정 캐시 및 서비스를 사용

• 후속 step에서 사용할 수있는 아티팩트를 생성

• 여기에 복제 섹션이있을 수 있습니다.

실행하기 전에 수동 트리거를 기다리도록 step을 구성 할 수 있습니다. step을 수동으로 정의하려면 bitbucket-pipelines.yml 파일의 step에 trigger : manual을  추가합니다. 수동 step:

• 구성된 순서 대로만 실행할 수 있습니다. 수동 step을 건너 뛸 수 없습니다.

• 이전 step이 성공적으로 완료된 경우에만 실행할 수 있습니다.

• 저장소에 대한 쓰기 권한이있는 사용자만 트리거 할 수 있습니다.

• Pipelines 웹 인터페이스를 통해 트리거 됩니다.

빌드에서 수동 step과 아티팩트를 모두 사용하는 경우 아티팩트를 생성 한 step 실행 후 14 일 동안 저장 됩니다. 이 시간이 지나면 아티팩트가 만료되고 파이프라인의 모든 수동 step을 더 이상 실행할 수 없습니다.

참고 : 파이프라인의 첫 번째 step을 수동 step으로 구성 할 수 없습니다.

name - 화면에서 각 step이 수행하는 작업을 더 쉽게 볼 수 있도록 step의 이름을 정의합니다.

image - Bitbucket Pipelines는 Docker 컨테이너를 사용하여 빌드를 실행합니다.

• 여러분이 사용할 수있는 Bitbucket에 의해 제공되는 the default image (atlassian/default-image:2) 또는 사용자 정의 이미지를 정의합니다. 사설 네트워크에서 호스팅되지 않는 공용 또는 개인 Docker 이미지를 지정할 수 있습니다.

• 전역 또는 step 수준에서 이미지를 정의 할 수 있습니다. 브랜치 수준에서 이미지를 정의 할 수는 없습니다.

다음과 같이 이미지를 사용하십시오: <your_account/repository_details>:<tag>

예제

pipelines:
  default:
    - step:          # non-parallel step
        name: Build
        script:
          - ./build.sh
    - parallel:      # 해당 2 step들은 병렬로 실행됩니다.
        - 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

trigger - step이 자동으로 실행되는지 아니면 누군가가 수동으로 트리거 한 후에 만 ​​실행할지 지정합니다. 트리거 유형을 manual 또는 automatic으로 정의 할 수 있습니다. 트리거 유형이 정의되지 않은 경우 step은 기본적으로 automatic으로 설정됩니다. 첫 번째 step은 수동일 수 없습니다. 전체 파이프라인이 수동 트리거에서만 실행되도록하려면 사용자 지정 파이프라인을 사용하십시오.

예제

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 -  배포 step에 대한 환경 유형을 설정하며 Deployments 대시보드에서 사용됩니다. 유효한 값은 test , staging 또는 production 입니다.

다음 step은 Deployments 뷰의 test 환경에서 표시됩니다  .

유효한 값은 test , staging 또는 production 입니다.

Example

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

size - step 또는 전체 파이프라인에 추가 리소스를 할당 할 수 있습니다. 2x 의 크기를 지정하면  사용 가능한 리소스가 두 배가됩니다 (예 : 4GB 메모리 → 8GB 메모리).

현재 유효한 크기는  1x  및  2x 입니다.

2x 파이프라인은 빌드 시간의 두 배를 사용합니다.

예 : 단일 step의 size 재정의

pipelines:
  default:
    - step:
        script:
          - echo "All good things..."
    - step:
        size: 2x # 이 step에 사용할 수있는 리소스가 두 배입니다.
        script:
          - echo "Come to those who wait."

script - 순서대로 실행되는 명령 목록을 포함합니다. 스크립트는 step에 나타나는 순서대로 실행됩니다. 큰 스크립트를 별도의 스크립트 파일로 이동하고 이를 bitbucket-pipelines.yml에서 호출하는 것이 좋습니다.

pipe - 파이프는 뒤에서 많은 작업을 수행하여 복잡한 작업을 더 쉽게 만듭니다. 즉, 사용할 파이프를 선택하고 필요한 변수를 제공 할 수 있습니다. 파이프에 대한 저장소에서 실행중인 명령을 확인할 수 있습니다. 

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"

고유 한 파이프를 만들 수도 있습니다그렇게하면 다음 구문을 사용하여 도커 기반 파이프를 지정할 수 있습니다.

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

after-script - 이후 스크립트 섹션 내의 명령은 step이 성공하거나 실패 할 때 실행됩니다. 이는 특히 사후 스크립트가 BITBUCKET_EXIT_CODE 값을 사용하는 경우 실행하려는 명령, 테스트 범위, 알림 또는 롤백을 정리하는데 유용 할 수 있습니다  .

참고 : 이후 스크립트 섹션의 명령이 실패하는 경우

• 해당 섹션에서 더 이상 명령을 실행하지 않습니다.

• step의 보고 된 상태에 영향을주지 않습니다.

예제

pipelines:
  default:
    - step:
        name: Build and test
        script:
          - npm install
          - npm test
        after-script:
          - echo "after script has run!"

artifacts - 다음 step과 공유하려는 보고서 및 JAR 파일과 같은 step에서 생성되는 파일을 정의합니다.

예제

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 - step이 전역 수준 또는 step 수준에서 실행할 수있는 최대 시간 (분)을 정의 할 수 있습니다. 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

최대 시간을 지정하지 않으면 기본값은 120 입니다.

clone - 저장소를 컨테이너에 복제 할 때의 설정을 포함합니다. 여기 설정은 다음과 같습니다.

• LFS - Git LFS 지원

• depth - Git 클론 depth

• enabled setting을 false로 설정하면 git 클론이 사용 중지됩니다.

LFS (GIT only) - 복제본에서 LFS 파일을 다운로드 할 수 있습니다. lfs는 지정되지 않은 경우 기본적으로 false입니다.

예제

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

depth (Git only) - 모든 파이프라인에 대한 Git 클론의 depth를 정의합니다. 키워드는 Git 저장소에 대해서만 지원됩니다.

depth를 지정하려면 0 보다 큰 정수를 사용하십-시오. full clone하려면 full 사용합니다. Git clone depth를 지정하지 않으면, 값은 기본적으로 50입니다.

에시

clone:
  depth: 5       # 최근 5개 커밋을 포함  
pipelines:
  default:
    - step:
        name: Cloning
        script:
          - echo "Clone all the things!"

enabled - enabled setting을 false로 설정하면 git 클론이 사용 중지됩니다.

예제

pipelines:
  default:
    - step:
        name: No clone
        clone:
          enabled: false
        script:
          - echo "I don't need to clone in this step!"
    

condition - 조건 또는 규칙이 충족 될 때만 step을 실행할 수 있습니다. 현재 지원되는 유일한 조건은 변경 집합입니다. 수정 된 파일 중 하나가 includePaths의 표현식과 일치하는 경우에만 step을 수행하도록 하려면 changesets를 사용하십시오.

고려되는 변경 사항 :

풀 요청 파이프라인에서는 모든 커밋이 고려되며 includePath 패턴의 목록을 제공하면  하나 이상의 커밋 변경이 조건 중 하나와 일치 할 때 step이 실행됩니다. 패턴 일치의 형식은 glob 패턴을 따릅니다 .

예제

다음 예제에서  step1  은 파이프라인을 트리거 한 커밋에 path1 디렉터리 내의 XML 파일 또는 path2 아래의 디렉터리 구조에있는 파일의 변경 사항이 중첩으로 포함 된 경우에만 실행됩니다.

- 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/**"

파일에 변경 사항이 없으면 step을 건너 뛰고 파이프라인이 성공합니다.

다른 유형의 파이프라인의 경우 마지막 커밋만 고려됩니다. 예를 들어 마스터의 풀 요청 병합 커밋에는 문제가 없지만 여러 커밋을 동시에 브랜치에 푸시하거나 특정 브랜치에 여러 번 푸시하면 실패한 파이프라인이 녹색으로 변할 때 직관적이지 않은 동작이 발생할 수 있습니다. 다음 실행에서 step을 건너 뜁니다.

Conditions 및 merge checks

성공적인 빌드 결과가 풀 요청 merge checks에 포함되는 경우 step의 조건이 브랜치 파이프라인에 대해 false-positives를 생성 할 수 있습니다. 빌드 결과 일관성이 가장 중요한 경우 조건을 완전히 피하거나 풀 요청 파이프라인만 사용하십시오.

definitions - 파이프라인 구성의 다른 곳에서 사용되는 리소스를 정의합니다. 리소스에는 다음이 포함될 수 있습니다.

• 별도의 Docker 컨테이너에서 실행되는 서비스

• Caches – see Caching dependencies.

• YAML anchors - 쉽게 재사용할 수 있도록 yaml 코드 블럭를 정의하는 방법 - YAML anchors

services - 파이프라인은 서비스에 대해 별도의 도커 컨테이너를 스핀 업할 수 있으므로 빌드가 더 빨라지고 서비스 편집이 쉬워집니다.

완전히 구성된 서비스의 예

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 - 빌드의 각 step마다 인터넷에서 종속성을 다시 다운로드하는 데 많은 시간이 소요될 수 있습니다. 캐시를 사용하면 서버에 한 번 다운로드 된 다음 매번 빌드에서 로컬로 로드 됩니다.

예제

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

YAML anchors - YAML anchors - 쉽게 재사용할 수 있도록 yaml 코드 블럭를 정의하는 방법 - YAML anchors