CI/CD 관련 인스턴스 제한 중 다수는 Admin 영역에서 관리할 수 있습니다. 나머지 제한은 GitLab Rails 콘솔로 인스턴스 구성을 수정해야만 변경할 수 있습니다.

GitLab.com은 GitLab Self-Managed의 기본값과 다른 값을 사용할 수 있습니다. GitLab.com의 CI/CD 제한 및 설정을 확인합니다.

인스턴스 CI/CD 변수 제한#

히스토리

• GitLab 17.1에서 도입되었습니다.

인스턴스 설정에서 정의할 수 있는 CI/CD 변수의 개수에는 제한이 있습니다. 이 제한은 새 변수를 만들 때마다 확인됩니다. 새 변수로 인해 변수 총개수가 제한을 초과하게 되면 새 변수는 생성되지 않습니다.

이 제한을 구성하려면 다음을 수행합니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > CI/CD를 선택합니다.
3. Continuous Integration and Deployment를 확장합니다.
4. CI/CD limits에서 Maximum number of Instance-level CI/CD variables that can be defined의 값을 설정합니다. 기본값은 25입니다.
5. Save changes를 선택합니다.

dotenv 파일 크기 제한#

히스토리

• GitLab 17.1에서 도입되었습니다.

dotenv 아티팩트의 최대 크기에 제한을 설정할 수 있습니다. 이 제한은 dotenv 파일이 아티팩트로 내보내질 때마다 확인됩니다.

이 제한을 구성하려면 다음을 수행합니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > CI/CD를 선택합니다.
3. Continuous Integration and Deployment를 확장합니다.
4. CI/CD limits에서 Maximum size of a dotenv artifact in bytes의 값을 설정합니다.
5. Save changes를 선택합니다.

제한을 0으로 설정하면 비활성화됩니다. 기본값은 5 KB입니다.

dotenv 변수 제한#

히스토리

• GitLab 17.1에서 도입되었습니다.

dotenv 아티팩트 안에 들어가는 변수의 최대 개수에 제한을 설정할 수 있습니다. 이 제한은 dotenv 파일이 아티팩트로 내보내질 때마다 확인됩니다.

이 제한을 구성하려면 다음을 수행합니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > CI/CD를 선택합니다.
3. Continuous Integration and Deployment를 확장합니다.
4. CI/CD limits에서 Maximum number of variables in a dotenv artifact의 값을 설정합니다.
5. Save changes를 선택합니다.

제한을 0으로 설정하면 비활성화됩니다. 기본값은 20입니다.

Plan limits API로도 이 제한을 설정할 수 있습니다.

CycloneDX 아티팩트 크기 제한#

히스토리

• GitLab 19.3에서 도입되었습니다.

CycloneDX SBOM 아티팩트의 최대 크기에 제한을 설정할 수 있습니다. 이 제한은 CycloneDX 리포트가 아티팩트로 업로드될 때마다 확인됩니다.

이 제한을 구성하려면 다음을 수행합니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > CI/CD를 선택합니다.
3. Continuous Integration and Deployment를 확장합니다.
4. CI/CD limits에서 Maximum size of a CycloneDX artifact in MB의 값을 설정합니다.
5. Save changes를 선택합니다.

제한을 0으로 설정하면 대신 최대 아티팩트 크기가 적용됩니다. 기본값은 1 MB입니다.

파이프라인의 최대 job 수#

히스토리

• 17.6에서 설정이 GitLab Enterprise Edition에서 GitLab Community Edition으로 이동되었습니다.

파이프라인의 최대 job 수를 제한할 수 있습니다. 파이프라인의 job 수는 파이프라인 생성 시점과 새 커밋 상태가 생성될 때 확인됩니다. job이 너무 많은 파이프라인은 size_limit_exceeded 오류와 함께 실패합니다.

이 제한을 구성하려면 다음을 수행합니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > CI/CD를 선택합니다.
3. Continuous Integration and Deployment를 확장합니다.
4. CI/CD limits에서 Maximum number of jobs in a single pipeline의 값을 설정합니다.
5. Save changes를 선택합니다.

제한을 0으로 설정하면 비활성화됩니다. 기본적으로 비활성화되어 있습니다.

활성 파이프라인의 job 수#

활성 파이프라인의 총 job 수는 프로젝트별로 제한할 수 있습니다. 이 제한은 새 파이프라인이 생성될 때마다 확인됩니다. 활성 파이프라인은 다음 상태 중 하나에 있는 파이프라인입니다:

• created
• pending
• running

새 파이프라인으로 인해 총 job 수가 제한을 초과하게 되면 해당 파이프라인은 job_activity_limit_exceeded 오류와 함께 실패합니다.

이 제한을 구성하려면 다음을 수행합니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > CI/CD를 선택합니다.
3. Continuous Integration and Deployment를 확장합니다.
4. CI/CD limits에서 Total number of jobs in currently active pipelines의 값을 설정합니다.
5. Save changes를 선택합니다.

제한을 0으로 설정하면 비활성화됩니다. 기본적으로 비활성화되어 있습니다.

프로젝트에 대한 CI/CD 구독 수#

총 구독 수는 프로젝트별로 제한할 수 있습니다. 이 제한은 새 구독이 생성될 때마다 확인됩니다.

새 구독으로 인해 총 구독 수가 제한을 초과하게 되면 해당 구독은 유효하지 않은 것으로 간주됩니다.

이 제한을 구성하려면 다음을 수행합니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > CI/CD를 선택합니다.
3. Continuous Integration and Deployment를 확장합니다.
4. CI/CD limits에서 Maximum number of pipeline subscriptions to and from a project의 값을 설정합니다.
5. Save changes를 선택합니다.

기본적으로 구독은 2개로 제한됩니다. 제한을 0으로 설정하면 비활성화됩니다.

파이프라인 스케줄 수#

총 파이프라인 스케줄 수는 프로젝트별로 제한할 수 있습니다. 이 제한은 새 파이프라인 스케줄이 생성될 때마다 확인됩니다. 새 파이프라인 스케줄로 인해 총 파이프라인 스케줄 수가 제한을 초과하게 되면 해당 파이프라인 스케줄은 생성되지 않습니다.

이 제한을 구성하려면 다음을 수행합니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > CI/CD를 선택합니다.
3. Continuous Integration and Deployment를 확장합니다.
4. CI/CD limits에서 Maximum number of pipeline schedules의 값을 설정합니다.
5. Save changes를 선택합니다.

기본적으로 파이프라인 스케줄은 10개로 제한됩니다.

Plan Limits API를 사용할 수도 있습니다.

최대 needs 의존성 수#

단일 job이 가질 수 있는 needs 의존성의 최대 개수를 설정할 수 있습니다.

이 제한을 구성하려면 다음을 수행합니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > CI/CD를 선택합니다.
3. Continuous Integration and Deployment를 확장합니다.
4. CI/CD limits에서 Maximum number of needs dependencies that a job can have의 값을 설정합니다
5. Save changes를 선택합니다.

이 제한은 비활성화할 수 없습니다. 기본값은 50입니다.

0으로 설정하면 모든 needs 의존성이 차단됩니다. 그러면 needs를 사용하도록 구성된 job이 있는 파이프라인은 job can only need 0 others 오류를 반환합니다.

그룹 및 프로젝트에 등록된 러너 수#

히스토리

• GitLab 17.1에서 러너가 오래된 것으로 처리되는 타임아웃이 3개월에서 7일로 변경되었습니다.

등록된 러너의 총개수는 그룹과 프로젝트에 대해 제한됩니다. 새 러너가 등록될 때마다 GitLab은 지난 7일 동안 생성되었거나 활성 상태였던 러너를 기준으로 이 제한을 확인합니다. 러너 등록 토큰으로 결정되는 범위의 제한을 초과하면 러너 등록이 실패합니다.

이 제한을 구성하려면 다음을 수행합니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > CI/CD를 선택합니다.
3. Continuous Integration and Deployment를 확장합니다.
4. CI/CD limits에서 다음 중 하나의 값을 설정합니다:
   • Maximum number of runners created or active in a group during the past seven days
   • Maximum number of runners created or active in a project during the past seven days
5. Save changes를 선택합니다.

제한을 0으로 설정하면 비활성화됩니다.

파이프라인 계층 크기 제한#

기본적으로 파이프라인 계층에는 최대 1000개의 다운스트림 파이프라인을 포함할 수 있습니다. 이 제한을 초과하면 파이프라인 생성이 downstream pipeline tree is too large 오류와 함께 실패합니다.

이 제한을 구성하려면 다음을 수행합니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > CI/CD를 선택합니다.
3. Continuous Integration and Deployment를 확장합니다.
4. CI/CD limits에서 Maximum number of downstream pipelines in a pipeline's hierarchy tree의 값을 설정합니다.
5. Save changes를 선택합니다.

Plan Limits API를 사용할 수도 있습니다.

머지 트레인 병렬 파이프라인 제한#

히스토리

• GitLab 19.0에서 도입되었습니다.

기본적으로 각 머지 트레인은 최대 20개의 파이프라인을 병렬로 실행할 수 있습니다. 이 제한에 도달하면 파이프라인 슬롯이 확보될 때까지 추가 머지 리퀘스트가 큐에 대기합니다.

이 제한을 구성하려면 다음을 수행합니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > CI/CD를 선택합니다.
3. Continuous Integration and Deployment를 확장합니다.
4. CI/CD limits에서 Maximum parallel pipelines per merge train의 값을 설정합니다. 최솟값은 1입니다. 1로 설정하면 병렬 처리 없이 머지 리퀘스트를 순차적으로 처리합니다.
5. Save changes를 선택합니다.

Plan Limits API를 사용할 수도 있습니다.

특정 프로젝트에는 다른 값을 설정할 수 있습니다.

job의 최대 실행 시간#

job의 기본 최대 실행 시간은 60분입니다. 60분을 넘겨 실행되는 job은 타임아웃됩니다.

job이 타임아웃되기 전까지 실행될 수 있는 최대 시간은 변경할 수 있습니다:

• 프로젝트 단위로는 해당 프로젝트의 프로젝트 CI/CD 설정에서 설정합니다. 이 제한은 10분에서 1개월 사이여야 합니다.
• 러너 단위로 설정합니다. 이 제한은 10분 이상이어야 합니다.

구성된 타임아웃 제한과 관계없이, GitLab은 60분 동안 비활성 상태였던 job을 모두 종료합니다. 비활성 job은 새 로그나 trace 갱신을 생성하지 않은 job입니다.

Git 푸시당 파이프라인 수#

히스토리

• GitLab 18.0에서 도입되었습니다.

여러 태그나 브랜치처럼 하나의 Git 푸시로 여러 변경 사항을 푸시할 때는 기본적으로 태그 또는 브랜치 파이프라인이 네 개까지만 트리거될 수 있습니다. 이 제한은 git push --all이나 git push --mirror를 사용할 때 많은 수의 파이프라인이 실수로 생성되는 것을 방지합니다.

머지 리퀘스트 파이프라인에도 제한이 적용됩니다. Git 푸시가 여러 머지 리퀘스트를 동시에 갱신하면, 제한에 도달하기 전까지 갱신된 머지 리퀘스트마다 머지 리퀘스트 파이프라인이 트리거될 수 있습니다.

GitLab Self-Managed와 GitLab.com의 기본값은 4입니다.

GitLab Self-Managed 인스턴스에서 이 제한을 변경하려면 다음을 수행합니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > CI/CD를 선택합니다.
3. Continuous Integration and Deployment를 확장합니다.
4. Pipeline limit per Git push의 값을 변경합니다.
5. Save changes를 선택합니다.

파이프라인 생성 속도 제한#

히스토리

• GitLab 15.0에서 ci_enforce_throttle_pipelines_creation이라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다. GitLab.com에서는 활성화되어 있습니다
• 18.3에서 기본적으로 활성화되었습니다.
• GitLab 19.2에서 CI Lint 속도 제한이 ci_enforce_ci_lint_rate_limit이라는 기능 플래그와 함께 도입되었습니다. 기본적으로 비활성화되어 있습니다.

사용자와 프로세스가 분당 일정 개수를 넘는 파이프라인을 요청할 수 없도록 제한을 설정할 수 있습니다. 이러한 제한은 리소스를 절약하고 안정성을 높이는 데 도움이 됩니다. 각 제한은 1분 후에 초기화됩니다.

이 절에서 GitLab이 적용하는 속도 제한은 다음과 같습니다:

• 프로젝트, 커밋, 사용자 단위: 프로젝트, 커밋 SHA, 사용자의 같은 조합으로 생성되는 파이프라인을 제한합니다. 기본값은 0(제한 없음)입니다.
• 사용자 단위: 한 사용자가 모든 프로젝트에서 생성한 총 파이프라인을 제한합니다. 기본값은 0(제한 없음)입니다.
• CI lint 요청의 사용자 단위: 한 사용자가 모든 프로젝트에서 보낸 CI lint 요청을 제한합니다. CI lint 요청은 파이프라인 생성 요청과 유사합니다.

새로 설치한 경우 ci_lint_limit_per_user는 0(제한 없음)으로 설정됩니다. GitLab 19.2로 업그레이드한 인스턴스에서 pipeline_limit_per_user가 이미 0보다 큰 값으로 설정되어 있으면, ci_lint_limit_per_user도 같은 값으로 초기화됩니다.

예를 들어 사용자별 제한을 100으로 설정했고 한 사용자가 1분 안에 여러 프로젝트에 걸쳐 트리거 API로 파이프라인 생성 요청을 101건 보내면, 101번째 요청이 차단됩니다. 엔드포인트 접근은 1분 후에 다시 허용됩니다.

이 제한은 IP 주소별로 적용되지 않습니다.

제한을 초과하는 요청은 application_json.log 파일에 기록됩니다.

파이프라인 요청 제한 설정#

사전 요구 사항:

• 관리자 액세스 권한이 있어야 합니다.

파이프라인 요청 수를 제한하려면 다음을 수행합니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > Network를 선택합니다.
3. Pipeline creation rate limits를 확장합니다.
   • Max requests per minute per project, user, and commit에서 같은 프로젝트, 커밋, 사용자 조합의 파이프라인을 제한하려면 0보다 큰 값을 입력합니다. 분당 요청을 무제한으로 두려면 0으로 설정합니다.
   • Max requests per minute per user에서 각 사용자가 생성하는 총 파이프라인을 제한하려면 0보다 큰 값을 입력합니다. 분당 요청을 무제한으로 두려면 0으로 설정합니다.
   • Maximum number of CI Lint requests for a user에서 각 사용자가 보내는 CI lint 요청을 제한하려면 0보다 큰 값을 입력합니다. 분당 요청을 무제한으로 두려면 0으로 설정합니다.
4. Save changes를 선택합니다.

속도 제한은 각각 독립적으로 평가됩니다:

• 한 프로젝트에서 같은 커밋 SHA에 대해 파이프라인을 여러 개 생성하는 사용자는 프로젝트, 사용자, 커밋 단위 제한의 적용을 받습니다.
• 서로 다른 프로젝트나 커밋에 걸쳐 파이프라인을 생성하는 사용자는 사용자 단위 제한의 적용을 받습니다.
• 여러 프로젝트에 걸쳐 CI lint 요청을 보내는 사용자는 CI lint 요청의 사용자 단위 제한의 적용을 받습니다.
• 제한을 초과하면 요청이 차단됩니다.

다운스트림 파이프라인 트리거 속도 제한#

하나의 소스에서 분당 트리거할 수 있는 다운스트림 파이프라인 개수를 제한합니다.

최대 다운스트림 파이프라인 트리거 속도는 특정 프로젝트, 사용자, 커밋 조합에 대해 분당 트리거할 수 있는 다운스트림 파이프라인 개수를 제한합니다. 기본값은 0이며, 이는 제한이 없다는 뜻입니다.

이 제한을 구성하려면 다음을 수행합니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > CI/CD를 선택합니다.
3. Continuous Integration and Deployment를 확장합니다.
4. Maximum downstream pipeline trigger rate의 값을 설정합니다.
5. Save changes를 선택합니다.

최대 아티팩트 크기#

스토리지 사용량을 제어하기 위해 job 아티팩트의 크기 제한을 설정합니다. job의 각 아티팩트 파일은 기본 최대 크기가 100 MB입니다.

artifacts:reports로 정의한 job 아티팩트에는 다른 제한이 적용될 수 있습니다. 서로 다른 제한이 적용되는 경우에는 더 작은 값이 사용됩니다.

아티팩트 크기 제한은 다음 수준에서 구성할 수 있습니다:

• 인스턴스: 모든 프로젝트와 그룹에 적용되는 기본 설정입니다.
• 그룹: 그룹 내 모든 프로젝트에 대해 인스턴스 설정을 재정의합니다.
• 프로젝트: 특정 프로젝트에 대해 인스턴스 설정과 그룹 설정을 모두 재정의합니다.

GitLab.com의 제한은 아티팩트 최대 크기를 참고합니다.

인스턴스의 최대 아티팩트 크기를 변경하려면 다음을 수행합니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > CI/CD를 선택합니다.
3. Continuous Integration and Deployment를 확장합니다.
4. Maximum artifacts size (MB) 텍스트 박스에 값을 입력합니다.
5. Save changes를 선택합니다.

최대 include 수#

파이프라인이 include 키워드로 포함할 수 있는 외부 YAML 파일 개수를 제한합니다. 이 제한은 파이프라인이 너무 많은 파일을 포함할 때 발생하는 성능 문제를 방지합니다.

기본적으로 파이프라인은 최대 150개 파일을 포함할 수 있습니다. 파이프라인이 이 제한을 초과하면 오류와 함께 실패합니다.

파이프라인당 포함할 수 있는 최대 파일 수를 설정하려면 다음을 수행합니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > CI/CD를 선택합니다.
3. Continuous Integration and Deployment를 확장합니다.
4. Maximum includes 텍스트 박스에 값을 입력합니다.
5. Save changes를 선택합니다.

CI 아티팩트 아카이브의 최대 크기#

이 설정은 동적 하위 파이프라인의 YAML 크기를 제한합니다.

CI 아티팩트 아카이브의 기본 최대 크기는 5메가바이트입니다.

Admin 영역에서 이 제한을 변경하려면 다음을 수행합니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > CI/CD를 선택합니다.
3. Continuous Integration and Deployment를 확장합니다.
4. Maximum artifact size for dynamic child pipelines (bytes) 텍스트 박스에 값을 입력합니다.
5. Save changes를 선택합니다.

GitLab Rails 콘솔로 이 제한을 변경하려면 max_artifacts_content_include_size를 새 값으로 갱신합니다. 예를 들어 20 MB로 설정하려면 다음과 같이 실행합니다:

ApplicationSetting.update(max_artifacts_content_include_size: 20.megabytes)

job당 최대 캐시 수#

히스토리

• GitLab 18.10.8, 18.11.5, 19.0.2, 19.1에서 베타로 도입되었습니다.
• GitLab 19.2에서 일반 공개되었습니다.

단일 CI/CD job이 정의할 수 있는 cache 항목 수를 제한합니다. 이 제한은 캐시가 cache:key:files를 사용할 때 파이프라인 생성 중 job이 트리거할 수 있는 Gitaly 호출 수의 상한을 정합니다.

기본적으로 job은 최대 4개의 캐시를 정의할 수 있습니다. job이 이 제한을 초과하면 구성 파싱이 오류와 함께 실패합니다.

값은 최소 1이어야 합니다. 제한을 기본값보다 높이면 파이프라인 생성 성능에 영향을 줄 수 있습니다.

job당 최대 캐시 수를 변경하려면 다음을 수행합니다.

1. 오른쪽 상단에서 Admin을 선택합니다.
2. 왼쪽 사이드바에서 Settings > CI/CD를 선택합니다.
3. Continuous Integration and Deployment를 확장합니다.
4. Maximum caches per job 텍스트 박스에 값을 입력합니다.
5. Save changes를 선택합니다.

CI/CD 제한 인스턴스 구성#

일부 CI/CD 제한은 인스턴스 구성을 편집해야만 변경할 수 있습니다.

사전 요구 사항:

• 해당 인스턴스의 GitLab Rails 콘솔에 접근할 수 있어야 합니다.

파이프라인의 최대 배포 job 수#

파이프라인의 최대 배포 job 수를 제한할 수 있습니다. 배포는 environment가 지정된 모든 job을 뜻합니다. 파이프라인의 배포 수는 파이프라인 생성 시점에 확인됩니다. 배포가 너무 많은 파이프라인은 deployments_limit_exceeded 오류와 함께 실패합니다.

제한을 변경하려면 다음 GitLab Rails 콘솔 명령으로 default 플랜의 제한을 변경합니다:

# If limits don't exist for the default plan, you can create one with:
# Plan.default.create_limits!

Plan.default.actual_limits.update!(ci_pipeline_deployments: 500)

기본 제한은 500입니다. 제한을 0으로 설정하면 비활성화됩니다.

파이프라인 트리거 수 제한#

프로젝트당 최대 파이프라인 트리거 수에 제한을 설정할 수 있습니다. 이 제한은 새 트리거가 생성될 때마다 확인됩니다.

새 트리거로 인해 총 파이프라인 트리거 수가 제한을 초과하게 되면 해당 트리거는 유효하지 않은 것으로 간주됩니다.

제한을 0으로 설정하면 비활성화됩니다. 기본값은 25000입니다.

이 제한을 100으로 설정하려면 GitLab Rails 콘솔에서 다음을 실행합니다:

Plan.default.actual_limits.update!(pipeline_triggers: 100)

파이프라인 스케줄이 하루에 생성하는 파이프라인 수 제한#

개별 파이프라인 스케줄이 하루에 트리거할 수 있는 파이프라인 수를 제한할 수 있습니다.

제한보다 잦게 파이프라인을 실행하려는 스케줄은 최대 빈도에 맞춰 느려집니다. 빈도는 1440(하루의 분 수)을 제한 값으로 나누어 계산합니다. 예를 들어 최대 빈도가 다음과 같은 경우입니다:

• 1분에 한 번이면 제한이 1440이어야 합니다.
• 10분에 한 번이면 제한이 144여야 합니다.
• 60분에 한 번이면 제한이 24여야 합니다

최솟값은 24이며, 60분당 파이프라인 한 개에 해당합니다. 최댓값은 없습니다.

GitLab Self-Managed 인스턴스에서 이 제한을 1440으로 설정하려면 GitLab Rails 콘솔에서 다음을 실행합니다:

Plan.default.actual_limits.update!(ci_daily_pipeline_schedule_triggers: 1440)

최대 파이프라인 스케줄 빈도#

예약 파이프라인은 어떤 cron 값으로든 구성할 수 있으나, 예약된 시각에 항상 정확히 실행되지는 않습니다. "pipeline schedule worker"라고 하는 내부 프로세스가 예약된 모든 파이프라인을 큐에 넣지만, 이 프로세스는 계속 실행되지는 않습니다. 워커는 자체 스케줄에 따라 실행되며, 시작할 준비가 된 예약 파이프라인은 워커가 다음번에 실행될 때에만 큐에 들어갑니다. 예약 파이프라인은 워커보다 잦게 실행될 수 없습니다.

pipeline schedule worker의 기본 빈도는 3-59/10 * * * *입니다(0:03, 0:13, 0:23처럼 10분마다 실행). GitLab.com의 기본 빈도는 GitLab.com 설정에 정리되어 있습니다.

pipeline schedule worker의 빈도를 변경하려면 다음을 수행합니다.

1. 인스턴스의 gitlab.rb 파일에서 gitlab_rails['pipeline_schedule_worker_cron'] 값을 편집합니다.
2. 변경 사항을 적용하려면 GitLab을 재구성합니다.

예를 들어 파이프라인의 최대 빈도를 하루 두 번으로 설정하려면 pipeline_schedule_worker_cron을 cron 값 0 */12 * * *(매일 00:00과 12:00)로 설정합니다.

많은 파이프라인 스케줄이 동시에 실행되면 추가 지연이 발생할 수 있습니다. pipeline schedule worker는 시스템 부하를 분산하기 위해 배치 단위로 파이프라인을 처리하며 배치마다 짧은 지연을 둡니다. 이 때문에 시스템 부하에 따라 파이프라인 스케줄이 예약 시각보다 몇 분에서 한 시간 이상 늦게 시작될 수 있습니다.

보안 정책 프로젝트에 대한 스케줄 규칙 수 제한#

보안 정책 프로젝트당 총 스케줄 규칙 수를 제한할 수 있습니다. 이 제한은 스케줄 규칙이 있는 정책이 갱신될 때마다 확인됩니다. 새 스케줄 규칙으로 인해 총 스케줄 규칙 수가 제한을 초과하게 되면 새 스케줄 규칙은 처리되지 않습니다.

기본적으로 GitLab은 처리 가능한 스케줄 규칙 수를 제한하지 않습니다.

이 제한을 설정하려면 GitLab Rails 콘솔에서 다음을 실행합니다:

Plan.default.actual_limits.update!(security_policy_scan_execution_schedules: 100)

그룹 및 프로젝트 CI/CD 변수 제한#

그룹과 프로젝트에서 정의할 수 있는 CI/CD 변수의 개수는 인스턴스 전체에 대해 제한됩니다. 이 제한은 새 변수를 만들 때마다 확인됩니다. 새 변수로 인해 변수 총개수가 각각의 제한을 초과하게 되면 새 변수는 생성되지 않습니다.

이 제한 중 하나의 default 플랜을 갱신하려면 GitLab Rails 콘솔에서 다음 명령을 실행합니다:

• 그룹당 그룹 수준 CI/CD 변수 제한(기본값: 30000):

  Plan.default.actual_limits.update!(group_ci_variables: 40000)
  

• 프로젝트당 프로젝트 수준 CI/CD 변수 제한(기본값: 8000):

  Plan.default.actual_limits.update!(project_ci_variables: 10000)
  

아티팩트 유형별 최대 파일 크기#

히스토리

• GitLab 17.3에서 ci_max_artifact_size_jacoco 제한이 도입되었습니다
• GitLab 17.8에서 ci_max_artifact_size_lsif 제한이 상향되었습니다.

러너가 업로드하는 artifacts:reports로 정의된 job 아티팩트는 파일 크기가 최대 파일 크기 제한을 초과하면 거부됩니다. 이 제한은 프로젝트의 최대 아티팩트 크기 설정과 해당 아티팩트 유형의 인스턴스 제한을 비교해 더 작은 값으로 결정됩니다.

제한은 메가바이트 단위로 설정하므로, 정의할 수 있는 가장 작은 값은 1 MB입니다.

아티팩트 유형마다 설정할 수 있는 크기 제한이 있습니다. 기본값 0은 해당 아티팩트 유형에 제한이 없다는 뜻이며, 이때는 프로젝트의 최대 아티팩트 크기 설정이 사용됩니다:

예를 들어 GitLab Self-Managed에서 ci_max_artifact_size_junit 제한을 10 MB로 설정하려면 GitLab Rails 콘솔에서 다음을 실행합니다:

Plan.default.actual_limits.update!(ci_max_artifact_size_junit: 10)

ci_max_artifact_size_cyclonedx는 Admin 영역에서도 설정할 수 있습니다. 자세한 내용은 CycloneDX 아티팩트 크기 제한을 참고합니다.

job 로그의 최대 파일 크기#

GitLab의 job 로그 파일 크기 제한은 기본적으로 100메가바이트입니다. 이 제한을 초과하는 job은 실패로 표시되고 러너에서 중단됩니다.

GitLab Rails 콘솔에서 이 제한을 변경할 수 있습니다. ci_jobs_trace_size_limit을 새 값(메가바이트 단위)으로 갱신합니다:

Plan.default.actual_limits.update!(ci_jobs_trace_size_limit: 125)

GitLab Runner에도 러너의 최대 로그 크기를 구성하는 output_limit 설정이 있습니다. 러너 제한을 초과하는 job은 계속 실행되지만, 제한에 도달한 시점부터 로그가 잘립니다.

프로젝트당 최대 활성 DAST 프로파일 스케줄 수#

프로젝트당 활성 DAST 프로파일 스케줄 수를 제한합니다. DAST 프로파일 스케줄은 활성 또는 비활성 상태일 수 있습니다.

GitLab Rails 콘솔에서 이 제한을 변경할 수 있습니다. dast_profile_schedules를 새 값으로 갱신합니다:

Plan.default.actual_limits.update!(dast_profile_schedules: 50)

CI/CD 구성 YAML 파일의 최대 크기 및 깊이#

히스토리

• GitLab 17.3에서 max_yaml_size_bytes의 기본값이 변경되었습니다.

단일 CI/CD 구성 YAML 파일의 기본 최대 크기는 2메가바이트이고 기본 깊이는 100입니다.

GitLab Rails 콘솔에서 이 제한을 변경할 수 있습니다:

• 최대 YAML 크기를 갱신하려면 max_yaml_size_bytes를 새 값(메가바이트 단위)으로 갱신합니다:

  ApplicationSetting.update(max_yaml_size_bytes: 4.megabytes)
  

  max_yaml_size_bytes 값은 YAML 파일의 크기와 직접 연결되는 것이 아니라, 관련 객체에 할당되는 메모리와 연결됩니다.

• 최대 YAML 깊이를 갱신하려면 max_yaml_depth를 새 값(줄 수 단위)으로 갱신합니다:

  ApplicationSetting.update(max_yaml_depth: 125)
  

전체 CI/CD 구성의 최대 크기#

히스토리

• GitLab 17.3에서 max_yaml_size_bytes의 기본값이 변경되었습니다.
• GitLab 17.3에서 ci_max_total_yaml_size_bytes의 기본값이 변경되었습니다.

포함된 모든 YAML 구성 파일을 합한 전체 파이프라인 구성에 할당할 수 있는 최대 메모리 양(바이트)입니다.

기본값은 max_yaml_size_bytes(기본값 2 MB)와 ci_max_includes(기본값 150)를 곱해 계산합니다:

• GitLab 17.2 이하: 1 MB × 150 = 157286400바이트(150 MB).
• GitLab 17.3 이상: 2 MB × 150 = 314572800바이트(314.6 MB).

GitLab Rails 콘솔로 이 제한을 변경할 수 있습니다. CI/CD 구성에 할당할 수 있는 최대 메모리를 갱신하려면 ci_max_total_yaml_size_bytes를 새 값으로 갱신합니다. 예를 들어 20 MB로 설정하려면 다음과 같이 실행합니다:

ApplicationSetting.update(ci_max_total_yaml_size_bytes: 20.megabytes)

이 제한은 파이프라인이 생성될 때 단일 CI/CD job에 대해 저장되는 컴파일된 구성에도 적용됩니다. 단일 job의 구성은 항상 전체 파이프라인 구성의 부분집합이므로 이 제한을 초과할 수 없습니다.

CI/CD job 어노테이션 제한#

CI/CD job당 어노테이션의 최대 개수에 제한을 설정할 수 있습니다.

제한을 0으로 설정하면 비활성화됩니다. 기본값은 20입니다.

인스턴스에서 이 제한을 100으로 설정하려면 GitLab Rails 콘솔에서 다음 명령을 실행합니다:

Plan.default.actual_limits.update!(ci_job_annotations_num: 100)

CI/CD job 어노테이션 파일 크기 제한#

CI/CD job 어노테이션의 최대 크기에 제한을 설정할 수 있습니다.

제한을 0으로 설정하면 비활성화됩니다. 기본값은 80 KB입니다.

이 제한을 100 KB로 설정하려면 GitLab Rails 콘솔에서 다음을 실행합니다:

Plan.default.actual_limits.update!(ci_job_annotations_size: 100.kilobytes)

CI/CD 테이블의 최대 데이터베이스 파티션 크기#

히스토리

• GitLab 18.0에서 도입되었습니다.
• GitLab 18.11에서 제거되었습니다.

새 파티션이 자동으로 생성되기 전까지 파티션된 테이블의 한 파티션이 사용할 수 있는 최대 디스크 공간(바이트)입니다. 기본값은 100 GB입니다.

GitLab Rails 콘솔로 이 제한을 변경할 수 있습니다. 제한을 변경하려면 ci_partitions_size_limit을 새 값으로 갱신합니다. 예를 들어 20 GB로 설정하려면 다음과 같이 실행합니다:

ApplicationSetting.update(ci_partitions_size_limit: 20.gigabytes)

CI/CD 파티션의 최대 시간 범위#

히스토리

• GitLab 18.10에서 도입되었습니다.

새 CI 파티션이 생성되고 시스템이 다음 파티션 세트로 전환되기까지의 시간 범위(초)입니다. 1개월에서 6개월 사이여야 합니다. 기본값은 1개월(2592000초)입니다.

GitLab Rails 콘솔로 이 제한을 변경할 수 있습니다. 제한을 변경하려면 ci_partitions_in_seconds_limit을 새 값으로 갱신합니다. 예를 들어 3개월로 설정하려면 다음과 같이 실행합니다:

ApplicationSetting.update(ci_partitions_in_seconds_limit: ChronicDuration.parse('3 months'))

자동 파이프라인 정리의 최대 보존 기간#

히스토리

• GitLab 18.0에서 도입되었습니다.

자동 파이프라인 정리의 상한을 구성합니다. 기본값은 1년입니다.

GitLab Rails 콘솔로 이 제한을 변경할 수 있습니다. 제한을 변경하려면 ci_delete_pipelines_in_seconds_limit_human_readable을 새 값으로 갱신합니다. 예를 들어 3년으로 설정하려면 다음과 같이 실행합니다:

ApplicationSetting.update(ci_delete_pipelines_in_seconds_limit_human_readable: '3 years')