파이프라인 구성 커스터마이즈하기

파이프라인 구성 커스터마이즈하기

프로젝트의 파이프라인이 어떻게 실행되는지는 여러 가지로 조정할 수 있어요. 누가 파이프라인을 볼 수 있는지, 실행을 어떻게 제어할지, 설정 파일을 어디에 둘지 등을 프로젝트마다 바꿀 수 있습니다.

출처: 문서

본문

  • 티어(Tier): Free, Premium, Ultimate
  • 제공 방식(Offering): GitLab.com, GitLab Self-Managed, GitLab Dedicated

누가 파이프라인을 볼 수 있는지 변경하기

공개(public) 및 내부(internal) 프로젝트에서는 다음 항목을 볼 수 있는 사용자를 변경할 수 있어요:

파이프라인과 관련 기능의 가시성을 변경하는 방법:

  1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾아요.
  2. 왼쪽 사이드바에서 Settings > CI/CD를 선택해요.
  3. General pipelines를 펼쳐요.
  4. Project-based pipeline visibility 체크박스를 선택하거나 해제해요. 선택하면 파이프라인과 관련 기능이 다음 기준으로 보여요: - Public 프로젝트에서는 모두에게. - Internal 프로젝트에서는 외부 사용자를 제외한 모든 인증 사용자에게. - Private 프로젝트에서는 모든 프로젝트 멤버(Guest 이상)에게. 해제하면: - Public 프로젝트에서는 job 로그, job 아티팩트, 파이프라인 보안 대시보드, CI/CD 메뉴 항목이 프로젝트 멤버(Reporter 이상)에게만 보여요. 게스트 사용자 등 다른 사용자는 MR이나 커밋을 볼 때만 파이프라인과 job의 상태를 볼 수 있어요. - Internal 프로젝트에서는 파이프라인이 외부 사용자를 제외한 모든 인증 사용자에게 보여요. 관련 기능은 프로젝트 멤버(Reporter 이상)에게만 보입니다. - Private 프로젝트에서는 파이프라인과 관련 기능이 프로젝트 멤버(Reporter 이상)에게만 보여요.

공개 프로젝트에서 비프로젝트 멤버의 파이프라인 가시성 변경하기

공개 프로젝트에서 비프로젝트 멤버의 파이프라인 가시성을 제어할 수 있어요.

이 설정은 다음 경우에는 효과가 없어요:

비프로젝트 멤버의 파이프라인 가시성을 변경하는 방법:

  1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾아요.
  2. 왼쪽 사이드바에서 Settings > General을 선택해요.
  3. Visibility, project features, permissions를 펼쳐요.
  4. CI/CD에서 다음 중 하나를 선택해요: - Only project members: 프로젝트 멤버만 파이프라인을 볼 수 있음. - Everyone With Access: 비프로젝트 멤버도 파이프라인을 볼 수 있음.
  5. Save changes를 선택해요.

CI/CD 권한 표에는 Everyone With Access를 선택했을 때 비프로젝트 멤버가 접근할 수 있는 파이프라인 기능이 정리되어 있어요.

중복 파이프라인 자동 취소

같은 브랜치에 새 변경 사항이 있는 파이프라인이 실행될 때, 대기 중이거나 실행 중인 파이프라인을 자동으로 취소하도록 설정할 수 있어요. 프로젝트 설정에서 활성화할 수 있습니다:

  1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾아요.
  2. 왼쪽 사이드바에서 Settings > CI/CD를 선택해요.
  3. General Pipelines를 펼쳐요.
  4. Auto-cancel redundant pipelines 체크박스를 선택해요.
  5. Save changes를 선택해요.

실행 중인 job이 완료되기 전에 취소될 수 있는지 표시하려면 interruptible 키워드를 사용하세요. interruptible: false인 job이 시작된 후에는 전체 파이프라인이 더 이상 인터럽트 가능한 것으로 간주되지 않습니다.

MR에 대한 브랜치 파이프라인 건너뛰기

  • 상태(Status): Beta

변경 이력

이 기능은 베타 단계예요.

열린 MR이 있는 브랜치에 push하면 GitLab은 기본적으로 브랜치 파이프라인과 MR 파이프라인을 모두 만들려고 해요. 이는 CI/CD 리소스를 낭비하고, 어떤 파이프라인이 머지 준비 상태를 결정하는지 헷갈리게 만들 수 있습니다. 이 문제에 대한 자세한 내용은 중복 파이프라인 피하기를 참고하세요.

열린 MR이 있는 브랜치에 push할 때 MR 파이프라인만 만들려면:

  1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾아요.
  2. 왼쪽 사이드바에서 Settings > CI/CD를 선택해요.
  3. General pipelines를 펼쳐요.
  4. Skip branch pipelines for merge requests 체크박스를 선택해요.
  5. Save changes를 선택해요.

이 설정을 켜면:

  • MR의 소스 브랜치인 브랜치에 git push할 때 GitLab은 브랜치 파이프라인을 만들려고 하지 않아요. MR 파이프라인만 만들려고 합니다.
  • 브랜치가 열려 있거나 이전에 닫힌 MR의 소스 브랜치가 아니라면, GitLab은 브랜치 파이프라인을 만들려고 해요.
  • MR을 만드는 첫 push에서는 브랜치 파이프라인이 여전히 생성돼요 — 파이프라인이 MR 생성 전에 시작되니까요. 다음 push부터는 브랜치 파이프라인이 건너뛰어집니다.
  • Pipelines must succeed 같은 머지 가능성 검사는 MR 파이프라인만 고려해요. 브랜치 파이프라인은 머지 준비 상태에 영향을 주지 않습니다.
  • 명시적인 rules, only, except 섹션이 없는 job은 MR 파이프라인에 자동으로 포함돼요. 이 job들에는 암시적 only: [branches, tags] 기본값이 제거됩니다.
  • push로 트리거된 파이프라인만 영향을 받아요. 수동, API, 예약, 트리거 파이프라인 등 다른 모든 파이프라인 유형은 영향을 받지 않습니다.
  • 파이프라인이나 job을 브랜치 파이프라인에서만 실행하도록 구성했다면, 이 설정을 켜면 MR에 대해 파이프라인이 전혀 실행되지 않을 수 있어요.

오래된 배포 job 방지하기

프로젝트에 같은 시간대에 실행되도록 예약된 동시 배포 job이 여러 개 있을 수 있어요.

이런 경우 더 오래된 배포 job이 더 새로운 job보다 나중에 실행되는 상황이 생길 수 있는데, 원하는 결과가 아닐 수 있죠.

이 시나리오를 피하려면:

  1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾아요.
  2. 왼쪽 사이드바에서 Settings > CI/CD를 선택해요.
  3. General pipelines를 펼쳐요.
  4. Prevent outdated deployment jobs 체크박스를 선택해요.
  5. 선택 사항. Allow job retries for rollback deployments 체크박스를 해제해요.
  6. Save changes를 선택해요.

자세한 내용은 배포 안전 문서를 참고하세요.

파이프라인이나 job을 취소할 수 있는 역할 제한하기

  • 티어(Tier): Premium, Ultimate
  • 제공 방식(Offering): GitLab.com, GitLab Self-Managed, GitLab Dedicated

파이프라인이나 job을 취소할 권한이 있는 역할을 커스터마이즈할 수 있어요.

기본적으로 Developer, Maintainer, Owner 역할의 사용자가 파이프라인이나 job을 취소할 수 있어요. 취소 권한을 Maintainer나 Owner 역할의 사용자로만 제한하거나, 파이프라인이나 job 취소를 완전히 막을 수도 있습니다.

파이프라인이나 job 취소 권한을 변경하는 방법:

  1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾아요.
  2. 왼쪽 사이드바에서 Settings > CI/CD를 선택해요.
  3. General pipelines를 펼쳐요.
  4. Minimum role required to cancel a pipeline or job에서 옵션을 선택해요.
  5. Save changes를 선택해요.

사용자 지정 CI/CD 구성 파일 지정하기

GitLab은 CI/CD 구성 파일(.gitlab-ci.yml)이 프로젝트 루트 디렉터리에 있을 것으로 기대해요. 하지만 프로젝트 외부 위치를 포함한 다른 파일명 경로를 지정할 수 있습니다.

경로를 커스터마이즈하려면:

  1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾아요.
  2. 왼쪽 사이드바에서 Settings > CI/CD를 선택해요.
  3. General pipelines를 펼쳐요.
  4. CI/CD configuration file 필드에 파일명을 입력해요. 파일이: - 루트 디렉터리에 없다면 경로를 포함하세요. - 다른 프로젝트에 있다면 그룹과 프로젝트 이름을 포함하세요. - 외부 사이트에 있다면 전체 URL을 입력하세요.
  5. Save changes를 선택해요.

다른 프로젝트나 외부 사이트의 CI/CD 구성 파일은 프로젝트의 파이프라인 편집기로 편집할 수 없어요.

사용자 지정 CI/CD 구성 파일 예시

CI/CD 구성 파일이 루트 디렉터리에 없으면 경로는 루트 기준 상대 경로여야 해요. 예를 들어:

  • my/path/.gitlab-ci.yml
  • my/path/.my-custom-file.yml

CI/CD 구성 파일이 외부 사이트에 있으면 URL이 .yml로 끝나야 해요:

  • http://example.com/generate/ci/config.yml

CI/CD 구성 파일이 다른 프로젝트에 있으면:

  • 파일이 그 기본 브랜치에 존재해야 하거나, refname으로 브랜치를 지정해야 해요.
  • 경로는 다른 프로젝트의 루트 디렉터리 기준 상대 경로여야 해요.
  • 경로 뒤에 @ 기호와 전체 그룹·프로젝트 경로가 따라와야 해요.

예를 들어:

  • .gitlab-ci.yml@namespace/another-project
  • my/path/.my-custom-file.yml@namespace/subgroup/another-project
  • my/path/.my-custom-file.yml@namespace/subgroup1/subgroup2/another-project:refname

구성 파일이 별도 프로젝트에 있다면 더 세밀한 권한을 설정할 수 있어요. 예를 들어:

  • 구성 파일을 호스팅하는 공개 프로젝트를 만들어요.
  • 파일을 편집할 수 있는 사용자에게만 프로젝트에 쓰기 권한을 주세요.

그러면 다른 사용자와 프로젝트는 구성 파일에 접근할 수 있지만 편집할 수는 없어요.

기본 Git 전략 선택하기

job이 실행될 때 GitLab에서 리포지토리를 가져오는 방식을 선택할 수 있어요.

  1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾아요.
  2. 왼쪽 사이드바에서 Settings > CI/CD를 선택해요.
  3. General pipelines를 펼쳐요.
  4. Git strategy 아래에서 옵션을 선택해요: - git clone은 매 job마다 리포지토리를 처음부터 복제하므로 더 느려요. 하지만 로컬 작업 복사본은 항상 깨끗합니다. - git fetch는 로컬 작업 복사본을 재사용하므로 더 빨라요(없으면 clone으로 대체). 특히 대형 리포지토리에서 이 명령을 사용하세요.

구성된 Git 전략은 .gitlab-ci.yml 파일의 GIT_STRATEGY 변수로 재정의할 수 있어요.

clone 중 가져올 변경 수 제한하기

GitLab CI/CD가 리포지토리를 clone할 때 가져오는 변경 수를 제한할 수 있어요.

  1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾아요.
  2. 왼쪽 사이드바에서 Settings > CI/CD를 선택해요.
  3. General pipelines를 펼쳐요.
  4. Git strategy 아래, Git shallow clone에 값을 입력해요. 최대값은 1000이에요. shallow clone을 비활성화하고 GitLab CI/CD가 매번 모든 브랜치와 태그를 가져오게 하려면 값을 비워 두거나 0으로 설정하세요.

새로 만든 프로젝트의 기본 git depth 값은 20이에요.

이 값은 .gitlab-ci.yml 파일의 GIT_DEPTH 변수로 재정의할 수 있어요.

job이 실행될 수 있는 시간 제한 설정하기

job이 타임아웃되기 전에 실행될 수 있는 시간을 정의할 수 있어요.

  1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾아요.
  2. 왼쪽 사이드바에서 Settings > CI/CD를 선택해요.
  3. General pipelines를 펼쳐요.
  4. Timeout 필드에 분 단위 숫자나 2 hours 같은 사람이 읽을 수 있는 값을 입력해요. 10분 이상, 1개월 미만이어야 해요. 기본값은 60분이에요. 24시간 동안 활동이 없으면 대기 중인 job은 드롭됩니다.

타임아웃을 초과한 job은 실패로 표시돼요.

프로젝트 타임아웃과 러너 타임아웃이 모두 설정되면 더 작은 값이 우선해요.

타임아웃과 무관하게 1시간 동안 출력이 없는 job은 드롭돼요. 이를 막으려면 진행 상황을 계속 출력하는 스크립트를 추가하세요. 자세한 내용은 issue 25359를 참고하세요.

파이프라인 배지

파이프라인 배지로 프로젝트의 파이프라인 상태와 테스트 커버리지를 표시할 수 있어요. 이 배지는 가장 최근의 성공한 파이프라인에 의해 결정됩니다.

GitLab CI/CD 파이프라인 비활성화

GitLab CI/CD 파이프라인은 모든 새 프로젝트에서 기본적으로 활성화되어 있어요. Jenkins나 Drone CI 같은 외부 CI/CD 서버를 사용한다면, commits status API와의 충돌을 피하려고 GitLab CI/CD를 비활성화할 수 있습니다.

GitLab CI/CD는 프로젝트별로 또는 인스턴스의 모든 새 프로젝트에 대해 비활성화할 수 있어요.

GitLab CI/CD를 비활성화하면:

  • 왼쪽 사이드바의 CI/CD 항목이 제거돼요.
  • /pipelines와 /jobs 페이지를 더 이상 사용할 수 없어요.
  • 기존 job과 파이프라인은 숨겨지지 제거되지는 않아요.

프로젝트에서 GitLab CI/CD를 비활성화하는 방법:

  1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾아요.
  2. 왼쪽 사이드바에서 Settings > General을 선택해요.
  3. Visibility, project features, permissions를 펼쳐요.
  4. Repository 섹션에서 CI/CD를 꺼요.
  5. Save changes를 선택해요.

이 변경은 외부 통합에 있는 프로젝트에는 적용되지 않아요.

자동 파이프라인 정리

  • 티어(Tier): Free, Premium, Ultimate
  • 제공 방식(Offering): GitLab.com, GitLab Self-Managed, GitLab Dedicated

변경 이력

파이프라인 스토리지를 관리하고 시스템 성능을 개선하려면 보존 기간을 설정하세요. 구성된 기간보다 오래된 파이프라인은 백그라운드 job이 자동으로 삭제해요. 정리는 파이프라인이 자격을 갖추자마자 즉시 되는 게 아니라 백그라운드에서 주기적으로 실행됩니다. 오래된 파이프라인이 많은 프로젝트는 여러 번의 실행에 걸쳐 점진적으로 정리돼요.

파이프라인이 삭제되면 그 job, job 로그, 아티팩트도 영구적으로 삭제돼요. 구성된 보존 기간보다 오래된 모든 파이프라인은 상태나 브랜치·태그의 최신 파이프라인인지와 무관하게 삭제 대상이 됩니다.

전제 조건:

  • 프로젝트의 Owner 역할.

자동 파이프라인 정리를 구성하는 방법:

  1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾아요.
  2. 왼쪽 사이드바에서 Settings > CI/CD를 선택해요.
  3. General pipelines를 펼쳐요.
  4. Automatic pipeline cleanup 필드에 2 weeks나 30 days 같은 기간을 입력해요. 값은 최소 하루, 최대 인스턴스 최댓값(기본 1년)이어야 해요. 비워 두면 파이프라인이 자동으로 삭제되지 않습니다.
  5. Save changes를 선택해요.

GitLab Self-Managed에서 관리자는 자동 파이프라인 정리의 상한을 늘릴 수 있어요.

더 알아보기 (Learn more)