프로젝트에서 파이프라인이 실행되는 방식을 사용자 지정할 수 있습니다.

파이프라인을 볼 수 있는 사용자 변경#

공개 및 내부 프로젝트에서는 다음을 볼 수 있는 사용자를 변경할 수 있습니다.

• 파이프라인
• 잡 출력 로그
• 잡 아티팩트

Project-based pipeline visibility 설정은 파이프라인 보안 보고서를 볼 수 있는 사용자를 변경하지 않습니다.

파이프라인 및 관련 기능의 가시성을 변경하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.

2. 왼쪽 사이드바에서 설정 > CI/CD를 선택합니다.

3. General pipelines를 확장합니다.

4. Project-based pipeline visibility 체크박스를 선택하거나 선택 해제합니다. 선택하면 파이프라인 및 관련 기능이 다음과 같이 표시됩니다.

   • Public 프로젝트의 경우 모든 사용자에게 표시됩니다.
   • Internal 프로젝트의 경우 외부 사용자를 제외한 모든 인증된 사용자에게 표시됩니다.
   • Private 프로젝트의 경우 모든 프로젝트 멤버(Guest 이상)에게 표시됩니다.

   선택 해제하면 다음과 같습니다.

   • Public 프로젝트의 경우 잡 로그, 잡 아티팩트, CI/CD 메뉴 항목이 프로젝트 멤버(Reporter 이상)에게만 표시됩니다. 게스트 사용자를 포함한 다른 사용자는 머지 리퀘스트나 커밋을 볼 때만 파이프라인과 잡의 상태를 볼 수 있습니다.
   • Internal 프로젝트의 경우 파이프라인 및 관련 기능이 프로젝트 멤버(Reporter 이상)에게만 표시됩니다. 외부 사용자를 제외한 다른 인증된 사용자는 머지 리퀘스트나 커밋을 볼 때만 파이프라인과 잡의 상태를 볼 수 있습니다.
   • Private 프로젝트의 경우 파이프라인 및 관련 기능은 프로젝트 멤버(Reporter 이상)에게만 표시됩니다.

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

공개 프로젝트에서 프로젝트에 속하지 않은 사용자에 대한 파이프라인 가시성을 제어할 수 있습니다.

이 설정은 다음의 경우 적용되지 않습니다.

• 프로젝트 가시성이 Internal 또는 Private로 설정된 경우, 프로젝트에 속하지 않은 사용자는 내부 또는 비공개 프로젝트에 액세스할 수 없기 때문입니다.
• Project-based pipeline visibility 설정이 비활성화된 경우.

프로젝트에 속하지 않은 사용자에 대한 파이프라인 가시성을 변경하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 설정 > General을 선택합니다.
3. Visibility, project features, permissions를 확장합니다.
4. CI/CD에 대해 다음 중 하나를 선택합니다.
   • Only project members: 프로젝트 멤버만 파이프라인을 볼 수 있습니다.
   • Everyone With Access: 프로젝트에 속하지 않은 사용자도 파이프라인을 볼 수 있습니다.
5. 변경 사항 저장을 선택합니다.

CI/CD 권한 테이블에는 Everyone With Access를 선택했을 때 프로젝트에 속하지 않은 사용자가 액세스할 수 있는 파이프라인 기능이 나와 있습니다.

중복 파이프라인 자동 취소#

동일한 브랜치에서 새 변경 사항에 대한 파이프라인이 실행될 때 대기 중이거나 실행 중인 파이프라인이 자동으로 취소되도록 설정할 수 있습니다. 이 기능은 프로젝트 설정에서 활성화할 수 있습니다.

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 설정 > CI/CD를 선택합니다.
3. General Pipelines를 확장합니다.
4. Auto-cancel redundant pipelines 체크박스를 선택합니다.
5. 변경 사항 저장을 선택합니다.

실행 중인 잡이 완료되기 전에 취소될 수 있는지 여부를 지정하려면 interruptible 키워드를 사용합니다. interruptible: false인 잡이 시작되면 그 시점부터 전체 파이프라인은 더 이상 중단 가능한 것으로 간주되지 않습니다.

머지 리퀘스트에 대한 브랜치 파이프라인 건너뛰기#

히스토리

• GitLab 19.2에서 베타로 도입되었습니다.
• GitLab 19.4에서 프로젝트 REST API에 추가되었습니다.

이 기능은 베타 상태입니다.

열린 머지 리퀘스트가 있는 브랜치에 푸시하면 GitLab은 기본적으로 브랜치 파이프라인과 머지 리퀘스트 파이프라인을 모두 생성하려고 시도합니다. 이로 인해 CI/CD 리소스가 낭비되고 어떤 파이프라인이 머지 준비 상태를 결정하는지 혼란이 생길 수 있습니다. 이 문제에 대한 자세한 내용은 중복 파이프라인 방지를 참조합니다.

열린 머지 리퀘스트가 있는 브랜치에 푸시할 때 머지 리퀘스트 파이프라인만 생성하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 설정 > CI/CD를 선택합니다.
3. General pipelines를 확장합니다.
4. Skip branch pipelines for merge requests 체크박스를 선택합니다.
5. 변경 사항 저장을 선택합니다.

이 설정을 활성화하면 다음과 같습니다.

• 머지 리퀘스트의 소스 브랜치인 브랜치에 git push할 때 GitLab은 브랜치 파이프라인을 생성하려고 시도하지 않습니다. GitLab은 머지 리퀘스트 파이프라인만 생성하려고 시도합니다.
• 해당 브랜치가 열려 있거나 이전에 닫힌 머지 리퀘스트의 소스 브랜치가 아닌 경우에는 GitLab이 브랜치 파이프라인을 생성하려고 시도합니다.
• 머지 리퀘스트를 생성하는 첫 번째 푸시에서는 머지 리퀘스트가 생성되기 전에 파이프라인이 시작되므로 브랜치 파이프라인이 계속 생성됩니다. 이후 푸시부터는 브랜치 파이프라인이 건너뛰어집니다.
• Pipelines must succeed와 같은 머지 가능 여부 검사는 머지 리퀘스트 파이프라인만 고려합니다. 브랜치 파이프라인은 머지 준비 상태에 영향을 주지 않습니다.
• 명시적인 rules, only, except 섹션이 없는 잡은 머지 리퀘스트 파이프라인에 자동으로 포함됩니다. 이러한 잡에 대해서는 암묵적인 only: [branches, tags] 기본값이 제거됩니다.
• 푸시로 트리거된 파이프라인만 영향을 받습니다. 수동, API, 예약, 트리거된 파이프라인을 비롯한 다른 모든 파이프라인 유형은 영향을 받지 않습니다.
• 파이프라인이나 잡을 브랜치 파이프라인으로만 실행되도록 구성한 경우 이 설정을 활성화하면 머지 리퀘스트에 대해 파이프라인이 실행되지 않을 수 있습니다.

오래된 배포 잡 방지#

프로젝트에 동일한 시간대에 실행되도록 예약된 여러 동시 배포 잡이 있을 수 있습니다.

이로 인해 이전 배포 잡이 더 최근 배포 잡보다 나중에 실행되는 상황이 발생할 수 있으며, 이는 의도한 동작이 아닐 수 있습니다.

이 상황을 방지하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 설정 > CI/CD를 선택합니다.
3. General pipelines를 확장합니다.
4. Prevent outdated deployment jobs 체크박스를 선택합니다.
5. 선택 사항. Allow job retries for rollback deployments 체크박스를 선택 해제합니다.
6. 변경 사항 저장을 선택합니다.

자세한 내용은 배포 안전성을 참조합니다.

파이프라인 또는 잡을 취소할 수 있는 권한 제한#

파이프라인 또는 잡을 취소할 권한이 있는 역할을 사용자 지정할 수 있습니다.

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

파이프라인 또는 잡을 취소할 수 있는 권한을 변경하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 설정 > CI/CD를 선택합니다.
3. General pipelines를 확장합니다.
4. Minimum role required to cancel a pipeline or job에서 옵션을 선택합니다.
5. 변경 사항 저장을 선택합니다.

커스텀 CI/CD 구성 파일 지정#

GitLab은 프로젝트의 루트 디렉터리에서 CI/CD 구성 파일(.gitlab-ci.yml)을 찾습니다. 그러나 프로젝트 외부 위치를 포함한 대체 파일 이름 경로를 지정할 수 있습니다.

경로를 사용자 지정하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 설정 > CI/CD를 선택합니다.
3. General pipelines를 확장합니다.
4. CI/CD configuration file 필드에 파일 이름을 입력합니다. 파일이:
   • 루트 디렉터리에 없다면 경로를 포함합니다.
   • 다른 프로젝트에 있다면 그룹 및 프로젝트 이름을 포함합니다.
   • 외부 사이트에 있다면 전체 URL을 입력합니다.
5. 변경 사항 저장을 선택합니다.

커스텀 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 전략 선택#

잡이 실행될 때 GitLab에서 저장소를 가져오는 방식을 선택할 수 있습니다.

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 설정 > CI/CD를 선택합니다.
3. General pipelines를 확장합니다.
4. Git strategy에서 옵션을 선택합니다.
   • git clone은 모든 잡마다 저장소를 처음부터 복제하기 때문에 더 느립니다. 그러나 로컬 작업 복사본이 항상 최신 상태로 유지됩니다.
   • git fetch는 로컬 작업 복사본을 재사용하기 때문에 더 빠릅니다(존재하지 않으면 복제로 대체됩니다). 특히 대규모 저장소에는 이 방식을 사용합니다.

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

클론 중에 가져오는 변경 사항 수 제한#

GitLab CI/CD가 저장소를 클론할 때 가져오는 변경 사항 수를 제한할 수 있습니다.

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 설정 > CI/CD를 선택합니다.
3. General pipelines를 확장합니다.
4. Git strategy 아래 Git shallow clone에 값을 입력합니다. 최댓값은 1000입니다. 얕은 클론을 비활성화하고 GitLab CI/CD가 매번 모든 브랜치와 태그를 가져오게 하려면 값을 비워 두거나 0으로 설정합니다.

새로 생성된 프로젝트의 기본 git depth 값은 20입니다.

이 값은 .gitlab-ci.yml 파일의 GIT_DEPTH 변수로 재정의할 수 있습니다.

잡 실행 제한 시간 설정#

잡이 제한 시간을 초과하기 전까지 실행될 수 있는 시간을 정의할 수 있습니다.

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 설정 > CI/CD를 선택합니다.
3. General pipelines를 확장합니다.
4. Timeout 필드에 분 단위 숫자나 2 hours와 같이 사람이 읽기 쉬운 값을 입력합니다. 10분 이상, 1개월 미만이어야 합니다. 기본값은 60분입니다. 대기 중인 잡은 24시간 동안 활동이 없으면 삭제됩니다.

제한 시간을 초과하는 잡은 실패로 표시됩니다.

프로젝트 제한 시간과 러너 제한 시간이 모두 설정된 경우 더 낮은 값이 우선합니다.

1시간 동안 출력이 없는 잡은 제한 시간과 관계없이 삭제됩니다. 이를 방지하려면 진행 상황을 계속 출력하는 스크립트를 추가합니다. 자세한 내용은 이슈 25359를 참조합니다.

파이프라인 배지#

파이프라인 배지를 사용하여 프로젝트의 파이프라인 상태와 테스트 커버리지를 나타낼 수 있습니다. 이 배지는 가장 최근에 성공한 파이프라인을 기준으로 결정됩니다.

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

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

GitLab CI/CD는 프로젝트별로 비활성화하거나 인스턴스의 모든 새 프로젝트에 대해 비활성화할 수 있습니다.

GitLab CI/CD를 비활성화하면 다음과 같습니다.

• 왼쪽 사이드바에서 CI/CD 항목이 제거됩니다.
• /pipelines 및 /jobs 페이지를 더 이상 사용할 수 없습니다.
• 기존 잡과 파이프라인은 삭제되지 않고 숨겨집니다.

프로젝트에서 GitLab CI/CD를 비활성화하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 설정 > General을 선택합니다.
3. Visibility, project features, permissions를 확장합니다.
4. Repository 섹션에서 CI/CD를 끕니다.
5. 변경 사항 저장을 선택합니다.

이 변경 사항은 외부 통합이 적용된 프로젝트에는 적용되지 않습니다.

자동 파이프라인 정리#

히스토리

• GitLab 17.7에서 ci_delete_old_pipelines라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.
• GitLab 17.9에서 기능 플래그 ci_delete_old_pipelines가 제거되었습니다.

보존 기간을 설정하면 파이프라인 저장소를 관리하고 시스템 성능을 개선하는 데 도움이 됩니다. 구성된 기간보다 오래된 파이프라인은 백그라운드 잡에 의해 자동으로 삭제됩니다. 정리는 파이프라인이 삭제 대상이 되는 즉시가 아니라 백그라운드에서 주기적으로 실행됩니다. 오래된 파이프라인이 많이 쌓인 프로젝트는 여러 번의 실행에 걸쳐 점진적으로 정리됩니다.

파이프라인이 삭제되면 해당 잡, 잡 로그, 아티팩트도 영구적으로 삭제됩니다. 구성된 보존 기간보다 오래된 모든 파이프라인은 상태나 특정 브랜치 또는 태그의 가장 최근 파이프라인인지 여부와 관계없이 삭제 대상이 됩니다.

사전 요구 사항:

• 프로젝트에 대한 Owner 권한.

자동 파이프라인 정리를 구성하려면:

1. 상단 바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 설정 > CI/CD를 선택합니다.
3. General pipelines를 확장합니다.
4. Automatic pipeline cleanup 필드에 2 weeks 또는 30 days와 같이 기간을 입력합니다. 값은 최소 하루 이상이어야 하며, 인스턴스 최댓값(기본값 1년) 이하여야 합니다. 파이프라인을 자동으로 삭제하지 않으려면 비워 둡니다.
5. 변경 사항 저장을 선택합니다.

GitLab Self-Managed의 경우 관리자가 자동 파이프라인 정리의 상한값을 높일 수 있습니다.