카테고리 없음

GitLab .gitlab-ci.yml 자주 사용되는 명령

ㅈ현 2022. 6. 19. 05:43

gitlab 파이프라인을 위한 파일 작성법으로써, 자세한 작성법은 아래 링크를 참고하길 바람.

https://docs.gitlab.com/ee/ci/yaml/

 

`.gitlab-ci.yml` keyword reference | GitLab

Documentation for GitLab Community Edition, GitLab Enterprise Edition, Omnibus GitLab, and GitLab Runner.

docs.gitlab.com

자주 사용되는 CI/CD 변수 List

 

Predefined variables reference | GitLab

Documentation for GitLab Community Edition, GitLab Enterprise Edition, Omnibus GitLab, and GitLab Runner.

docs.gitlab.com

 

1. example

 

stages:
  - build
  - test

build-code-job:
  stage: build
  script:
    - echo "Check the ruby version, then build some Ruby project files:"
    - ruby -v
    - rake

test-code-job1:
  stage: test
  script:
    - echo "If the files are built successfully, test some files with one command:"
    - rake test1

test-code-job2:
  stage: test
  script:
    - echo "If the files are built successfully, test other files with a different command:"
    - rake test2

 

 

2. workflow: rules

최상위 파이프 라인 생성 여부 결정

  • if : 파이프 라인이 실행할 시기 결정
    • - if: $CI_PIPELINE_SOURCE == "schedule" : 스케줄로만 실행
    • - if: $CI_PIPELINE_SOURCE == "merge_request_event" : 머지 리퀘스트 있을 시 실행
    • - if: $CI_COMMIT_BRANCH == "master" : 마스터 브랜치에서만 실행 이렇게 특정 조건에서 파이프 라인이 실행되도록 결정
  • when : if 문의 결과가 true일때 수행할 작업 지정
    • always: 이전 단계 작업상관없이 실행 (나중에 when설명 나옴)
    • never: 실행하지 않음
  • when: final ```ymal workflow: rules:
    • if: $CI_PIPELINE_SOURCE == “schedule” when: never
    • if: $CI_PIPELINE_SOURCE == “push” when: always #스케줄로 실행시 실행하지 않고, push로 실행시 실행한다 =================================================================== rules:
    • if: $CI_PIPELINE_SOURCE == “schedule” when: never
    • if: $CI_PIPELINE_SOURCE == “push” when: never
    • when: always //final when : 스케줄, push로는 pipeline이 실행되지 않고 그외 경우에는 pipeline이 실행된다 //ex) 수동실행 ```
workflow:
  rules:
    - if: $CI_COMMIT_TITLE =~ /-draft$/
      when: never
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

3. stages

작업을 포함하는 단계를 정의한다

  • test
  • buile
  • deploy

4. image

작업에서 사용할 runner의 Docker image를 지정하는데 사용

  • image:name 사용할 이미지의 이름(repository)
  • image:entrypoint 이미지의 entrypoint(Dockerfile의 entrypoint와 같음) 

 

image:
  name: alpine
  entrypoint: [""]

5. services

기본 이미지에서 사용할 서비스 이미지
ex)

image: ubuntu
services:
  -  name: mysql

ubuntu 이미지 안에서 mysql을 서비스로 사용하겠다는 의미.

5.1 dind

docker in docker라는 의미로, 파이프라인 내에서 docker 빌드가 필요할떄 사용한다.

6. script

작업동안 실행할 명령 정의

job1:
  ...
  script: ls    //한개
job2: 
  ...
  script: 
    - cd       //한개 이상
    - ls

 

7. before_script, after_script

작업 전 후에 사용할 스크립트를 지정한다

default:
  before_script:
     ...
  after_script:
    ...

위 방식대로 사용하면 전역적으로 사용할 수있다.

또한 아래 방식처럼 job 내부에서 사용할 수도 있다.

job 내부에서 사용한 after script

8. stage

실행되는 단계를 정의하는데 사용하며 stages에 정의된 작업에 의존한다.

9. .pre, .post 

모든 파이프 라인에서 사용할 수 있으며 stages에 명시적으로 선언하지 않아도 사용할 수 있다.

  • .pre : 파이프라인 시작 전 실행되는 단계다
  • .post : 파이프라인 종료시 실행되는 단계다
stages:
  - b
  - a

stage0:
  stage: .pre
  ...
stage1:
  stage: a
  ...
stage2:
  stage: b
  ...
stage3:
  stage: .post 
  ...

위 예시에서는 a, b 두개의 stages가 존재하며, 

10. rules

파이프 라인에서 작업을 포함, 제외할 수 있다.
또한 rules는 only, except 키워드하고 같이 사용할 수 없다.

  • when: 규칙이 true일때 실행되는 구문임. 정의하지 않은 경우 default: on_success임
    • when: delayed 로 사용할 경우 start_in 옵션 필요함
  • allow_failure: 정의하지 않은 경우 default: false임

사용 가능한 규칙은

  • if : if문 결과에 따라 파이프라인 등록, 제외함
  • changes : 변경 내용에 따라 파이프 라인 등록, 제외함
  • exists : 파일의 존재 여부에 따라 파이프라인 등록, 제외함

규칙에 일치하는 항목이 없어도 마지막 라인이 - when: on_success, delayed, always 인 경우 파이프 라인에 등록된다.

ex1)

  1. merge 요청일 경우 수작업(manual)으로 등록됨 (만약 수작업이 실행되지 않아도 allow_failure에 의해 등록됨)
  2. schedule인 경우 등록됨
  3. 그 외 모든 경우는 등록되지 않는다

ex2)

  1. merge요청의 경우 등록되지 않음
  2. schedule 인 경우 등록되지 않음
  3. 그 외 모든 경우에는 등록됨

10. 1rules:if 

if 규칙은 다음으로 해석된다

  • 이 규칙이 true이면 작업(job)을추가하시오
  • when: never 있을경우 : 이 규칙이 true이면 작업을 추가하지 마시오

10.1.1 $CI_PIPELINE_SOURCE 의 결과값들 

  • api: 파이프 라인 API 에 의해 트리거 된 파이프 라인의 경우 .
  • chat: GitLab ChatOps 명령 을 사용하여 생성 된 파이프 라인의 경우 .
  • external: GitLab 이외의 CI 서비스를 사용하는 경우.
  • external_pull_request_event: GitHub에서 외부 pull 요청이 생성되거나 업데이트 될 때. 외부 pull 요청에 대한 파이프 라인을 참조하십시오 .
  • merge_request_event: 병합 요청이 생성되거나 업데이트 될 때 생성 된 파이프 라인의 경우. 병합 요청 파이프 라인 , 병합 된 결과 파이프 라인 및 병합 열차 를 활성화하는 데 필요합니다 .
  • parent_pipeline: 부모 파이프 라인에서 트리거
  • pipeline: 위해 멀티 프로젝트 파이프 라인 에 의해 생성 과 API 사용CI_JOB_TOKEN , 또는 trigger키워드를.
  • push: git push분기 및 태그를 포함 하여 이벤트 에 의해 트리거 된 파이프 라인의 경우.
  • schedule: 대한 계획 파이프 라인 .
  • trigger: 트리거 토큰 을 사용하여 생성 된 파이프 라인의 경우 .
  • web : 프로젝트의 CI / CD> 파이프 라인 섹션 에서 GitLab UI의 파이프 라인 실행 버튼 을 사용하여 생성 된 파이프 라인의 경우 .
  • webide : WebIDE 를 사용하여 생성 된 파이프 라인의 경우 .

10.1.2 if절에 사용되는 변수

  • if: $CI_COMMIT_TAG: 태그에 대한 변경 사항이 푸시되는 경우.
  • if: $CI_COMMIT_BRANCH: 변경 사항이 분기로 푸시되는 경우.
  • if: ‘$CI_COMMIT_BRANCH == “master”‘: 변경 사항이 master.
  • if: ‘$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH’: 변경 사항이 기본 분기로 푸시되는 경우 (일반적으로 master). 
    기본분기가 다른 여러 프로젝트에서 동일한 구성을 원할 때 사용합니다.
  • if: ‘$CI_COMMIT_BRANCH =~ /regex-expression/’: 커밋 분기가 정규식과 일치하는 경우.
  • if: ‘$CUSTOM_VARIABLE !~ /regex-expression/’: 맞춤 변수 CUSTOM_VARIABLE 가 정규 표현식과 일치 하지 않는 경우 .
  • if: ‘$CUSTOM_VARIABLE == “value1”‘: 맞춤 변수 CUSTOM_VARIABLE가 정확히 value1.

10. 2 rules: changes 

특정 파일의 변경사항을 확인하여 파이프라인 추가 여부를 결정한다

job:
  rules:
    - changes:
      - Dockerfile
    when: always
// Dockerfile이 변경되면 작업을 추가한다.

환경 변수또한 사용 가능하다.

10.3 rules:exists 

경로에 파일이 존재하는 경우 true

Dockerfile이 존재하면 true다

또한 glob 패턴을 사용할 수 있다. ex) *.txt

10.4 rules:allow_failure 

allow_failure: true를 사용하여 작업에 실패해도 파이프 라인을 중지하지 않도록 허용할 수 있다.

10.5 복합절 

if, changes, exists등을 연결해서 사용하면 AND로 묶여서 사용된다.

만약 Dockerfile이나 아래 경로에 파일이 바뀌고, VAR = string value이면 이 작업은 수작업으로 진행된다.
저 두 조건중 하나라도 만족하지 못하면 파이프 라인에 추가되지 않는다.
또한 if에 && ||를 사용해 더 복잡한 식을 만들 수 있다.

10.6 only/except(basic) 

  • only: 작업이 실행되는 분기, 태그의 이름을 정의
  • except: 작업이 실행되지 않는 분기, 태그의 이름 정의 사용되는 키워드
  • api: 파이프 라인 API 에 의해 트리거 된 파이프 라인의 경우 .
  • branches: 파이프 라인에 대한 Git 참조가 분기 인 경우.
  • chat: GitLab ChatOps 명령 을 사용하여 생성 된 파이프 라인의 경우 .
  • external: GitLab 이외의 CI 서비스를 사용하는 경우.
  • external_pull_requests: GitHub에서 외부 pull 요청이 생성되거나 업데이트 될 때 (외부 pull 요청에 대한 파이프 라인 참조 ).
  • merge_requests: 병합 요청이 생성되거나 업데이트 될 때 생성 된 파이프 라인의 경우. 
    병합 요청 파이프 라인 , 병합 된 결과 파이프 라인 및 병합 훈련을 활성화합니다 .
  • pipelines: 위해 멀티 프로젝트 파이프 라인 에 의해 생성 과 API 사용CI_JOB_TOKEN , 또는 trigger키워드를.
  • pushes: git push분기 및 태그를 포함 하여 이벤트 에 의해 트리거 된 파이프 라인의 경우.
  • schedules: 대한 계획 파이프 라인 .
  • tags: 파이프 라인에 대한 Git 참조가 태그 인 경우.
  • triggers: 트리거 토큰 을 사용하여 생성 된 파이프 라인의 경우 .
  • web: 프로젝트의 CI / CD> 파이프 라인 섹션 에서 GitLab UI의 파이프 라인 실행 버튼 을 사용하여 생성 된 파이프 라인의 경우 .

작업은 tag되어있는참조, trigger, schedules에서만 파이프라인 실행됨

작업은 issue- 로 시작하는 참조(태그, 브랜치)에서는 실행되지만, 나머지 브랜치들에서는 실행되지 않음.

only의 default는 only: [‘branches’, ‘tags’]이고 except의 default는 없다.
또한 only, except는 4개의 key를 사용할 수 있다.

  • refs : 태그, 브랜치 등의 참조
  • variables : 아래의 예시처럼 커밋 메시지를 통한 허가, denied
  • changes : 파일의 변화
  • kubernetes : 쿠버네티스의 여부

만약 only에서 두가지 이상의 키를 사용한다면 AND로 묶이게 된다.


master분기에서 실행되거나 schedules로 실행되어야 하고
variables가 매치가 되어야 하고, 쿠버네티스가 켜져있어야만 파이프라인이 실행된다.

반면 except는 or로 묶이게 된다.


마스터에서 실행되거나 README.md가 변하게 되면 파이프라인은 실행되지 않는다

11. needs

비 순차적 작업을 위해 사용된다.
단계 순서를 무시하고 다른 작업이 완료 될때까지 기다리지 않고 일부 작업을 실행할 수 있다.
여러 단계의 작업을 동시에 실행할 수 있다.

 

needs:
  - job:blah
//또는 이렇게도 작성 가능
  • lint : needs가 없기 때문에 다른 작업과 상관없이 즉시 작업에 들어간다
  • linux: linux:build가 완료 해야지 다음 linux 작업으로 들어간다 (mac작업과는 상관 없다)
  • mac: mac:build가 완료 해야 다음 mac작업으로 넘어간다 (linux 작업과는 상관 없다)
  • production: 모든 선행 작업을 완료해야 진행된다

needs의 최대 작업 수는 50개이다.

12. allow_failure

작업에 실패해도 나머지 pipeline에 영향을 주지 않기위해 사용 
default -> allow_failure:false

allow_failure: true로 설정하게되면 작업에 실패하더라도 경고만 표시하고 흐름은 계속 진행된다.


이 작업에서는 job1이 실패해도 다음 단계인 job3로 넘어가게 된다.

13. when

작업의 진행 여부를 구현하는데 사용된다.

  • on_success: 이전 단계 모든 작업이 성공할때 실행하거나 allow_failure:true 일때 실행
  • on_failure: 이전 단계의 작업이 하나 이상 실패한 경우 실행
  • always: 이전 단계의 상관 없이 작업 실행
  • manual: 작업을 수동으로 진행
  • delayed: 지정 기간동안 실행을 지연
  • never: 작업을 실행하지 않는다.
stages:
  - build
  - cleanup_build
  - test
  - deploy
  - cleanup

build_job:
  stage: build
  script:
    - make build

cleanup_build_job:
  stage: cleanup_build
  script:
    - cleanup build when failed
  when: on_failure

test_job:
  stage: test
  script:
    - make test

deploy_job:
  stage: deploy
  script:
    - make deploy
  when: manual

cleanup_job:
  stage: cleanup
  script:
    - cleanup after jobs
  when: always

cleanup_build_job은 build_job이 실패한 경우에 실행 cleanup_job은 항상 실행 deploy_job은 수동으로 실행할때 실

12.1 when:manual 

수동작업은 자동으로 실행되지 않고 사용자가 명시적으로 시작해야 하는 작업 유형이다. 배포와 같은 작업에 수동으로 사용할 수 있다.
수동작업은 기본적으로 allow_failure: true가 설정되며 전체 파이프 라인에 영향을 주지 않는다.
allow_failure: false를 추가하면 이 단계에서 작업이 중지되고 계속 실행하려면 수동작업에서 재생을 클릭해야 한다.

12.2 when:delayed 

대기시간 후 스크립트를 실행하기 위해 사용하며 start_in으로 대기 기간을 설정할 수 있다.
‘5’, 5 seconds, 30 minutes, 1 day, 1 week 등으로 설정할 수 있다.
작업이 지연되면 파이프라인은 지연된 작업이 완료될때까지 진행되지 않는다.

13. retry

작업을 재시도 하는 횟수 when과 같이 사용할 수 있다.


러너 시스템 오류 외 다른 이유로는 재시도 하지 않는다. 사용 가능한 when 값

  • always: 실패시 재 시도합니다 (기본값).
  • unknown_failure: 실패 이유를 알 수없는 경우 재 시도합니다.
  • script_failure: 스크립트가 실패하면 재 시도하십시오.
  • api_failure: API 실패시 재 시도합니다.
  • stuck_or_timeout_failure: 작업이 중단되거나 시간이 초과되면 다시 시도하십시오.
  • runner_system_failure: 실행기 시스템 오류가있는 경우 재 시도합니다 (예 : 작업 설정 실패).
  • missing_dependency_failure: 종속성이 누락 된 경우 재 시도하십시오.
  • runner_unsupported: 러너가 지원되지 않는 경우 다시 시도하십시오.
  • stale_schedule: 지연된 작업을 실행할 수없는 경우 재 시도합니다.
  • job_execution_timeout: 스크립트가 작업에 설정된 최대 실행 시간을 초과 한 경우 재 시도합니다.
  • archived_failure: 작업이 보관되어 실행할 수없는 경우 다시 시도합니다.
  • unmet_prerequisites: 작업이 필수 작업을 완료하지 못한 경우 다시 시도합니다.
  • scheduler_failure: 스케줄러가 실행자에게 작업을 할당하지 못한 경우 재 시도합니다.
  • data_integrity_failure: 구조적 무결성 문제가 감지 된 경우 다시 시도하십시오
저작자표시 비영리 변경금지