CI/CD 제한

요약

관리자 영역을 통해 많은 CI/CD 관련 인스턴스 제한을 관리할 수 있습니다. GitLab.com은 GitLab Self-Managed 기본값과 다른 값을 사용할 수 있습니다. 인스턴스 설정에서 정의할 수 있는 CI/CD 변수의 수가 제한됩니다.

CI/CD 제한#

  - 
  Offering: GitLab Self-Managed, GitLab Dedicated

관리자 영역을 통해 많은 CI/CD 관련 인스턴스 제한을 관리할 수 있습니다. 그 밖의 제한은 GitLab Rails 콘솔을 통해 인스턴스 구성을 수정해야만 변경할 수 있습니다.

GitLab.com은 GitLab Self-Managed 기본값과 다른 값을 사용할 수 있습니다. GitLab.com의 CI/CD 제한 및 설정을 검토하세요.

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

History

GitLab 17.1에서 도입됨.

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

이 제한을 구성하려면:

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

dotenv 파일 크기 제한#

History

GitLab 17.1에서 도입됨.

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

이 제한을 구성하려면:

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

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

dotenv 변수 제한#

History

GitLab 17.1에서 도입됨.

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

이 제한을 구성하려면:

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

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

Plan limits API를 사용하여 이 제한을 설정할 수도 있습니다.

파이프라인의 최대 job 수#

History

GitLab 17.6에서 설정이 GitLab Enterprise Edition에서 GitLab Community Edition으로 이동됨.

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

이 제한을 구성하려면:

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

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

활성 파이프라인의 job 수#

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

created
pending
running

새 파이프라인이 총 job 수를 제한 초과하게 만들 경우, 파이프라인은 job_activity_limit_exceeded 오류와 함께 실패합니다.

이 제한을 구성하려면:

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

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

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

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

새 구독이 총 구독 수를 제한 초과하게 만들 경우, 구독은 유효하지 않은 것으로 간주됩니다.

이 제한을 구성하려면:

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

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

파이프라인 스케줄 수#

총 파이프라인 스케줄 수는 프로젝트별로 제한할 수 있습니다. 이 제한은 새 파이프라인 스케줄이 생성될 때마다 확인됩니다. 새 파이프라인 스케줄이 총 파이프라인 스케줄 수를 제한 초과하게 만들 경우, 파이프라인 스케줄은 생성되지 않습니다.

이 제한을 구성하려면:

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

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

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

최대 needs 의존성 수#

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

이 제한을 구성하려면:

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

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

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

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

History

러너 비활성 타임아웃이 GitLab 17.1에서 3개월에서 7일로 변경됨.

등록된 러너의 총 수는 그룹 및 프로젝트별로 제한됩니다. 새 러너가 등록될 때마다 GitLab은 최근 7일 이내에 생성되거나 활성화된 러너에 대해 이 제한을 확인합니다. 러너 등록 토큰으로 결정된 범위의 제한을 초과하면 러너 등록이 실패합니다.

이 제한을 구성하려면:

오른쪽 상단에서 Admin을 선택합니다.
왼쪽 사이드바에서 Settings > CI/CD를 선택합니다.
Continuous Integration and Deployment를 확장합니다.
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
Save changes를 선택합니다.

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

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

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

이 제한을 늘리는 것은 권장하지 않습니다. 기본 제한은 GitLab 인스턴스를 과도한 리소스 소비,

잠재적인 파이프라인 재귀, 및 데이터베이스 과부하로부터 보호합니다.

제한을 늘리는 대신, 큰 파이프라인 계층을 더 작은 파이프라인으로 분리하여 CI/CD 구성을 재구성하세요. 단일 파이프라인에서 job 간에 needs 사용이나 종속 Stage를 고려하세요.

이 제한을 구성하려면:

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

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

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

History

GitLab 19.0에서 도입됨.

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

이 제한을 구성하려면:

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

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

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

job의 최대 실행 시간#

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

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

특정 프로젝트의 경우 프로젝트의 CI/CD 설정에서 변경할 수 있습니다. 이 제한은 10분에서 1개월 사이여야 합니다.
러너에 대해. 이 제한은 10분 이상이어야 합니다.

구성된 타임아웃 제한에 관계없이 GitLab은 60분 동안 비활성 상태인 모든 job을 종료합니다. 비활성 job은 새 로그나 트레이스 업데이트를 생성하지 않는 job입니다.

Git 푸시당 파이프라인 수#

History

GitLab 18.0에서 도입됨.

이 제한을 늘리는 것은 권장하지 않습니다. 많은 변경 사항이 동시에 푸시될 경우 GitLab 인스턴스에 과도한 부하를 줄 수 있으며, 잠재적으로 대량의 파이프라인이 생성될 수 있습니다.

단일 Git 푸시로 여러 변경 사항(예: 여러 태그 또는 브랜치)을 푸시할 때, 기본적으로 최대 4개의 태그 또는 브랜치 파이프라인만 트리거될 수 있습니다. 이 제한은 git push --all 또는 git push --mirror를 사용할 때 다수의 파이프라인이 우발적으로 생성되는 것을 방지합니다.

머지 리퀘스트 파이프라인은 제한됩니다. Git 푸시가 여러 머지 리퀘스트를 동시에 업데이트하는 경우, 제한에 도달하기 전에 업데이트된 모든 머지 리퀘스트에 대해 머지 리퀘스트 파이프라인이 트리거될 수 있습니다.

기본값은 GitLab Self-Managed 및 GitLab.com 모두 4입니다.

GitLab Self-Managed 인스턴스에서 이 제한을 변경하려면:

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

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

History

GitLab 15.0에서 ci_enforce_throttle_pipelines_creation이라는 플래그와 함께 도입됨. 기본적으로 비활성화되어 있음. GitLab.com에서 활성화됨.
18.3에서 기본적으로 활성화됨.

사용자와 프로세스가 분당 특정 수 이상의 파이프라인을 요청하지 못하도록 제한을 설정할 수 있습니다. 이러한 제한은 리소스를 절약하고 안정성을 향상시키는 데 도움이 됩니다.

GitLab은 파이프라인 생성에 대해 두 가지 유형의 속도 제한을 적용합니다:

프로젝트, 커밋, 사용자별: 동일한 프로젝트, 커밋 SHA, 사용자 조합에 대해 생성된 파이프라인을 제한합니다. 기본적으로 비활성화되어 있습니다.
사용자별: 모든 프로젝트에 걸쳐 사용자가 생성한 총 파이프라인을 제한합니다. 기본적으로 비활성화되어 있습니다.

예를 들어, 사용자별 제한을 100으로 설정하고, 사용자가 1분 이내에 다른 프로젝트에서 trigger API에 101개의 파이프라인 생성 요청을 보내면, 101번째 요청은 차단됩니다. 1분 후에 엔드포인트에 대한 접근이 다시 허용됩니다.

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

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

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

전제 조건:

관리자 접근 권한.

파이프라인 요청 수를 제한하려면:

오른쪽 상단에서 Admin을 선택합니다.
왼쪽 사이드바에서 Settings > Network를 선택합니다.
Pipelines Rate Limits를 확장합니다.

Max requests per minute per project, user, and commit 아래에서 0보다 큰 값을 입력하여 동일한 프로젝트, 커밋, 사용자 조합에 대한 파이프라인을 제한합니다.

Max requests per minute per user 아래에서 0보다 큰 값을 입력하여 각 사용자가 생성하는 총 파이프라인을 제한합니다. 분당 무제한 요청을 허용하려면 0으로 설정합니다.
Save changes를 선택합니다.

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

프로젝트에서 동일한 커밋 SHA에 대해 여러 파이프라인을 생성하는 사용자는 프로젝트, 사용자, 커밋별 제한이 적용됩니다.
다른 프로젝트나 커밋에 걸쳐 파이프라인을 생성하는 사용자는 사용자별 제한이 적용됩니다.
두 제한 중 하나라도 초과되면 파이프라인 생성 요청이 차단됩니다.

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

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

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

이 제한을 구성하려면:

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

최대 아티팩트 크기#

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

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

이 설정은 job의 개별 파일이 아닌 최종 아카이브 파일의 크기에 적용됩니다.

다음에 대한 아티팩트 크기 제한을 구성할 수 있습니다:

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

GitLab.com 제한에 대해서는 아티팩트 최대 크기를 참조하세요.

인스턴스의 최대 아티팩트 크기를 변경하려면:

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

최대 include 수#

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

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

파이프라인당 최대 포함 파일 수를 설정하려면:

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

job당 최대 캐시 수#

```
Status: Beta
```

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

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

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

job당 최대 캐시 수를 변경하려면:

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

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

```
Offering: GitLab Self-Managed
```

일부 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분당 1회인 경우 제한은 144이어야 합니다.
60분당 1회인 경우 제한은 24이어야 합니다.

최솟값은 24이며, 60분당 1개의 파이프라인입니다. 최댓값은 없습니다.

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

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

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

파이프라인 스케줄은 cron 값으로 구성할 수 있지만, 정확히 예약된 시간에 실행되지 않을 수 있습니다. "파이프라인 스케줄 워커"라고 하는 내부 프로세스가 모든 예약된 파이프라인을 대기열에 추가하지만, 지속적으로 실행되지는 않습니다. 워커는 자체 스케줄로 실행되며, 시작 준비가 된 예약된 파이프라인은 워커가 다음에 실행될 때만 대기열에 추가됩니다. 예약된 파이프라인은 워커보다 더 자주 실행될 수 없습니다.

파이프라인 스케줄 워커의 기본 빈도는 3-59/10 * * * *(10분마다, 0:03, 0:13, 0:23 등으로 시작)입니다. GitLab.com의 기본 빈도는 GitLab.com 설정에 나열되어 있습니다.

파이프라인 스케줄 워커의 빈도를 변경하려면:

인스턴스의 gitlab.rb 파일에서 gitlab_rails['pipeline_schedule_worker_cron'] 값을 편집합니다.
변경 사항이 적용되도록 GitLab을 재구성합니다.

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

많은 파이프라인 스케줄이 동시에 실행될 때 추가 지연이 발생할 수 있습니다. 파이프라인 스케줄 워커는 시스템 부하를 분산하기 위해 각 배치 사이에 약간의 지연을 두고 배치로 파이프라인을 처리합니다. 이로 인해 시스템 부하에 따라 파이프라인 스케줄이 예약된 시간보다 몇 분에서 한 시간 이상 늦게 시작될 수 있습니다.

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

보안 정책 프로젝트당 총 스케줄 규칙 수를 제한할 수 있습니다. 이 제한은 스케줄 규칙이 있는 정책이 업데이트될 때마다 확인됩니다. 새 스케줄 규칙이 총 스케줄 규칙 수를 제한 초과하게 만들 경우, 새 스케줄 규칙은 처리되지 않습니다.

기본적으로 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)

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

History

ci_max_artifact_size_annotations 제한이 GitLab 16.3에서 도입됨.
ci_max_artifact_size_jacoco 제한이 GitLab 17.3에서 도입됨.
ci_max_artifact_size_lsif 제한이 GitLab 17.8에서 증가됨.

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

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

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

아티팩트 제한 이름	기본값
ci_max_artifact_size_accessibility	0
ci_max_artifact_size_annotations	0
ci_max_artifact_size_api_fuzzing	0
ci_max_artifact_size_archive	0
ci_max_artifact_size_browser_performance	0
ci_max_artifact_size_cluster_applications	0
ci_max_artifact_size_cobertura	0
ci_max_artifact_size_codequality	0
ci_max_artifact_size_container_scanning	0
ci_max_artifact_size_coverage_fuzzing	0
ci_max_artifact_size_dast	0
ci_max_artifact_size_dependency_scanning	0
ci_max_artifact_size_dotenv	0
ci_max_artifact_size_jacoco	0
ci_max_artifact_size_junit	0
ci_max_artifact_size_license_management	0
ci_max_artifact_size_license_scanning	0
ci_max_artifact_size_load_performance	0
ci_max_artifact_size_lsif	200 MB
ci_max_artifact_size_metadata	0
ci_max_artifact_size_metrics_referee	0
ci_max_artifact_size_metrics	0
ci_max_artifact_size_network_referee	0
ci_max_artifact_size_performance	0
ci_max_artifact_size_requirements	0
ci_max_artifact_size_requirements_v2	0
ci_max_artifact_size_sast	0
ci_max_artifact_size_secret_detection	0
ci_max_artifact_size_terraform	5 MB
ci_max_artifact_size_trace	0
ci_max_artifact_size_cyclonedx	5 MB

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

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

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 아티팩트 아카이브의 최대 크기#

이 설정은 동적 자식 파이프라인의 YAML 크기를 제한하는 데 사용됩니다.

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

GitLab Rails 콘솔을 사용하여 이 제한을 변경할 수 있습니다. CI 아티팩트 아카이브의 최대 크기를 업데이트하려면 max_artifacts_content_include_size를 새 값으로 업데이트합니다. 예를 들어, 20 MB로 설정하려면:

ApplicationSetting.update(max_artifacts_content_include_size: 20.megabytes)

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

History

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 구성의 최대 크기#

History

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 어노테이션 제한#

History

GitLab 16.3에서 도입됨.

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

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

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

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

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

History

GitLab 16.3에서 도입됨.

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

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

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

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

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

History

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 파티션의 최대 시간 윈도우#

History

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'))

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

History

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')

CI/CD 제한

GitLab v19.1

원문 보기

번역일: 2026-06-19

요약

CI/CD 제한#

  - 
  Offering: GitLab Self-Managed, GitLab Dedicated

GitLab.com은 GitLab Self-Managed 기본값과 다른 값을 사용할 수 있습니다. GitLab.com의 CI/CD 제한 및 설정을 검토하세요.

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

History

GitLab 17.1에서 도입됨.

이 제한을 구성하려면:

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

dotenv 파일 크기 제한#

History

GitLab 17.1에서 도입됨.

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

이 제한을 구성하려면:

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

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

dotenv 변수 제한#

History

GitLab 17.1에서 도입됨.

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

이 제한을 구성하려면:

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

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

Plan limits API를 사용하여 이 제한을 설정할 수도 있습니다.

파이프라인의 최대 job 수#

History

GitLab 17.6에서 설정이 GitLab Enterprise Edition에서 GitLab Community Edition으로 이동됨.

이 제한을 구성하려면:

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

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

활성 파이프라인의 job 수#

created
pending
running

새 파이프라인이 총 job 수를 제한 초과하게 만들 경우, 파이프라인은 job_activity_limit_exceeded 오류와 함께 실패합니다.

이 제한을 구성하려면:

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

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

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

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

새 구독이 총 구독 수를 제한 초과하게 만들 경우, 구독은 유효하지 않은 것으로 간주됩니다.

이 제한을 구성하려면:

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

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

파이프라인 스케줄 수#

이 제한을 구성하려면:

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

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

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

최대 needs 의존성 수#

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

이 제한을 구성하려면:

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

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

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

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

History

러너 비활성 타임아웃이 GitLab 17.1에서 3개월에서 7일로 변경됨.

이 제한을 구성하려면:

오른쪽 상단에서 Admin을 선택합니다.
왼쪽 사이드바에서 Settings > CI/CD를 선택합니다.
Continuous Integration and Deployment를 확장합니다.
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
Save changes를 선택합니다.

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

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

이 제한을 늘리는 것은 권장하지 않습니다. 기본 제한은 GitLab 인스턴스를 과도한 리소스 소비,

잠재적인 파이프라인 재귀, 및 데이터베이스 과부하로부터 보호합니다.

이 제한을 구성하려면:

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

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

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

History

GitLab 19.0에서 도입됨.

이 제한을 구성하려면:

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

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

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

job의 최대 실행 시간#

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

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

특정 프로젝트의 경우 프로젝트의 CI/CD 설정에서 변경할 수 있습니다. 이 제한은 10분에서 1개월 사이여야 합니다.
러너에 대해. 이 제한은 10분 이상이어야 합니다.

Git 푸시당 파이프라인 수#

History

GitLab 18.0에서 도입됨.

이 제한을 늘리는 것은 권장하지 않습니다. 많은 변경 사항이 동시에 푸시될 경우 GitLab 인스턴스에 과도한 부하를 줄 수 있으며, 잠재적으로 대량의 파이프라인이 생성될 수 있습니다.

단일 Git 푸시로 여러 변경 사항(예: 여러 태그 또는 브랜치)을 푸시할 때, 기본적으로 최대 4개의 태그 또는 브랜치 파이프라인만 트리거될 수 있습니다. 이 제한은 git push --all 또는 git push --mirror를 사용할 때 다수의 파이프라인이 우발적으로 생성되는 것을 방지합니다.

기본값은 GitLab Self-Managed 및 GitLab.com 모두 4입니다.

GitLab Self-Managed 인스턴스에서 이 제한을 변경하려면:

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

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

History

GitLab 15.0에서 ci_enforce_throttle_pipelines_creation이라는 플래그와 함께 도입됨. 기본적으로 비활성화되어 있음. GitLab.com에서 활성화됨.
18.3에서 기본적으로 활성화됨.

GitLab은 파이프라인 생성에 대해 두 가지 유형의 속도 제한을 적용합니다:

프로젝트, 커밋, 사용자별: 동일한 프로젝트, 커밋 SHA, 사용자 조합에 대해 생성된 파이프라인을 제한합니다. 기본적으로 비활성화되어 있습니다.
사용자별: 모든 프로젝트에 걸쳐 사용자가 생성한 총 파이프라인을 제한합니다. 기본적으로 비활성화되어 있습니다.

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

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

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

전제 조건:

관리자 접근 권한.

파이프라인 요청 수를 제한하려면:

오른쪽 상단에서 Admin을 선택합니다.
왼쪽 사이드바에서 Settings > Network를 선택합니다.
Pipelines Rate Limits를 확장합니다.

Max requests per minute per project, user, and commit 아래에서 0보다 큰 값을 입력하여 동일한 프로젝트, 커밋, 사용자 조합에 대한 파이프라인을 제한합니다.

Max requests per minute per user 아래에서 0보다 큰 값을 입력하여 각 사용자가 생성하는 총 파이프라인을 제한합니다. 분당 무제한 요청을 허용하려면 0으로 설정합니다.
Save changes를 선택합니다.

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

프로젝트에서 동일한 커밋 SHA에 대해 여러 파이프라인을 생성하는 사용자는 프로젝트, 사용자, 커밋별 제한이 적용됩니다.
다른 프로젝트나 커밋에 걸쳐 파이프라인을 생성하는 사용자는 사용자별 제한이 적용됩니다.
두 제한 중 하나라도 초과되면 파이프라인 생성 요청이 차단됩니다.

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

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

이 제한을 구성하려면:

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

최대 아티팩트 크기#

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

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

이 설정은 job의 개별 파일이 아닌 최종 아카이브 파일의 크기에 적용됩니다.

다음에 대한 아티팩트 크기 제한을 구성할 수 있습니다:

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

GitLab.com 제한에 대해서는 아티팩트 최대 크기를 참조하세요.

인스턴스의 최대 아티팩트 크기를 변경하려면:

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

최대 include 수#

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

파이프라인당 최대 포함 파일 수를 설정하려면:

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

job당 최대 캐시 수#

```
Status: Beta
```

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

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

job당 최대 캐시 수를 변경하려면:

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

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

```
Offering: GitLab Self-Managed
```

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

전제 조건:

인스턴스에 대한 GitLab Rails 콘솔에 접근할 수 있어야 합니다.

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

제한을 변경하려면 다음 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)

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

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

분당 1회인 경우 제한은 1440이어야 합니다.
10분당 1회인 경우 제한은 144이어야 합니다.
60분당 1회인 경우 제한은 24이어야 합니다.

최솟값은 24이며, 60분당 1개의 파이프라인입니다. 최댓값은 없습니다.

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

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

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

파이프라인 스케줄 워커의 빈도를 변경하려면:

인스턴스의 gitlab.rb 파일에서 gitlab_rails['pipeline_schedule_worker_cron'] 값을 편집합니다.
변경 사항이 적용되도록 GitLab을 재구성합니다.

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

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

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

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

그룹 및 프로젝트 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)

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

History

ci_max_artifact_size_annotations 제한이 GitLab 16.3에서 도입됨.
ci_max_artifact_size_jacoco 제한이 GitLab 17.3에서 도입됨.
ci_max_artifact_size_lsif 제한이 GitLab 17.8에서 증가됨.

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

아티팩트 제한 이름	기본값
ci_max_artifact_size_accessibility	0
ci_max_artifact_size_annotations	0
ci_max_artifact_size_api_fuzzing	0
ci_max_artifact_size_archive	0
ci_max_artifact_size_browser_performance	0
ci_max_artifact_size_cluster_applications	0
ci_max_artifact_size_cobertura	0
ci_max_artifact_size_codequality	0
ci_max_artifact_size_container_scanning	0
ci_max_artifact_size_coverage_fuzzing	0
ci_max_artifact_size_dast	0
ci_max_artifact_size_dependency_scanning	0
ci_max_artifact_size_dotenv	0
ci_max_artifact_size_jacoco	0
ci_max_artifact_size_junit	0
ci_max_artifact_size_license_management	0
ci_max_artifact_size_license_scanning	0
ci_max_artifact_size_load_performance	0
ci_max_artifact_size_lsif	200 MB
ci_max_artifact_size_metadata	0
ci_max_artifact_size_metrics_referee	0
ci_max_artifact_size_metrics	0
ci_max_artifact_size_network_referee	0
ci_max_artifact_size_performance	0
ci_max_artifact_size_requirements	0
ci_max_artifact_size_requirements_v2	0
ci_max_artifact_size_sast	0
ci_max_artifact_size_secret_detection	0
ci_max_artifact_size_terraform	5 MB
ci_max_artifact_size_trace	0
ci_max_artifact_size_cyclonedx	5 MB

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

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

job 로그의 최대 파일 크기#

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

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

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

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

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

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

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

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

이 설정은 동적 자식 파이프라인의 YAML 크기를 제한하는 데 사용됩니다.

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

ApplicationSetting.update(max_artifacts_content_include_size: 20.megabytes)

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

History

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 구성의 최대 크기#

History

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).

ApplicationSetting.update(ci_max_total_yaml_size_bytes: 20.megabytes)

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

History

GitLab 16.3에서 도입됨.

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

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

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

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

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

History

GitLab 16.3에서 도입됨.

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

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

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

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

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

History

GitLab 18.0에서 도입됨.
GitLab 18.11에서 제거됨.

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

ApplicationSetting.update(ci_partitions_size_limit: 20.gigabytes)

CI/CD 파티션의 최대 시간 윈도우#

History

GitLab 18.10에서 도입됨.

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

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

History

GitLab 18.0에서 도입됨.

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

ApplicationSetting.update(ci_delete_pipelines_in_seconds_limit_human_readable: '3 years')