• 최대 작업 시간 설정
  • 인스턴스 runner인 경우
  • 그룹 runner 인 경우
  • 프로젝트 runner인 경우
• 최대 작업 시간 설정 방법
• script 및 after_script 시간 제한 설정
• 민감한 정보 보호
• Long Polling 구성
• 포크된 프로젝트에서 인스턴스 러너 사용하기
• 프로젝트용 러너 등록 토큰 재설정(폐기됨)
• 인증 토큰 보안
  • 러너 구성 인증 토큰 재설정
  • 러너 인증 토큰 자동 회전
• 러너가 민감한 정보를 노출하지 않도록 방지하기
  • 인스턴스 러너의 경우
  • 그룹 러너용
  • 프로젝트 러너용
• 러너가 실행할 수 있는 작업 제어
  • 인스턴스 러너용
  • 그룹 러너용
  • 프로젝트 러너용
  • 러너가 태그를 사용하는 방법
    • 러너가 지정된 작업만 실행
    • 러너가 태그가 지정되지 않은 작업을 실행할 수 있는 경우
    • 러너와 작업에 여러 태그가 있는 경우
  • 다른 플랫폼에서 작업 실행을 위해 태그 사용
  • CI/CD 변수를 태그에서 사용
• 변수로 러너 동작 구성
  • Git 전략
  • 서브모듈 Git 전략
  • Git 체크아웃
  • Git clean 플래그
  • Git fetch 추가 플래그
  • CI 작업에서 특정 서브모듈 동기화 또는 제외
  • 서브모듈 업데이트 플래그
  • 서브모듈 URL을 HTTPS로 재작성
  • 얕은 클론
  • Git 서브모듈 깊이
  • 사용자 정의 빌드 디렉터리
    • 동시성 처리
    • 중첩 경로
  • after_script에서 오류 무시
  • 작업 단계 시도
• GitLab.com 인스턴스 러너에서 사용할 수 없는 시스템 호출
• 아티팩트 및 캐시 설정
• 아티팩트 출처 메타데이터
  • 출처 메타데이터 형식
• 스테이징 디렉터리
• 성능 향상을 위해 fastzip 구성

Runner 구성

이 문서에서는 GitLab UI에서 runner를 구성하는 방법에 대해 설명합니다.

GitLab Runner를 설치한 기계에서 runner를 구성해야하는 경우 GitLab Runner 문서를 참조하십시오.

최대 작업 시간 설정

각 runner에 대해 최대 작업 시간을 지정하여 보다 긴 작업 시간이 필요한 프로젝트가 runner를 사용하지 못하도록 할 수 있습니다. 프로젝트에서 정의된 작업 시간보다 최대 작업 시간이 짧은 경우 최대 작업 시간이 사용됩니다.

Runner의 최대 시간을 설정하려면 REST API 엔드포인트 PUT /runners/:id에서 maximum_timeout 매개변수를 설정하십시오.

인스턴스 runner인 경우

전제 조건: - 관리자여야 합니다.

자체 관리 GitLab 설치에서 인스턴스 runner의 작업 시간을 재정의할 수 있습니다.

GitLab.com에서는 GitLab 호스트 인스턴스 runner의 작업 시간을 재정의할 수 없으며 대신 프로젝트 정의된 시간 제한을 사용해야 합니다.

최대 작업 시간을 설정하려면:

1. 왼쪽 사이드바에서 하단에서 관리를 선택합니다.
2. CI/CD > Runner를 선택합니다.
3. 편집하려는 runner 오른쪽에서 편집 ()을 선택합니다.
4. 최대 작업 시간 필드에 초 단위로 값을 입력하십시오. 최소값은 600초 (10분)입니다.
5. 변경 사항 저장을 선택합니다.

그룹 runner 인 경우

전제 조건: - 그룹의 소유자 역할이 있어야 합니다.

최대 작업 시간을 설정하려면:

1. 왼쪽 사이드바에서 검색 또는 이동을 선택하여 그룹을 찾습니다.
2. 빌드 > Runner를 선택합니다.
3. 편집하려는 runner 오른쪽에서 편집 ()을 선택합니다.
4. 최대 작업 시간 필드에 초 단위로 값을 입력하십시오. 최소값은 600초 (10분)입니다.
5. 변경 사항 저장을 선택합니다.

프로젝트 runner인 경우

전제 조건: - 프로젝트의 소유자 역할이 있어야 합니다.

최대 작업 시간을 설정하려면:

1. 왼쪽 사이드바에서 검색 또는 이동을 선택하여 프로젝트를 찾습니다.
2. 설정 > CI/CD를 선택합니다.
3. Runner를 확장합니다.
4. 편집하려는 runner 오른쪽에서 편집 ()을 선택합니다.
5. 최대 작업 시간 필드에 초 단위로 값을 입력하십시오. 최소값은 600초 (10분)입니다. 정의되지 않은 경우 프로젝트의 작업 시간 제한이 대신 사용됩니다.
6. 변경 사항 저장을 선택합니다.

최대 작업 시간 설정 방법

예 1 - Runner timeout이 프로젝트 timeout보다 큰 경우

1. runner의 _최대 작업 시간_을 24시간으로 설정합니다.
2. 프로젝트의 _CI/CD Timeout_를 2시간으로 설정합니다.
3. 작업을 시작합니다.
4. 작업은 2시간 이후에 시간 초과됩니다.

예 2 - Runner timeout 설정이 되지 않은 경우

1. runner에서 최대 작업 시간 구성을 제거합니다.
2. 프로젝트의 _CI/CD Timeout_를 2시간으로 설정합니다.
3. 작업을 시작합니다.
4. 작업은 2시간 이후에 시간 초과됩니다.

예 3 - Runner timeout이 프로젝트 timeout보다 작은 경우

1. runner의 _최대 작업 시간_을 30분으로 설정합니다.
2. 프로젝트의 _CI/CD Timeout_를 2시간으로 설정합니다.
3. 작업을 시작합니다.
4. 작업은 30분 이후에 시간 초과됩니다.

script 및 after_script 시간 제한 설정

• GitLab Runner 16.4에서 도입.

script 및 after_script가 종료되기 전에 실행되는 시간의 양을 제어하려면 .gitlab-ci.yml 파일에서 시간 제한 값을 지정하십시오.

예를 들어, 긴 실행 script를 조기에 종료하여 작업 시간이 초과되기 전에 여전히 artifact와 cache를 업로드할 수 있도록 시간 제한을 지정할 수 있습니다.

• script에 시간 제한을 설정하려면 작업 변수 RUNNER_SCRIPT_TIMEOUT를 사용하십시오.
• after_script에 시간 제한을 설정하고 기본값 5분을 재정의하려면 작업 변수 RUNNER_AFTER_SCRIPT_TIMEOUT을 사용하십시오.

이러한 변수는 Go의 지속 형식을 허용합니다 (예: 40s, 1h20m, 2h 4h30m30s).

예:

job-with-script-timeouts:
  variables:
    RUNNER_SCRIPT_TIMEOUT: 15m
    RUNNER_AFTER_SCRIPT_TIMEOUT: 10m
  script:
    - "나는 최소(15m, 남은 작업 시간)만큼 실행할 수 있습니다."
  after_script:
    - "나는 최소(10m, 남은 작업 시간)만큼 실행할 수 있습니다."

job-artifact-upload-on-timeout:
  timeout: 1h                           # 작업 시간을 1시간으로 설정 
  variables:
     RUNNER_SCRIPT_TIMEOUT: 50m         # 스크립트가 50분 동안만 실행되도록 허용
  script:
    - long-running-process > output.txt # 50분 후에 종료됩니다.

  artifacts: # artifact는 대략 ~10분 업로드할 시간이 있습니다
    paths:
      - output.txt
    when: on_failure # 타임아웃 후 스크립트 종료는 실패로 처리됩니다

민감한 정보 보호

인스턴스 runner를 사용할 때 보안 리스크가 더 큽니다. 이러한 runner는 GitLab 인스턴스의 모든 그룹 및 프로젝트에서 기본적으로 사용할 수 있습니다. 사용되는 runner executor 및 파일 시스템에 따라, runner가 실행하는 코드와 runner 인증 토큰이 runner 호스트 환경에 액세스 할 수 있는 모든 사용자에게 노출될 수 있습니다. 예를 들어, runner 인증 토큰에 액세스 권한이 있는 사용자는 runner의 클론을 생성하고 vector 공격에서 거짓 작업을 제출하는 데 사용할 수 있습니다. 자세한 내용은 보안 고려 사항을 참조하십시오.

Long Polling 구성

작업 대기 시간 및 GitLab 서버의 부하를 줄이기 위해 롱 폴링을 구성합니다.

포크된 프로젝트에서 인스턴스 러너 사용하기

프로젝트가 포크될 때 작업과 관련된 작업 설정이 복사됩니다. 프로젝트에 인스턴스 러너가 구성되어 있고 사용자가 해당 프로젝트를 포크하면 인스턴스 러너는 해당 프로젝트의 작업을 처리합니다.

알려진 이슈로 인해, 포크된 프로젝트의 러너 설정이 새로운 프로젝트 네임스페이스와 일치하지 않을 경우 다음 메시지가 표시됩니다: 프로젝트를 포크하는 동안 오류가 발생했습니다. 다시 시도하십시오..

이 문제를 해결하려면 포크된 프로젝트와 새 네임스페이스의 인스턴스 러너 설정이 일관되도록 합니다.

• 포크된 프로젝트에서 인스턴스 러너가 활성화되어 있다면, 새 네임스페이스에서도 활성화되어야 합니다.
• 포크된 프로젝트에서 인스턴스 러너가 비활성화되어 있다면, 새 네임스페이스에서도 비활성화되어야 합니다.

프로젝트용 러너 등록 토큰 재설정(폐기됨)

경고: 런너 등록 토큰을 전달하고 특정 구성 인수를 지원하는 기능이 GitLab 15.6에서 폐기 예정되었으며, GitLab 18.0에서 제거될 예정입니다. 인증 토큰 대신 사용해야 합니다. 자세한 내용은 새 러너 등록 워크플로로 마이그레이션을 참조하십시오.

프로젝트의 등록 토큰이 노출되었다고 생각된다면 재설정하세요. 등록 토큰은 프로젝트에 다른 러너를 등록하는 데 사용될 수 있습니다. 그 새 러너를 사용하여 비밀 변수의 값이나 프로젝트 코드를 복제할 수 있습니다.

등록 토큰을 재설정하려면:

1. 왼쪽 사이드바에서 검색 또는 이동하여 프로젝트를 찾습니다.
2. 설정 > CI/CD를 선택합니다.
3. 러너를 확장합니다.
4. 새 프로젝트 러너 옆의 수직 엘리시스()를 선택합니다.
5. 등록 토큰 재설정을 선택합니다.
6. 토큰 재설정을 선택합니다.

러너 등록 토큰을 재설정하면 이제 더는 유효하지 않으며 새로운 러너를 프로젝트에 등록하지 않습니다. 또한, 새 값들을 프로비저닝하고 등록하는 데 사용하는 도구에서 등록 토큰을 업데이트해야 합니다.

인증 토큰 보안

• GitLab 15.3에서 도입되었습니다. 기본적으로 비활성화된 enforce_runner_token_expires_at라는 플래그로 도입되었습니다.
• GitLab 15.5에서 일반적으로 사용 가능합니다. 기능 플래그 enforce_runner_token_expires_at가 제거되었습니다.

각 러너는 GitLab 인스턴스에 연결하고 인증하는 데 러너 인증 토큰을 사용합니다.

토큰이 노출되는 것을 방지하기 위해, 일정 간격으로 토큰이 자동으로 회전하도록 설정할 수 있습니다. 토큰이 회전되면 러너의 상태(온라인 또는 오프라인)에 관계없이 각 러너에 대해 업데이트됩니다.

수동 개입이 필요하지 않으며 실행 중인 작업에 영향을 미치지 않아야 합니다. 토큰 회전에 대한 자세한 내용은 러너 인증 토큰이 회전되었을 때 업데이트되지 않음을 참조하십시오.

러너 인증 토큰을 수동으로 업데이트해야 하는 경우, 토큰 재설정 명령을 실행할 수 있습니다.

러너 구성 인증 토큰 재설정

러너의 인증 토큰이 노출된 경우, 공격자가 해당 토큰을 사용하여 러너를 복제할 수 있습니다.

러너 구성 인증 토큰을 재설정하려면:

1. 러너를 삭제합니다:
   • 인스턴스 러너 삭제.
   • 그룹 러너 삭제.
   • 프로젝트 러너 삭제.
2. 새 러너를 만들어 새 러너 인증 토큰이 할당되도록 합니다:
   • 인스턴스 러너 만들기.
   • 그룹 러너 만들기.
   • 프로젝트 러너 만들기.
3. 선택 사항. 이전 러너 인증 토큰이 폐기되었는지 확인하려면 러너 API를 사용합니다.

러너 인증 토큰 자동 회전

러너 인증 토큰을 주기적으로 회전할 수 있습니다. 러너 인증 토큰을 정기적으로 회전시킴으로써 무단 액세스 가능성을 최소화할 수 있습니다.

전제 조건:

• 러너가 GitLab Runner 15.3 이상을 사용해야 합니다.
• 관리자여야 합니다.

러너 인증 토큰을 자동으로 회전하려면:

1. 왼쪽 사이드바에서 가장 아래쪽에서 관리자를 선택합니다.
2. Settings > CI/CD를 선택합니다.
3. Continuous Integration and Deployment를 확장합니다.
4. 러너의 만료 시간을 설정하고 만료되지 않도록 비워둡니다.
5. 변경 사항 저장을 선택합니다.

만료 시간이 지나기 전에 러너는 자동으로 새 러너 인증 토큰을 요청합니다. 토큰 회전에 대한 자세한 내용은 러너 인증 토큰이 회전되었을 때 업데이트되지 않음을 참조하십시오.

러너가 민감한 정보를 노출하지 않도록 방지하기

러너가 민감한 정보를 노출하지 않도록 하려면, 그들이 보호된 브랜치에서만 작업을 실행하도록 구성하거나 보호된 태그에서 작업해야 합니다.

보호된 브랜치에서만 작업을 실행하도록 구성된 러너는 병합 요청 파이프라인에서 작업을 실행할 수 없습니다.

인스턴스 러너의 경우

전제 조건:

• 관리자여야 합니다.

1. 왼쪽 사이드바에서 가장 아래쪽에서 관리자를 선택합니다.
2. CI/CD > 러너를 선택합니다.
3. 보호할 러너 오른쪽에서 편집()을 선택합니다.
4. 보호됨 확인란을 선택합니다.
5. 변경 사항 저장을 선택합니다.

그룹 러너용

전제 조건:

• 그룹에 대한 소유자 역할이 있어야 합니다.

1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 빌드 > 러너를 선택합니다.
3. 보호하려는 러너 오른쪽에서 편집 ()을 선택합니다.
4. 보호됨 확인란을 선택합니다.
5. 변경 사항 저장을 선택합니다.

프로젝트 러너용

전제 조건:

• 프로젝트에 대한 소유자 역할이 있어야 합니다.

1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 설정 > CI/CD를 선택합니다.
3. 러너를 확장합니다.
4. 보호하려는 러너 오른쪽에서 편집 ()을 선택합니다.
5. 보호됨 확인란을 선택합니다.
6. 변경 사항 저장을 선택합니다.

러너가 실행할 수 있는 작업 제어

태그를 사용하여 러너가 실행할 수 있는 작업을 제어할 수 있습니다.
예를 들어, rails 태그를 지정하여 Rails 테스트 스위트를 실행할 수 있는 의존성을 가진 러너를 지정할 수 있습니다.

GitLab CI/CD 태그는 Git 태그와 다릅니다. GitLab CI/CD 태그는 러너와 연결되어 있습니다.
Git 태그는 커밋과 연결되어 있습니다.

인스턴스 러너용

전제 조건:

• 관리자여야 합니다.

인스턴스 러너가 실행할 수 있는 작업을 제어하려면 다음을 수행합니다:

1. 왼쪽 사이드바에서 맨 아래에서 관리자를 선택합니다.
2. CI/CD > 러너를 선택합니다.
3. 편집하려는 러너 오른쪽에서 편집 ()을 선택합니다.
4. 러너를 태그가 지정된 작업 또는 태그가 없는 작업을 실행하도록 설정합니다:
   • 태그가 지정된 작업을 실행하려면 태그 필드에 쉼표로 구분된 작업 태그를 입력합니다. 예: macos, rails.
   • 태그가 지정되지 않은 작업을 실행하려면 태그가 지정되지 않은 작업 실행 확인란을 선택합니다.
5. 변경 사항 저장을 선택합니다.

그룹 러너용

전제 조건:

• 그룹에 대한 소유자 역할이 있어야 합니다.

그룹 러너가 실행할 수 있는 작업을 제어하려면 다음을 수행합니다:

1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 그룹을 찾습니다.
2. 빌드 > 러너를 선택합니다.
3. 편집하려는 러너 오른쪽에서 편집 ()을 선택합니다.
4. 러너를 태그가 지정된 작업 또는 태그가 지정되지 않은 작업을 실행하도록 설정합니다:
   • 태그가 지정된 작업을 실행하려면 태그 필드에 쉼표로 구분된 작업 태그를 입력합니다. 예: macos, ruby.
   • 태그가 지정되지 않은 작업을 실행하려면 태그가 지정되지 않은 작업 실행 확인란을 선택합니다.
5. 변경 사항 저장을 선택합니다.

프로젝트 러너용

전제 조건:

• 프로젝트에 대한 소유자 역할이 있어야 합니다.

프로젝트 러너가 실행할 수 있는 작업을 제어하려면 다음을 수행합니다:

1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
2. 설정 > CI/CD를 선택합니다.
3. 러너를 확장합니다.
4. 편집하려는 러너 오른쪽에서 편집 ()을 선택합니다.
5. 러너를 태그가 지정된 작업 또는 태그가 지정되지 않은 작업을 실행하도록 설정합니다:
   • 태그가 지정된 작업을 실행하려면 태그 필드에 쉼표로 구분된 작업 태그를 입력합니다. 예: macos, ruby.
   • 태그가 지정되지 않은 작업을 실행하려면 태그가 지정되지 않은 작업 실행 확인란을 선택합니다.
6. 변경 사항 저장을 선택합니다.

러너가 태그를 사용하는 방법

러너가 지정된 작업만 실행

다음 예제는 러너가 지정된 작업만 실행하도록 설정했을 때의 잠재적인 영향을 보여줍니다.

예제 1:

1. 러너가 지정된 작업만 실행하도록 설정되어 있고 docker 태그가 있습니다.
2. hello 태그가 있는 작업이 실행되어 멈춥니다.

예제 2:

1. 러너가 지정된 작업만 실행하도록 설정되어 있고 docker 태그가 있습니다.
2. docker 태그가 있는 작업이 실행되어 실행됩니다.

예제 3:

1. 러너가 지정된 작업만 실행하도록 설정되어 있고 docker 태그가 있습니다.
2. 태그가 정의되지 않은 작업이 실행되어 멈춥니다.

러너가 태그가 지정되지 않은 작업을 실행할 수 있는 경우

다음 예제는 러너가 태그가 지정되지 않은 작업을 실행할 수 있는 경우의 잠재적인 영향을 보여줍니다.

예제 1:

1. 러너가 태그가 지정되지 않은 작업을 실행하도록 설정되어 있고 docker 태그가 있습니다.
2. 태그가 정의되지 않은 작업이 실행되어 실행됩니다.
3. 태그가 정의되지 않은 작업이 실행되어 docker 태그가 정의되어 있습니다.

예제 2:

1. 러너가 태그가 지정되지 않은 작업을 실행하도록 설정되어 있고 태그가 정의되지 않았습니다.
2. 태그가 정의되지 않은 작업이 실행되어 실행됩니다.
3. 태그가 정의되지 않은 작업이 실행되어 docker 태그가 정의되어 있습니다.

러너와 작업에 여러 태그가 있는 경우

러너와 작업의 선택 논리는 작업 스크립트 블록에서 정의된 tags 목록을 기반으로 합니다. 러너가 작업을 실행할 수 있도록 선택하려면 작업 스크립트 블록에서 정의된 모든 태그를 가져야 합니다.

다음 예제는 러너와 작업에 여러 태그가 있는 경우의 영향을 보여줍니다. 러너가 작업을 실행하려면 작업 스크립트 블록에서 정의된 모든 태그를 가져야 합니다.

예제 1:

1. 러너는 [docker, shell, gpu] 태그로 구성되어 있습니다.
2. 작업은 [docker, shell, gpu] 태그를 가지고 있어 실행되어 실행됩니다.

예제 2:

1. 러너는 [docker, shell, gpu] 태그로 구성되어 있습니다.
2. 작업은 [docker, shell,] 태그를 가지고 있어 실행되어 실행됩니다.

예제 3:

1. 러너는 [docker, shell] 태그로 구성되어 있습니다.
2. 작업은 [docker, shell, gpu] 태그를 가지고 있어 실행되어 실행되지 않습니다.

다른 플랫폼에서 작업 실행을 위해 태그 사용

태그를 사용하여 다른 플랫폼에서 작업을 실행할 수 있습니다.
예를 들어, osx 태그를 가진 OS X 러너와 windows 태그를 가진 Windows 러너가 있다면 각 플랫폼에서 작업을 실행할 수 있습니다.

.gitlab-ci.yml의 tags 필드를 업데이트합니다:

windows job:
  stage: build
  tags:
    - windows
  script:
    - echo Hello, %USERNAME%!

osx job:
  stage: build
  tags:
    - osx
  script:
    - echo "Hello, $USER!"

CI/CD 변수를 태그에서 사용

.gitlab-ci.yml 파일에서 tags와 함께 CI/CD 변수를 사용하여 동적 러너 선택에 대해 구성하세요:

variables:
  KUBERNETES_RUNNER: kubernetes

  job:
    tags:
      - docker
      - $KUBERNETES_RUNNER
    script:
      - echo "Hello runner selector feature"

변수로 러너 동작 구성

전역적으로 또는 개별 작업에 대해 러너 Git 동작을 구성하는 데 CI/CD 변수를 사용할 수 있습니다:

• GIT_STRATEGY
• GIT_SUBMODULE_STRATEGY
• GIT_CHECKOUT
• GIT_CLEAN_FLAGS
• GIT_FETCH_EXTRA_FLAGS
• GIT_SUBMODULE_UPDATE_FLAGS
• GIT_SUBMODULE_FORCE_HTTPS
• GIT_DEPTH (얕은 클론)
• GIT_SUBMODULE_DEPTH
• GIT_CLONE_PATH (사용자 정의 빌드 디렉터리)
• TRANSFER_METER_FREQUENCY (아티팩트/캐시 미터 업데이트 주기)
• ARTIFACT_COMPRESSION_LEVEL (아티팩트 압축 수준)
• CACHE_COMPRESSION_LEVEL (캐시 압축 수준)
• CACHE_REQUEST_TIMEOUT (캐시 요청 시간 초과)
• RUNNER_SCRIPT_TIMEOUT
• RUNNER_AFTER_SCRIPT_TIMEOUT
• AFTER_SCRIPT_IGNORE_ERRORS

또한 러너가 작업 실행의 특정 단계를 시도하는 횟수를 구성할 때 변수를 사용할 수 있습니다.

Kubernetes 실행기를 사용할 때, Kubernetes CPU 및 메모리 할당을 재정의하기 위해 변수를 사용할 수 있습니다.

Git 전략

GIT_STRATEGY 변수는 빌드 디렉터리가 준비되고 저장소 내용이 검색되는 방식을 구성합니다. 이 변수를 전역적으로 또는 작업당 설정할 수 있으며, 이는 variables 섹션에서 설정됩니다.

variables:
  GIT_STRATEGY: clone

가능한 값은 clone, fetch, none, empty입니다. 값을 지정하지 않으면 작업은 프로젝트의 파이프라인 설정을 사용합니다.

clone은 가장 느린 옵션입니다. 모든 작업에 대해 저장소를 처음부터 복제하여 로컬 작업 복사본이 항상 원래 상태임을 보장합니다. 기존 작업트리를 발견하면 복제 전에 제거합니다.

fetch는 로컬 작업 복사본을 재사용하기 때문에 더 빠릅니다 (clone이 존재하지 않으면 다시 clone으로 돌아갑니다). git clean은 마지막 작업에서 발생한 모든 변경을 취소하고, git fetch는 마지막 작업 이후에 만들어진 커밋을 검색하는 데 사용됩니다.

그러나 fetch는 이전 작업트리에 액세스해야 합니다. 이는 shell 또는 docker 실행기를 사용할 때 잘 작동합니다. 이러한 실행기는 작업 트리를 보존하려고 시도하고 기본적으로 재사용합니다.

이는 Docker Machine 실행기를 사용할 때 제한이 있습니다.

none Git 전략은 로컬 작업 복사본을 재사용하지만 일반적으로 GitLab에서 수행하는 모든 Git 작업을 건너뜁니다. GitLab 러너 사전 클론 스크립트도 건너뜁니다(제공되는 경우). 이 전략은 .gitlab-ci.yml 스크립트에 fetch 및 checkout 명령을 추가해야 할 수 있음을 의미할 수 있습니다.

이는 배포 작업과 같이 아티팩트에 독점적으로 작용하는 작업에 사용할 수 있습니다. Git 저장소 데이터는 존재할 수 있지만 최신 상태가 아닐 수 있습니다. 로컬 작업 복사본에 캐시나 아티팩트로 가져온 파일에만 의존해야 하며, 이전 파이프라인에서 가져온 캐시와 아티팩트 파일이 여전히 존재할 수 있음을 인식해야 합니다.

empty Git 전략은 전용 빌드 디렉터리를 삭제한 다음 캐시 또는 아티팩트 파일을 다운로드하기 전에 다시 만듭니다. 이 전략을 사용하여 GitLab 러너 후크 스크립트가 여전히 실행되도록 함으로써 추가 동작을 사용할 수 있습니다. job이 실행될 때마다 깨끗하고 제어된 또는 사용자 정의된 시작 상태를 원할 때 empty Git 전략을 사용합니다.

• 저장소 데이터가 필요하지 않은 경우
• 작업이 실행될 때마다 깨끗하고 제어된 또는 사용자 정의된 시작 상태를 원하는 경우

서브모듈 Git 전략

GIT_SUBMODULE_STRATEGY 변수는 빌드 전에 코드 가져오기 시 Git 서브모듈 포함 여부/방식을 제어하는 데 사용됩니다. 이는 variables 섹션에서 모든 작업에 대해 전역적으로 또는 사용할 수 있습니다.

세 가지 가능한 값이 있습니다: none, normal, recursive:

• none은 프로젝트 코드를 가져올 때 서브모듈이 포함되지 않음을 의미합니다. 이것이 기본값이며, v1.10 이전 동작과 일치합니다.

• normal은 최상위 서브모듈만 포함됩니다. 다음에 해당됩니다.

  git submodule sync
  git submodule update --init
  

• recursive는 모든 서브모듈(서브모듈의 서브모듈 포함)이 포함됩니다. 이 기능은 Git v1.8.1 이후에 필요합니다. Docker에 기반하지 않은 GitLab 러너를 사용할 때 Git 버전이 해당 요구 사항을 충족하는지 확인하십시오. 다음에 해당됩니다.

  git submodule sync --recursive
  git submodule update --init --recursive
  

이 기능이 올바르게 작동하려면 서브모듈은 다음 중 하나로 구성되어야 합니다.

• 공개 액세스가 가능한 리포지토리의 HTTP(S) URL 또는
• GitLab 서버의 다른 리포지토리에 대한 상대적인 경로. Git 서브모듈 설명서를 참조하십시오.

GIT_SUBMODULE_UPDATE_FLAGS를 사용하여 고급 동작을 제어하는 추가 플래그를 제공할 수 있습니다.

Git 체크아웃

GIT_CHECKOUT 변수는 GIT_STRATEGY가 clone 또는 fetch로 설정되어 있을 때 git checkout을 실행할지 여부를 지정하는 데 사용할 수 있습니다. 지정하지 않으면 기본값은 true입니다. 이는 variables 섹션에서 전역적으로 또는 작업당 설정할 수 있습니다.

false로 설정된 경우 러너:

• ‘fetch’를 수행할 때 - 저장소를 업데이트하고 현재 리비전을 작업 복사본에 유지합니다.
• ‘clone’를 수행할 때 - 저장소를 복제하고 작업 복사본을 기본 브랜치에 유지합니다.

GIT_CHECKOUT이 true로 설정되어 있으면 clone과 fetch가 동일하게 작동합니다. 러너는 CI 파이프라인과 관련된 리비전의 작업 복사본을 체크아웃합니다.

variables:
  GIT_STRATEGY: clone
  GIT_CHECKOUT: "false"
script:
  - git checkout -B master origin/master
  - git merge $CI_COMMIT_SHA

Git clean 플래그

GIT_CLEAN_FLAGS 변수는 소스를 체크아웃한 후 git clean의 기본 동작을 제어하는 데 사용됩니다. 전역으로 설정하거나 variables 섹션에서 작업별로 설정할 수 있습니다.

GIT_CLEAN_FLAGS는 git clean 명령어의 모든 옵션을 허용합니다.

GIT_CHECKOUT: "false"가 지정된 경우 git clean이 비활성화됩니다.

만약 GIT_CLEAN_FLAGS가:

• 지정되지 않으면 git clean 플래그는 기본적으로 -ffdx로 설정됩니다.
• none 값을 가지면 git clean이 실행되지 않습니다.

예를 들어:

variables:
  GIT_CLEAN_FLAGS: -ffdx -e cache/
script:
  - ls -al cache/

Git fetch 추가 플래그

GIT_FETCH_EXTRA_FLAGS 변수를 사용하여 git fetch의 동작을 제어할 수 있습니다. 전역으로 설정하거나 variables 섹션에서 작업별로 설정할 수 있습니다.

GIT_FETCH_EXTRA_FLAGS는 git fetch 명령어의 모든 옵션을 허용합니다. 그러나 GIT_FETCH_EXTRA_FLAGS 플래그는 수정할 수 없는 기본 플래그 뒤에 추가됩니다.

기본 플래그는 다음과 같습니다:

• GIT_DEPTH.
• refspecks 목록
• origin이라는 원격 저장소

만약 GIT_FETCH_EXTRA_FLAGS가:

• 지정되지 않으면 git fetch 플래그는 기본적으로 --prune --quiet와 함께 기본 플래그가 설정됩니다.
• none 값을 가지면 git fetch가 기본 플래그만으로 실행됩니다.

예를 들어, 기본 플래그가 --prune --quiet이므로 이를 --prune으로 재정의하여 git fetch를 더 자세하게 만들 수 있습니다:

variables:
  GIT_FETCH_EXTRA_FLAGS: --prune
script:
  - ls -al cache/

위의 구성은 git fetch가 다음과 같이 호출되도록 합니다:

git fetch origin $REFSPECS --depth 50  --prune

여기서 $REFSPECS는 GitLab에서 러너에게 내부적으로 제공된 값입니다.

CI 작업에서 특정 서브모듈 동기화 또는 제외

• 소개됨 in GitLab Runner 14.0.

GIT_SUBMODULE_PATHS 변수를 사용하여 어떤 서브모듈을 동기화하거나 업데이트할지 제어할 수 있습니다. 전역으로 설정하거나 variables 섹션에서 작업별로 설정할 수 있습니다.

경로 구문은 git submodule와 같습니다:

• 특정 경로를 동기화하고 업데이트하려면:

  variables:
     GIT_SUBMODULE_PATHS: submoduleA submoduleB
  

• 특정 경로를 제외하려면:

  variables:
     GIT_SUBMODULE_PATHS: :(exclude)submoduleA :(exclude)submoduleB
  

경고: Git은 중첩된 경로를 무시합니다. 중첩된 서브모듈을 무시하려면 부모 서브모듈을 제외하고 해당 서브모듈을 작업 스크립트에서 수동으로 복제하세요. 예를 들어, git clone <repo> --recurse-submodules=':(exclude)nested-submodule'과 같이 문자열을 작은따옴표로 감싸 YAML이 성공적으로 구문 분석될 수 있도록 하세요.

서브모듈 업데이트 플래그

GIT_SUBMODULE_UPDATE_FLAGS 변수를 사용하여 GIT_SUBMODULE_STRATEGY가 normal 또는 recursive로 설정된 경우 git submodule update의 동작을 제어할 수 있습니다. 전역으로 설정하거나 variables 섹션에서 작업별로 설정할 수 있습니다.

GIT_SUBMODULE_UPDATE_FLAGS는 git submodule update 하위 명령어의 모든 옵션을 허용합니다. 그러나 GIT_SUBMODULE_UPDATE_FLAGS 플래그는 몇 가지 기본 플래그 뒤에 추가됩니다:

• --init, 만약 GIT_SUBMODULE_STRATEGY가 normal 또는 recursive로 설정되었을 경우
• --recursive, 만약 GIT_SUBMODULE_STRATEGY가 recursive로 설정되었을 경우
• GIT_DEPTH. 아래에서 기본값을 확인하세요.

Git은 인수 목록에서의 플래그의 마지막 발생을 존중하므로 GIT_SUBMODULE_UPDATE_FLAGS에서 수동으로 제공하는 경우 이러한 기본 플래그를 재정의할 수 있습니다.

이 변수를 사용하여 리포지토리에서 추적된 커밋 대신 최신 원격 HEAD를 가져오거나 서브모듈을 병렬로 가져와 체크아웃을 더 빠르게 할 수 있습니다:

variables:
  GIT_SUBMODULE_STRATEGY: recursive
  GIT_SUBMODULE_UPDATE_FLAGS: --remote --jobs 4
script:
  - ls -al .git/modules/

위의 구성은 git submodule update가 다음과 같이 호출되도록 합니다:

git submodule update --init --depth 50 --recursive --remote --jobs 4

경고: --remote 플래그를 사용할 때의 빌드의 보안, 안정성 및 재현성에 대한 영향을 인식해야 합니다. 대부분의 경우 설계된 대로 서브모듈 커밋을 명시적으로 추적하고 자동 치유/의존성 봇을 사용하여 업데이트하는 것이 좋습니다.

서브모듈 URL을 HTTPS로 재작성

• 소개됨 in GitLab Runner 15.11.

GIT_SUBMODULE_FORCE_HTTPS 변수를 사용하여 모든 Git 및 SSH 서브모듈 URL을 HTTPS로 재작성할 수 있습니다. 이를 통해 Git 또는 SSH 프로토콜로 구성되었더라도 절대 URL을 사용하는 동일한 GitLab 인스턴스에서 서브모듈을 클론할 수 있습니다.

variables:
  GIT_SUBMODULE_STRATEGY: recursive
  GIT_SUBMODULE_FORCE_HTTPS: "true"

활성화된 경우 GitLab 러너는 CI/CD 작업 토큰을 사용하여 작업을 실행하는 사용자의 권한으로 서브모듈을 복제하며 SSH 자격 증명이 필요하지 않습니다.

얕은 클론

GIT_DEPTH를 사용하여 가져오기 및 복제의 깊이를 지정할 수 있습니다. GIT_DEPTH는 저장소의 얕은 클론을 수행하며 복제를 크게 가속시킬 수 있습니다. 이는 커밋 수가 많거나 오래된 대형 이진 파일이 있는 저장소에 유용할 수 있습니다. 이 값은 git fetch 및 git clone에 전달됩니다.

새롭게 생성된 프로젝트는 자동으로 기본적으로 git depth 값이 50으로 설정됩니다.

깊이가 1로 설정되어 있고 작업 큐나 다시 시도하는 작업이 있는 경우 작업이 실패할 수 있습니다.

Git 가져오기와 클론은 브랜치 이름과 같은 ref에 기반하므로, 러너는 특정 커밋 SHA를 복제할 수 없습니다. 여러 작업이 대기 중이거나 오래된 작업을 다시 시도하는 경우, 테스트할 커밋은 복제된 Git 히스토리 내에 있어야 합니다. GIT_DEPTH에 너무 작은 값을 설정하면 이전 커밋을 실행하는 것이 불가능해지며 작업 로그에 unresolved reference가 표시됩니다. 따라서 GIT_DEPTH를 더 높은 값으로 변경하는 것을 다시 고려해야 합니다.

GIT_DEPTH가 설정된 경우 git describe를 필요로 하는 작업은 올바르게 작동하지 않을 수 있습니다. 이는 Git 히스토리의 일부만 존재하기 때문입니다.

마지막 3개의 커밋만 가져오거나 복제하려면:

variables:
  GIT_DEPTH: "3"

이를 전역적으로 설정하거나 variables 섹션에서 작업당으로 설정할 수 있습니다.

Git 서브모듈 깊이

• GitLab Runner 15.5에서 도입됨.

GIT_SUBMODULE_STRATEGY가 normal 또는 recursive로 설정된 경우, GIT_SUBMODULE_DEPTH 변수를 사용하여 서브모듈의 가져오기 및 복제 깊이를 지정할 수 있습니다. 이를 전역적으로 설정하거나 variables 섹션에서 특정 작업에 대해 설정할 수 있습니다.

GIT_SUBMODULE_DEPTH 변수를 설정하면 이는 서브모듈에 대해서만 GIT_DEPTH 설정을 덮어씁니다.

마지막 3개의 커밋만 가져오거나 복제하려면:

variables:
  GIT_SUBMODULE_DEPTH: 3

사용자 정의 빌드 디렉터리

기본적으로 GitLab 러너는 저장소를 $CI_BUILDS_DIR 디렉토리의 고유한 하위 경로에 복제합니다. 그러나 프로젝트에 따라 코드가 특정 디렉터리(Go 프로젝트 등)에 필요한 경우, 러너에게 저장소를 복제할 디렉토리를 알려주기 위해 GIT_CLONE_PATH 변수를 지정할 수 있습니다.

variables:
  GIT_CLONE_PATH: $CI_BUILDS_DIR/project-name

test:
  script:
    - pwd

GIT_CLONE_PATH는 항상 $CI_BUILDS_DIR 내에 있어야 합니다. $CI_BUILDS_DIR에서 설정된 디렉토리는 실행자와 runners.builds_dir 설정에 따라 종속됩니다.

이는 실행자의 runner 설정에서 custom_build_dir이 활성화된 경우에만 사용할 수 있습니다.

동시성 처리

동시성이 1보다 큰 실행자는 실패로 이어질 수 있습니다. 여러 작업이 동시에 실행되는 경우 builds_dir가 작업 간에 공유되기 때문입니다.

러너는 이러한 상황을 방지하려고 시도하지 않습니다. 실행자 구성의 요구 사항을 준수하는 것은 관리자와 개발자에게 달려 있습니다.

이러한 시나리오를 피하려면 $CI_BUILDS_DIR 내에서 고유한 경로를 사용할 수 있습니다. 왜냐하면 러너는 고유한 ID를 제공하는 두 가지 추가 변수를 노출하기 때문입니다:

• $CI_CONCURRENT_ID: 주어진 실행자 내에서 실행되는 모든 작업의 고유 ID입니다.
• $CI_CONCURRENT_PROJECT_ID: 주어진 실행자와 프로젝트 내에서 실행되는 모든 작업의 고유 ID입니다.

어떤 시나리오에서나 어떤 실행자에서든 잘 작동할 수 있는 가장 안정성 있는 구성은 GIT_CLONE_PATH에 $CI_CONCURRENT_ID를 사용하는 것입니다. 예를 들어:

variables:
  GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_CONCURRENT_ID/project-name

test:
  script:
    - pwd -P

$CI_CONCURRENT_PROJECT_ID는 $CI_PROJECT_PATH와 함께 사용되어야 합니다. 왜냐하면 $CI_PROJECT_PATH는 저장소의 경로를 제공하기 때문입니다. 즉, group/subgroup/project. 예를 들어:

variables:
  GIT_CLONE_PATH: $CI_BUILDS_DIR/$CI_CONCURRENT_ID/$CI_PROJECT_PATH

test:
  script:
    - pwd -P

중첩 경로

GIT_CLONE_PATH의 값은 한 번 확장되며 내부에 위치한 변수의 중첩은 지원되지 않습니다.

예를 들어, 다음과 같이 두 변수를 .gitlab-ci.yml 파일에 정의하는 경우:

variables:
  GOPATH: $CI_BUILDS_DIR/go
  GIT_CLONE_PATH: $GOPATH/src/namespace/project

GIT_CLONE_PATH의 값은 한 번 확장되어 $CI_BUILDS_DIR/go/src/namespace/project가 되며, $CI_BUILDS_DIR가 확장되지 않아 실패하게 됩니다.

after_script에서 오류 무시

작업에서 after_script를 사용하여 작업의 before_script 및 script 섹션 후에 실행되어야 하는 명령어 배열을 정의할 수 있습니다. after_script 명령은 스크립트 종료 상태(실패 또는 성공)에 관계없이 실행됩니다.

기본적으로 GitLab 러너는 after_script 실행 중 발생한 오류를 무시합니다. after_script 실행 중 오류가 발생하면 즉시 작업을 실패로 설정하려면 AFTER_SCRIPT_IGNORE_ERRORS CI/CD 변수를 false로 설정하세요. 예를 들어:

variables:
  AFTER_SCRIPT_IGNORE_ERRORS: false

작업 단계 시도

다음 단계를 수행하기로 하는 실행 중인 작업의 시도 횟수를 설정할 수 있습니다:

기본값은 하나의 단일 시도입니다.

예시:

variables:
  GET_SOURCES_ATTEMPTS: 3

전역적으로 설정하거나 variables 섹션에서 작업당으로 설정할 수 있습니다.

GitLab.com 인스턴스 러너에서 사용할 수 없는 시스템 호출

GitLab.com 인스턴스 러너는 CoreOS에서 실행됩니다. 이는 C 표준 라이브러리에서 getlogin과 같은 일부 시스템 호출을 사용할 수 없음을 의미합니다.

아티팩트 및 캐시 설정

아티팩트 및 캐시 설정은 아티팩트와 캐시의 압축률을 제어합니다. 이러한 설정을 사용하여 작업에서 생성된 아카이브의 크기를 지정할 수 있습니다.

• 느린 네트워크에서는 작은 아카이브의 업로드가 더 빨라질 수 있습니다.
• 대역폭과 저장 공간이 고려되지 않는 빠른 네트워크에서는 아카이브의 크기가 크더라도 최고의 압축률을 사용하는 것이 더 빠를 수 있습니다.

GitLab Pages에서 HTTP Range requests를 제공하기 위해 아티팩트는 ARTIFACT_COMPRESSION_LEVEL: fastest 설정을 사용해야 합니다. 이 설정은 압축되지 않은 zip 아카이브만 지원합니다.

미터를 활성화하여 업로드 및 다운로드의 전송 속도를 제공할 수 있습니다.

CACHE_REQUEST_TIMEOUT 설정으로 캐시 업로드 및 다운로드의 최대 시간을 설정할 수 있습니다. 이 설정은 캐시 업로드가 지연되어 작업의 수행 시간이 길어지는 경우 유용합니다.

variables:
  # 2초마다 업로드 및 다운로드 진행 상황 출력
  TRANSFER_METER_FREQUENCY: "2s"

  # 큰 아카이브를 생성하는 빠른 압축 사용
  ARTIFACT_COMPRESSION_LEVEL: "fast"

  # 캐시에 대한 압축 사용하지 않음
  CACHE_COMPRESSION_LEVEL: "fastest"

  # 캐시 업로드 및 다운로드의 최대 소요 시간 설정
  CACHE_REQUEST_TIMEOUT: 5

아티팩트 출처 메타데이터

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

런너는 모든 빌드 아티팩트에 대한 출처 메타데이터를 생성하고 제공할 수 있습니다.

아티팩트 출처 데이터를 활성화하려면 .gitlab-ci.yml 파일에서 RUNNER_GENERATE_ARTIFACTS_METADATA 환경 변수를 true로 설정하세요. 이 변수는 전역 또는 개별 작업에 대해 설정할 수 있습니다:

variables:
  RUNNER_GENERATE_ARTIFACTS_METADATA: "true"

job1:
  variables:
    RUNNER_GENERATE_ARTIFACTS_METADATA: "true"

메타데이터는 아티팩트와 함께 저장된 일반 텍스트 형식의 .json 파일로 렌더링됩니다. 파일 이름은 {ARTIFACT_NAME}-metadata.json 입니다. ARTIFACT_NAME은 .gitlab-ci.yml 파일에서 정의된 아티팩트의 이름입니다. 이름이 정의되지 않은 경우, 기본 파일 이름은 artifacts-metadata.json입니다.

출처 메타데이터 형식

출처 메타데이터는 in-toto attestation format에서 생성되었습니다. spec 버전 1.0을 사용합니다.

SLSA v1.0 문장을 사용하려면 .gitlab-ci.yml 파일에서 SLSA_PROVENANCE_SCHEMA_VERSION=v1 변수를 설정하세요.

다음 필드는 기본적으로 채워집니다:

GitLab 러너가 생성할 출처 메타데이터 예시:

{
 "_type": "https://in-toto.io/Statement/v0.1",
 "predicateType": "https://slsa.dev/provenance/v1",
 "subject": [
  {
   "name": "build/pico_w/wifi/blink/picow_blink.uf2",
   "digest": {
    "sha256": "f5a381a3fdf095a88fb928094f0e38cf269d226b07414369e8906d749634c090"
   }
  },
  {
   "name": "build/pico_w/wifi/blink/picow_blink.0.1.148-2-new-feature49.cosign.bundle",
   "digest": {
    "sha256": "f8762bf0b3ea1b88550b755323bf04417c2bbe9e50010cfcefc1fa877e2b52a6"
   }
  },
  {
   "name": "build/pico_w/wifi/blink/pico-examples-3a.0.1.148-2-new-feature49.tar.gz",
   "digest": {
    "sha256": "104674887da894443ab55918d81b0151dc7abb2472e5dafcdd78e7be71098af1"
   }
  },
  {
   "name": "build/pico_w/wifi/blink/pico-examples-3a.0.1.148-2-new-feature49.tar.gz.cosign.bundle",
   "digest": {
    "sha256": "33f3f7a19779a2d189dc03b420eb0be199a38404e8c1a24b2c8731bdfa3a30fb"
   }
  }
 ],
 "predicate": {
  "buildDefinition": {
   "buildType": "https://gitlab.com/gitlab-org/gitlab-runner/-/blob/761ae5dd/PROVENANCE.md",
   // 다른 모든 CI 변수 이름은 여기에 나열됩니다. 값은 항상 비밀을 유출하지 않고 SLSA를 준수하기 위해 비어 있습니다.
   "externalParameters": {
    "CI": "",
    ... // (중략)
   },
   "internalParameters": {
    "architecture": "amd64",
    "executor": "docker+machine",
    "job": "7211908025",
    "name": "green-6.saas-linux-small-amd64.runners-manager.gitlab.com/default"
   },
   "resolvedDependencies": [
    {
     "uri": "https://gitlab.com/dsanoy-demo/experiments/pico-examples-3a",
     "digest": {
      "sha256": "7e1aeac4e6c07138769b638d4926f429692d0124"
     }
    }
   ]
  },
  "runDetails": {
   "builder": {
    "id": "https://gitlab.com/dsanoy-demo/experiments/pico-examples-3a/-/runners/32976645",
    "version": {
     "gitlab-runner": "761ae5dd"
    }
   },
   "metadata": {
    "invocationID": "7211908025",
    "startedOn": "2024-06-28T09:56:44Z",
    "finishedOn": "2024-06-28T09:56:58Z"
   }
  }
 }
}

스테이징 디렉터리

• GitLab Runner 15.0에서 소개됨.

시스템의 기본 임시 디렉터리에 캐시 및 아티팩트를 보관하고 싶지 않은 경우 다른 디렉터리를 지정할 수 있습니다.

시스템의 기본 임시 경로에 제약이 있는 경우 디렉터리를 변경해야 할 수도 있습니다. 디렉터리 위치에 빠른 디스크를 사용하면 성능도 향상될 수 있습니다.

디렉터리를 변경하려면 CI 작업에서 변수로 ARCHIVER_STAGING_DIR를 설정하거나, 러너를 등록할 때 러너 변수를 사용하세요 (gitlab register --env ARCHIVER_STAGING_DIR=<dir>).

지정한 디렉터리는 아티팩트를 추출하기 전에 다운로드하는 위치로 사용됩니다. fastzip 아카이버를 사용하는 경우 이 위치는 아카이빙할 때 스크래치 공간으로도 사용됩니다.

성능 향상을 위해 fastzip 구성

• GitLab Runner 15.0에서 소개됨.

fastzip를 튜닝하려면 FF_USE_FASTZIP 플래그가 활성화되어 있는지 확인하세요. 그런 다음 다음 환경 변수 중 하나를 사용하세요.

zip 아카이브의 파일은 순차적으로 추가됩니다. 이는 동시 압축이 어렵게 만듭니다. fastzip는 파일을 디스크에 동시에 압축한 후 결과를 순차적으로 zip 아카이브에 복사하여 이 제한을 해결합니다.

더 작은 파일에 대해 디스크로 쓰고 내용을 다시 읽는 것을 피하려면, 각 동시성당 작은 버퍼가 사용됩니다. 이 설정은 FASTZIP_ARCHIVER_BUFFER_SIZE로 제어할 수 있습니다. 이 버퍼의 기본 크기는 2 MiB이며 따라서 16의 동시성은 32 MiB를 할당합니다. 버퍼 크기를 초과하는 데이터는 디스크로 쓰여지고 다시 읽힙니다. 따라서 버퍼 없이 FASTZIP_ARCHIVER_BUFFER_SIZE: 0를 사용하고 스크래치 공간만 사용하는 것도 올바른 옵션입니다.

FASTZIP_ARCHIVER_CONCURRENCY는 얼마나 많은 파일을 동시에 압축할지 제어합니다. 앞서 말한대로 이 설정은 얼마나 많은 메모리가 사용되는지와 같이 임시 데이터가 얼마나 많이 디스크에 쓰이는지를 증가시킬 수 있습니다. 기본값은 사용 가능한 CPU 수이지만 메모리에 대한 고려 사항 때문에 항상 최선의 설정은 아닐 수 있습니다.

FASTZIP_EXTRACTOR_CONCURRENCY는 한 번에 얼마나 많은 파일을 압축 해제할지 제어합니다. zip 아카이브의 파일은 원래 동시성에서 읽을 수 있기 때문에 압축 해제기가 요구하는 메모리에 추가로 할당되는 것은 없습니다. 기본값은 사용 가능한 CPU 수입니다.