GitLab CI에서 연속 push할 때 선행 작업 중단

코드 베이스 & 개발 팀이 커지면 빌드에 걸리는 시간도 빌드가 시작될 때까지의 대기 시간도 점점 길어집니다. 돈을 쌓아 GitLab Runner를 증강해 버리면 가장 빠릅니다만, 이 문서에서는 맨손의 테크닉으로 빌드 큐에 조금이라도 여유를 만드는 방법을 소개합니다.

확인 환경

GitLab.com (12.7.0-pre 94b8fd8d152)

배경

다음과 같이 자동 테스트를 실행하는 test 스테이지와 배포를 실행하는 deploy 스테이지로 구성된 빌드 파이프라인을 구축한다고 가정합니다.

.gitlab-ci.yml

image: busybox:latest

stages:
  - test
  - deploy

frontend-test:
  stage: test
  script:
    - echo "frontend-test ..."
    - sleep 10

backend-test:
  stage: test
  script:
    - echo "backend-test ..."
    - sleep 10

deploy:
  stage: deploy
  script: "echo deploying..."

이 작업 브랜치를 GitLab으로 푸시하면 자동으로 빌드가 시작됩니다. 지금까지는 기대대로입니다만, 여기에서 수정 미스를 깨닫는 등, 아직 빌드가 끝나지 않은 상태에서 다시 코드를 push 한다고 합니다. 그러면 첫 번째 push에 대한 빌드와는 별도로 새로 빌드 파이프라인이 시작됩니다(아래 그림 참조).



일반적으로 정적 분석이나 자동 테스트는 최신 커밋에 대한 실행 결과만 있으면 충분한 경우가 많고, 연속적으로 push 하는 경우에는 선행 작업의 빌드를 계속하는 의미가 없습니다. 이를 위해 GitLab Runner 리소스를 다른 작업에 할당하는 것이 의미가 있습니다.

해결책

GitLab에는 일시 중단 가능한 작업을 지정하는 기능이 있으므로이를 사용합니다. 기본적으로 interruptible = false입니다.

.gitlab-ci.yml

image: busybox:latest

stages:
  - test
  - deploy

frontend-test:
  stage: test
  script:
    - echo "frontend-test ..."
    - sleep 10
+ interruptible: true

backend-test:
  stage: test
  script:
    - echo "backend-test ..."
    - sleep 10
+ interruptible: true

deploy:
  stage: deploy
  script: "echo deploying..."

interruptible = true 를 지정한 상태로 코드를 연속 push 하면(자), 아래 그림과 같이 선행하는 파이프라인의 작업이 자동적으로 중단되어 canceled 상태가 되는 것을 알 수 있습니다. 다만, 문서에도 기재가 있는 대로, 1개라도 interruptible = false인 작업의 실행이 개시되어 버리면(자), 그 파이프라인은 더 이상 중단할 수 없습니다.



덧붙여 선행 작업을 중단할지 어떨지는 브랜치 단위로 관리되므로, 아래 그림과 같이 다른 브랜치로 병행 push 해도 어느 쪽인가의 파이프 라인이 중단되는 것은 아닙니다.

참고

GitLab CI/CD Pipeline Configuration Reference | GitLab