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

러너 구성

이 문서에서는 GitLab UI에서 러너를 구성하는 방법을 설명합니다.

GitLab Runner를 설치한 머신에서 러너를 구성해야 하는 경우,
GitLab Runner 문서를 참조하세요.

최대 작업 타임아웃 설정

각 러너에 대한 최대 작업 타임아웃을 지정할 수 있으며, 이는
더 긴 작업 타임아웃을 가진 프로젝트가 러너를 사용하는 것을 방지합니다.

최대 작업 타임아웃은 프로젝트에서 정의된 작업 타임아웃보다 짧은 경우에 사용됩니다.

러너의 최대 타임아웃을 설정하려면, REST API 엔드포인트 PUT /runners/:id에서 maximum_timeout 매개변수를 설정하세요.

인스턴스 러너의 경우

사전 조건:

• 관리자가 되어야 합니다.

자체 관리 GitLab 설치에서만 인스턴스 러너의 작업 타임아웃을 재정의할 수 있습니다.

GitLab.com에서는 GitLab 호스팅 인스턴스 러너의 작업 타임아웃을 재정의할 수 없으며,
대신 프로젝트 정의된 타임아웃을 사용해야 합니다.

최대 작업 타임아웃을 설정하려면:

1. 왼쪽 사이드바의 맨 아래에서 Admin을 선택합니다.
2. CI/CD > Runners를 선택합니다.
3. 수정하려는 러너의 오른쪽에서 Edit ()를 선택합니다.
4. Maximum job timeout 필드에 초 단위로 값을 입력합니다. 최소 값은 600초 (10분)입니다.
5. Save changes를 선택합니다.

그룹 러너의 경우

사전 조건:

• 그룹의 Owner 역할을 가져야 합니다.

최대 작업 타임아웃을 설정하려면:

1. 왼쪽 사이드바에서 Search or go to를 선택하고 그룹을 찾습니다.
2. Build > Runners를 선택합니다.
3. 수정하려는 러너의 오른쪽에서 Edit ()를 선택합니다.
4. Maximum job timeout 필드에 초 단위로 값을 입력합니다. 최소 값은 600초 (10분)입니다.
5. Save changes를 선택합니다.

프로젝트 러너의 경우

사전 조건:

• 프로젝트의 Owner 역할을 가져야 합니다.

최대 작업 타임아웃을 설정하려면:

1. 왼쪽 사이드바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. Settings > CI/CD를 선택합니다.
3. Runners를 확장합니다.
4. 수정하려는 러너의 오른쪽에서 Edit ()를 선택합니다.
5. Maximum job timeout 필드에 초 단위로 값을 입력합니다. 최소 값은 600초 (10분)입니다. 정의되지 않은 경우, 프로젝트의 작업 타임아웃이 대신 사용됩니다.
6. Save changes를 선택합니다.

최대 작업 타임아웃이 작동하는 방식

예제 1 - 러너 타임아웃이 프로젝트 타임아웃보다 큰 경우

1. 러너의 _최대 작업 타임아웃_을 24시간으로 설정합니다.
2. 프로젝트의 _CI/CD Timeout_을 2시간으로 설정합니다.
3. 작업을 시작합니다.
4. 작업이 더 오래 실행될 경우, 2시간 후에 타임아웃됩니다.

예제 2 - 러너 타임아웃이 구성되지 않은 경우

1. 러너에서 최대 작업 타임아웃 구성을 제거합니다.
2. 프로젝트의 _CI/CD Timeout_을 2시간으로 설정합니다.
3. 작업을 시작합니다.
4. 작업이 더 오래 실행될 경우, 2시간 후에 타임아웃됩니다.

예제 3 - 러너 타임아웃이 프로젝트 타임아웃보다 작은 경우

1. 러너의 _최대 작업 타임아웃_을 30분으로 설정합니다.
2. 프로젝트의 _CI/CD Timeout_을 2시간으로 설정합니다.
3. 작업을 시작합니다.
4. 작업이 더 오래 실행될 경우, 30분 후에 타임아웃됩니다.

script 및 after_script 타임아웃 설정

• GitLab Runner 16.4에 도입됨 Introduced.

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

예를 들어, 긴 실행 시간의 script를 조기에 종료할 수 있도록 타임아웃을 지정하여, 작업 타임아웃을 초과하기 전에 아티팩트와 캐시를 여전히 업로드할 수 있습니다.

• 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:
    - "나는 min(15m, 남은 작업 타임아웃) 만큼 실행할 수 있습니다."
  after_script:
    - "나는 min(10m, 남은 작업 타임아웃) 만큼 실행할 수 있습니다."

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

  artifacts: # 아티팩트는 대략 ~10분 동안 업로드할 수 있습니다.
    paths:
      - output.txt
    when: on_failure # 타임아웃 후 스크립트 종료는 실패로 간주되기 때문에 on_failure

민감한 정보 보호

인스턴스 러너를 사용할 때는 모든 그룹 및 프로젝트에 기본적으로 제공되므로 보안 위험이 더 큽니다. 사용되는 러너 실행기 및 파일 시스템에 따라 러너가 실행하는 코드와 러너 인증 토큰이 러너 호스트 환경에 접근할 수 있는 모든 사용자에게 노출될 수 있습니다.

예를 들어, 러너 인증 토큰에 접근할 수 있는 사용자는 이를 사용하여 러너의 복제본을 만들고 벡터 공격으로 잘못된 작업을 제출할 수 있습니다. 자세한 내용은 보안 고려사항을 참조하세요.

긴 폴링 구성

작업 대기 시간과 GitLab 서버의 부하를 줄이려면 긴 폴링을 구성하십시오.

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

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

알려진 문제로 인해, 포크된 프로젝트의 러너 설정이 새 프로젝트 네임스페이스와 일치하지 않으면 다음과 같은 메시지가 표시됩니다:

프로젝트를 포크하는 동안 오류가 발생했습니다. 다시 시도하십시오..

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

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

프로젝트에 대한 러너 등록 토큰 초기화 (사용 중단)

경고:

러너 등록 토큰을 전달하는 기능과 특정 구성 인수에 대한 지원이

사용 중단 되었으며 GitLab 15.6에서 제거될 예정입니다.

대신 인증 토큰을 사용해야 합니다. 자세한 내용은 새 러너 등록 워크플로로 마이그레이션을 참조하세요.

프로젝트의 등록 토큰이 노출되었다고 생각되면 초기화해야 합니다. 등록 토큰은 프로젝트에 대해 다른 러너를 등록하는 데 사용될 수 있습니다.

그 새 러너는 비밀 변수 값이나 프로젝트 코드를 클론하는 데 사용될 수 있습니다.

등록 토큰을 초기화하려면:

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

2. 설정 > CI/CD를 선택합니다.

3. 러너를 확장합니다.

4. 새 프로젝트 러너의 오른쪽에서 수직의 점 3개 ()를 선택합니다.

5. 등록 토큰 초기화를 선택합니다.

6. 토큰 초기화를 선택합니다.

등록 토큰을 초기화한 후에는 더 이상 유효하지 않으며 프로젝트에 새로운 러너를 등록하지 않습니다.

새 값을 프로비저닝하고 등록하는 데 사용하는 도구에서도 등록 토큰을 업데이트해야 합니다.

인증 토큰 보안

• 도입됨 GitLab 15.3에서 enforce_runner_token_expires_at라는 플래그와 함께. 기본적으로 비활성화됨.
• 일반적으로 사용 가능 GitLab 15.5에서. 기능 플래그 enforce_runner_token_expires_at 제거됨.

각 러너는 GitLab 인스턴스와 연결하고 인증하기 위해 러너 인증 토큰을 사용합니다.

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

수동 개입이 필요하지 않으며, 실행 중인 작업에는 영향을 주지 않아야 합니다.

토큰 _ROTATE_에 대한 자세한 내용은 러너 인증 토큰이 _ROTATE_될 때 업데이트되지 않음을 참조하세요.

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

러너 구성 인증 토큰 초기화

러너의 인증 토큰이 노출되면, 공격자가 이를 사용하여 러너 클론을 수행할 수 있습니다.

러너 구성 인증 토큰을 초기화하려면:

1. 러너를 삭제합니다:
   • 인스턴스 러너 삭제.
   • 그룹 러너 삭제.
   • 프로젝트 러너 삭제.
2. 새 러너를 생성하여 새로운 러너 인증 토큰을 할당받습니다:
   • 인스턴스 러너 생성.
   • 그룹 러너 생성.
   • 프로젝트 러너 생성.
3. 선택 사항. 이전 러너 인증 토큰이 취소되었는지 확인하려면 러너 API를 사용합니다.

자동으로 러너 인증 토큰 회전

러너 인증 토큰을 회전할 간격을 지정할 수 있습니다.

정기적으로 러너 인증 토큰을 회전하는 것은 손상된 토큰을 통한 GitLab 인스턴스의 무단 액세스 위험을 최소화하는 데 도움이 됩니다.

전제 조건:

• 러너는 GitLab Runner 15.3 이상을 사용해야 합니다.
• 관리자인 경우에만 가능합니다.

자동으로 러너 인증 토큰 회전하기:

1. 왼쪽 사이드바에서 맨 아래에 있는 관리자를 선택합니다.

2. 설정 > CI/CD를 선택합니다.

3. 지속적인 통합 및 배포를 펼칩니다.

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. 왼쪽 사이드바에서 Search or go to를 선택하고 그룹을 찾습니다.
2. Build > Runners를 선택합니다.
3. 편집하려는 러너의 오른쪽에서 Edit ()을 선택합니다.
4. 러너를 태그가 있는 작업 또는 태그가 없는 작업을 실행하도록 설정합니다:
   • 태그가 있는 작업을 실행하려면, Tags 필드에 작업 태그를 쉼표로 구분하여 입력합니다. 예를 들어, macos, ruby.
   • 태그가 없는 작업을 실행하려면, Run untagged jobs 체크박스를 선택합니다.
5. Save changes를 선택합니다.

프로젝트 러너를 위한

필수 조건:

• 프로젝트에 대한 소유자 역할을 가져야 합니다.

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

1. 왼쪽 사이드바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. Settings > CI/CD를 선택합니다.
3. Runners를 확장합니다.
4. 편집하려는 러너의 오른쪽에서 Edit ()을 선택합니다.
5. 러너를 태그가 있는 작업 또는 태그가 없는 작업을 실행하도록 설정합니다:
   • 태그가 있는 작업을 실행하려면, Tags 필드에 작업 태그를 쉼표로 구분하여 입력합니다. 예를 들어, macos, ruby.
   • 태그가 없는 작업을 실행하려면, Run untagged jobs 체크박스를 선택합니다.
6. Save changes를 선택합니다.

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

러너는 태그가 있는 작업만 실행

다음 예시는 러너가 태그가 있는 작업만 실행하도록 설정되었을 때의 잠재적 영향을 설명합니다.

예시 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"

변수로 러너 동작 구성

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

• 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으로 대체됨). git clean은 마지막 작업으로 인해 발생한 모든 변경 사항을 취소하는 데 사용되며, git fetch는 마지막 작업이 실행된 이후에 수행된 커밋을 가져오는 데 사용됩니다.

하지만 fetch는 이전 작업 트리에 대한 접근이 필요합니다. 이는 shell 또는 docker 실행기를 사용할 때 좋으며, 이러한 실행기는 기본적으로 작업 트리를 유지하려고 합니다.

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

none의 Git 전략도 로컬 작업 복사본을 재사용하지만 GitLab에서 일반적으로 수행하는 모든 Git 작업을 건너뜁니다. GitLab Runner의 사전 클론 스크립트도 존재할 경우 건너뛰게 됩니다. 이 전략은 아티팩트에서만 작업하는 작업, 예를 들어 배포 작업에 유용할 수 있습니다. Git 리포지토리 데이터가 존재할 수 있지만 오래된 데이터일 가능성이 높습니다. 캐시 또는 아티팩트에서 가져온 파일에만 의존해야 하며 이전 파이프라인에서의 캐시 및 아티팩트 파일이 여전히 존재할 수 있음을 인지해야 합니다.

none와 달리 empty Git 전략은 캐시 또는 아티팩트 파일을 다운로드하기 전에 전용 빌드 디렉토리를 삭제하고 다시 생성합니다. 이 전략을 사용하면 GitLab Runner 후크 스크립트가 여전히 실행됩니다(제공되는 경우) 추가 동작 사용자 지정을 허용합니다.

empty Git 전략을 사용해야 하는 경우는 다음과 같습니다:

• 리포지토리 데이터가 존재할 필요가 없습니다.
• 작업이 실행될 때마다 깨끗하고 제어된 또는 사용자 지정된 시작 상태가 필요합니다.

Git 서브모듈 전략

GIT_SUBMODULE_STRATEGY 변수는 빌드 전에 코드를 가져올 때 Git 서브모듈의 포함 여부와 방식을 제어하는 데 사용됩니다. 이 변수는 variables 섹션에서 전역적으로 또는 작업별로 설정할 수 있습니다.

가능한 값은 세 가지입니다: none, normal, recursive:

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

• normal은 최상위 서브모듈만 포함됨을 의미합니다. 이는 다음과 같습니다:

  git submodule sync
  git submodule update --init
  

• recursive는 모든 서브모듈(서브모듈의 서브모듈 포함)이 포함됨을 의미합니다. 이 기능은 Git v1.8.1 이상이 필요합니다. Docker를 기반으로 하지 않은 실행기를 사용하는 GitLab Runner를 사용할 경우, Git 버전이 해당 요건을 충족하는지 확인해야 합니다. 이는 다음과 같습니다:

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

이 기능이 제대로 작동하려면 서브모듈이 다음과 같이 구성되어 있어야 합니다 (.gitmodules 내에서):

• 공개적으로 접근 가능한 리포지토리의 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 클린 플래그

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의 동작을 제어하려면 GIT_FETCH_EXTRA_FLAGS 변수를 사용하십시오. 이 변수를 전역적으로 또는 각 작업의 variables 섹션에서 설정할 수 있습니다.

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

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

• GIT_DEPTH.
• refspecs의 목록.
• 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 작업에서 특정 서브모듈 동기화 또는 제외

• 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 서브모듈 업데이트 플래그

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로 다시 쓰기

• 도입됨 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 Runner는 권한을 가진 사용자로 하위 모듈을 클론하기 위해 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 describe에 의존하는 작업은 GIT_DEPTH가 설정되면 올바르게 작동하지 않을 수 있습니다. 왜냐하면 Git 기록의 일부만 존재하기 때문입니다.

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

variables:
  GIT_DEPTH: "3"

이는 전역적으로 설정할 수도 있고, variables 섹션에서 특정 작업에 대해 설정할 수도 있습니다.

Git 하위 모듈 깊이

• 도입됨 GitLab Runner 15.5에서.

GIT_SUBMODULE_DEPTH 변수를 사용하여 GIT_SUBMODULE_STRATEGY가 normal 또는 recursive로 설정될 때 하위 모듈을 가져오고 클론하는 깊이를 지정할 수 있습니다.

이는 전역적으로 설정할 수도 있고 특정 작업에 대해 variables 섹션에서 설정할 수도 있습니다.

GIT_SUBMODULE_DEPTH 변수를 설정하면 하위 모듈에 대해서만 GIT_DEPTH 설정이 덮어씌워집니다.

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

variables:
  GIT_SUBMODULE_DEPTH: 3

사용자 지정 빌드 디렉터리

기본적으로 GitLab Runner는 $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 설정 구성을 기반으로 합니다.

이는 러너 구성에서 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 Runner는 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 범위 요청을 제공하기 위해서는 아티팩트가 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에서 도입됨.

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

아티팩트 출처 데이터를 활성화하려면 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 attestations format에서 생성되며, 사양 버전은 1.0입니다.

SLSA v1.0 문서를 사용하려면 .gitlab-ci.yml 파일에 SLSA_PROVENANCE_SCHEMA_VERSION=v1 변수를 설정하십시오.

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

GitLab Runner가 생성할 수 있는 출처 메타데이터의 예시는 다음과 같습니다:

{
 "_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": "",
    "CI_API_GRAPHQL_URL": "",
    "CI_API_V4_URL": "",
    "CI_COMMIT_AUTHOR": "",
    "CI_COMMIT_BEFORE_SHA": "",
    "CI_COMMIT_BRANCH": "",
    "CI_COMMIT_DESCRIPTION": "",
    "CI_COMMIT_MESSAGE": "",
    "CI_COMMIT_REF_NAME": "",
    "CI_COMMIT_REF_PROTECTED": "",
    "CI_COMMIT_REF_SLUG": "",
    "CI_COMMIT_SHA": "",
    "CI_COMMIT_SHORT_SHA": "",
    "CI_COMMIT_TIMESTAMP": "",
    "CI_COMMIT_TITLE": "",
    "CI_CONFIG_PATH": "",
    "CI_DEFAULT_BRANCH": "",
    "CI_DEPENDENCY_PROXY_DIRECT_GROUP_IMAGE_PREFIX": "",
    "CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX": "",
    "CI_DEPENDENCY_PROXY_PASSWORD": "",
    "CI_DEPENDENCY_PROXY_SERVER": "",
    "CI_DEPENDENCY_PROXY_USER": "",
    "CI_JOB_ID": "",
    "CI_JOB_NAME": "",
    "CI_JOB_NAME_SLUG": "",
    "CI_JOB_STAGE": "",
    "CI_JOB_STARTED_AT": "",
    "CI_JOB_TOKEN": "",
    "CI_JOB_URL": "",
    "CI_NODE_TOTAL": "",
    "CI_OPEN_MERGE_REQUESTS": "",
    "CI_PAGES_DOMAIN": "",
    "CI_PAGES_URL": "",
    "CI_PIPELINE_CREATED_AT": "",
    "CI_PIPELINE_ID": "",
    "CI_PIPELINE_IID": "",
    "CI_PIPELINE_NAME": "",
    "CI_PIPELINE_SOURCE": "",
    "CI_PIPELINE_URL": "",
    "CI_PROJECT_CLASSIFICATION_LABEL": "",
    "CI_PROJECT_DESCRIPTION": "",
    "CI_PROJECT_ID": "",
    "CI_PROJECT_NAME": "",
    "CI_PROJECT_NAMESPACE": "",
    "CI_PROJECT_NAMESPACE_ID": "",
    "CI_PROJECT_PATH": "",
    "CI_PROJECT_PATH_SLUG": "",
    "CI_PROJECT_REPOSITORY_LANGUAGES": "",
    "CI_PROJECT_ROOT_NAMESPACE": "",
    "CI_PROJECT_TITLE": "",
    "CI_PROJECT_URL": "",
    "CI_PROJECT_VISIBILITY": "",
    "CI_REGISTRY": "",
    "CI_REGISTRY_IMAGE": "",
    "CI_REGISTRY_PASSWORD": "",
    "CI_REGISTRY_USER": "",
    "CI_REPOSITORY_URL": "",
    "CI_RUNNER_DESCRIPTION": "",
    "CI_RUNNER_ID": "",
    "CI_RUNNER_TAGS": "",
    "CI_SERVER_FQDN": "",
    "CI_SERVER_HOST": "",
    "CI_SERVER_NAME": "",
    "CI_SERVER_PORT": "",
    "CI_SERVER_PROTOCOL": "",
    "CI_SERVER_REVISION": "",
    "CI_SERVER_SHELL_SSH_HOST": "",
    "CI_SERVER_SHELL_SSH_PORT": "",
    "CI_SERVER_URL": "",
    "CI_SERVER_VERSION": "",
    "CI_SERVER_VERSION_MAJOR": "",
    "CI_SERVER_VERSION_MINOR": "",
    "CI_SERVER_VERSION_PATCH": "",
    "CI_TEMPLATE_REGISTRY_HOST": "",
    "COSIGN_YES": "",
    "DS_EXCLUDED_ANALYZERS": "",
    "DS_EXCLUDED_PATHS": "",
    "DS_MAJOR_VERSION": "",
    "DS_SCHEMA_MODEL": "",
    "GITLAB_CI": "",
    "GITLAB_FEATURES": "",
    "GITLAB_USER_EMAIL": "",
    "GITLAB_USER_ID": "",
    "GITLAB_USER_LOGIN": "",
    "GITLAB_USER_NAME": "",
    "GitVersion_FullSemVer": "",
    "GitVersion_LegacySemVer": "",
    "GitVersion_Major": "",
    "GitVersion_MajorMinorPatch": "",
    "GitVersion_Minor": "",
    "GitVersion_Patch": "",
    "GitVersion_SemVer": "",
    "RUNNER_GENERATE_ARTIFACTS_METADATA": "",
    "SAST_EXCLUDED_ANALYZERS": "",
    "SAST_EXCLUDED_PATHS": "",
    "SAST_IMAGE_SUFFIX": "",
    "SCAN_KUBERNETES_MANIFESTS": "",
    "SECRETS_ANALYZER_VERSION": "",
    "SECRET_DETECTION_EXCLUDED_PATHS": "",
    "SECRET_DETECTION_IMAGE_SUFFIX": "",
    "SECURE_ANALYZERS_PREFIX": "",
    "SIGSTORE_ID_TOKEN": "",
    "entryPoint": "create_generic_package",
    "source": "https://gitlab.com/dsanoy-demo/experiments/pico-examples-3a"
   },
   "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"
   }
  }
 }
}

in-toto 규격 준수를 확인하려면, in-toto 문서를 참조하십시오.

스테이징 디렉토리

• GitLab Runner 15.0에 도입됨 소개됨.

시스템의 기본 임시 디렉토리에 캐시와 아티팩트를 아카이브하고 싶지 않은 경우, 다른 디렉토리를 지정할 수 있습니다.

시스템의 기본 임시 경로에 제약이 있는 경우 디렉토리를 변경해야 할 수 있습니다.

디렉토리 위치에 빠른 디스크를 사용할 경우 성능을 개선할 수 있습니다.

디렉토리를 변경하려면 CI 작업에서 변수를 설정하거나 러너를 등록할 때 러너 변수를 사용하십시오 (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 수를 따릅니다.