GitLab은 CI/CD 구성을 더 쉽게 디버깅할 수 있도록 여러 도구를 제공합니다.

파이프라인 문제를 해결할 수 없는 경우 다음 곳에서 도움을 받을 수 있습니다:

• GitLab 커뮤니티 포럼
• GitLab 지원팀

특정 CI/CD 기능에 문제가 있는 경우 해당 기능의 관련 문제 해결 섹션을 참조하세요:

• 캐싱
• CI/CD 잡 토큰
• 컨테이너 레지스트리
• Docker
• 다운스트림 파이프라인
• 환경
• GitLab Runner
• ID 토큰
• 잡
• 잡 아티팩트
• 머지 요청 파이프라인 병합된 결과 파이프라인 및 머지 트레인
• 파이프라인 편집기
• 변수
• YAML includes 키워드
• YAML script 키워드

디버깅 기법#

구문 확인#

문제의 초기 원인이 잘못된 구문일 수 있습니다. 구문이나 형식 문제가 발견되면 파이프라인에 yaml invalid 배지가 표시되고 실행이 시작되지 않습니다.

파이프라인 편집기로 .gitlab-ci.yml 편집#

파이프라인 편집기는 권장되는 편집 환경입니다(단일 파일 편집기나 Web IDE보다 권장). 다음이 포함됩니다:

• 허용된 키워드만 사용하도록 보장하는 코드 완성 제안.
• 자동 구문 강조 및 유효성 검사.
• .gitlab-ci.yml 파일의 그래픽 표현인 CI/CD 구성 시각화.

.gitlab-ci.yml 로컬 편집#

로컬에서 파이프라인 구성을 편집하려면 편집기에서 GitLab CI/CD 스키마를 사용하여 기본 구문 문제를 확인할 수 있습니다. Schemastore 지원 편집기는 기본적으로 GitLab CI/CD 스키마를 사용합니다.

스키마에 직접 연결해야 하는 경우 다음 URL을 사용하세요:

https://gitlab.com/gitlab-org/gitlab/-/blob/master/app/assets/javascripts/editor/schema/ci.json

CI/CD 스키마가 커버하는 사용자 정의 태그의 전체 목록을 보려면 최신 버전의 스키마를 확인하세요.

CI Lint 도구로 구문 확인#

CI Lint 도구를 사용하여 CI/CD 구성 스니펫의 구문이 올바른지 확인할 수 있습니다. 전체 .gitlab-ci.yml 파일이나 개별 잡 구성을 붙여넣어 기본 구문을 확인합니다.

프로젝트에 .gitlab-ci.yml 파일이 있는 경우, CI Lint 도구를 사용하여 전체 파이프라인 생성을 시뮬레이션할 수도 있습니다. 이는 구성 구문에 대해 더 깊은 검증을 수행합니다.

파이프라인 이름 사용#

workflow:name을 사용하여 모든 파이프라인 유형에 이름을 지정하면 파이프라인 목록에서 파이프라인을 더 쉽게 식별할 수 있습니다. 예를 들면:

variables:
  PIPELINE_NAME: "Default pipeline name"

workflow:
  name: '$PIPELINE_NAME'
  rules:
    - if: '$CI_PIPELINE_SOURCE == "merge_request_event"'
      variables:
        PIPELINE_NAME: "Merge request pipeline"
    - if: '$CI_PIPELINE_SOURCE == "schedule" && $PIPELINE_SCHEDULE_TYPE == "hourly_deploy"'
      variables:
        PIPELINE_NAME: "Hourly deployment pipeline"
    - if: '$CI_PIPELINE_SOURCE == "schedule"'
      variables:
        PIPELINE_NAME: "Other scheduled pipeline"
    - if: '$CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH'
      variables:
        PIPELINE_NAME: "Default branch pipeline"
    - if: '$CI_COMMIT_BRANCH =~ /^\d{1,2}\.\d{1,2}-stable$/'
      variables:
        PIPELINE_NAME: "Stable branch pipeline"

CI/CD 변수#

변수 확인#

CI/CD 문제 해결의 핵심 부분은 파이프라인에 어떤 변수가 있는지, 그리고 해당 값이 무엇인지 확인하는 것입니다. 많은 파이프라인 구성이 변수에 의존하며, 변수를 확인하는 것이 문제의 원인을 찾는 가장 빠른 방법 중 하나입니다.

각 문제가 있는 잡에서 사용 가능한 변수의 전체 목록을 내보냅니다. 예상하는 변수가 있는지 확인하고, 해당 값이 예상대로인지 확인합니다.

변수를 사용하여 CLI 명령에 플래그 추가#

표준 파이프라인 실행에서는 사용되지 않지만 필요 시 디버깅에 사용할 수 있는 CI/CD 변수를 정의할 수 있습니다. 다음 예시처럼 변수를 추가하면 파이프라인 또는 개별 잡의 수동 실행 중에 추가하여 명령의 동작을 수정할 수 있습니다. 예를 들면:

my-flaky-job:
  variables:
    DEBUG_VARS: ""
  script:
    - my-test-command $DEBUG_VARS /test-dirs

이 예시에서 DEBUG_VARS는 표준 파이프라인에서 기본적으로 비어 있습니다. 잡의 동작을 디버깅해야 하는 경우 파이프라인을 수동으로 실행하고 DEBUG_VARS를 --verbose로 설정하여 추가 출력을 얻습니다.

의존성#

의존성 관련 문제도 파이프라인에서 예기치 않은 문제의 일반적인 원인입니다.

의존성 버전 확인#

잡에서 올바른 버전의 의존성이 사용되고 있는지 확인하려면 주요 스크립트 명령을 실행하기 전에 출력할 수 있습니다. 예를 들면:

job:
  before_script:
    - node --version
    - yarn --version
  script:
    - my-javascript-tests.sh

버전 고정#

항상 최신 버전의 의존성이나 이미지를 사용하고 싶을 수 있지만, 업데이트에는 예기치 않게 breaking changes가 포함될 수 있습니다. 예상치 못한 변경을 방지하기 위해 핵심 의존성과 이미지를 고정하는 것을 고려하세요. 예를 들면:

variables:
  ALPINE_VERSION: '3.18.6'

job1:
  image: alpine:$ALPINE_VERSION  # This will never change unexpectedly
  script:
    - my-test-script.sh

job2:
  image: alpine:latest  # This might suddenly change
  script:
    - my-test-script.sh

중요한 보안 업데이트가 있을 수 있으므로 의존성 및 이미지 업데이트를 정기적으로 확인해야 합니다. 그런 다음 업데이트된 이미지 또는 의존성이 파이프라인에서 여전히 작동하는지 확인하는 프로세스의 일부로 버전을 수동으로 업데이트할 수 있습니다.

잡 출력 확인#

출력을 상세히 표시#

잡 로그의 출력량을 줄이기 위해 --silent를 사용하면 잡에서 무엇이 잘못되었는지 파악하기 어려울 수 있습니다. 또한 가능한 경우 추가 세부 정보를 위해 --verbose를 사용하는 것을 고려하세요.

job1:
  script:
    - my-test-tool --silent         # If this fails, it might be impossible to identify the issue.
    - my-other-test-tool --verbose  # This command will likely be easier to debug.

출력 및 보고서를 아티팩트로 저장#

일부 도구는 잡 실행 중에만 필요한 파일을 생성할 수 있지만, 이 파일의 내용이 디버깅에 사용될 수 있습니다. artifacts를 사용하여 나중에 분석할 수 있도록 저장할 수 있습니다:

job1:
  script:
    - my-tool --json-output my-output.json
  artifacts:
    paths:
      - my-output.json

artifacts:reports로 구성된 보고서는 기본적으로 다운로드할 수 없지만 디버깅에 도움이 될 정보도 포함할 수 있습니다. 같은 기법을 사용하여 이러한 보고서를 검사할 수 있게 합니다:

job1:
  script:
    - rspec --format RspecJunitFormatter --out rspec.xml
  artifacts:
    reports:
      junit: rspec.xml
    paths:
      - rspec.xmp

로컬에서 잡 명령 실행#

Rancher Desktop이나 유사한 대안 도구를 사용하여 로컬 머신에서 잡의 컨테이너 이미지를 실행할 수 있습니다. 그런 다음 컨테이너에서 잡의 script 명령을 실행하고 동작을 확인합니다.

Root Cause Analysis로 실패한 잡 문제 해결#

GitLab Duo Chat의 GitLab Duo Root Cause Analysis를 사용하여 실패한 CI/CD 잡을 문제 해결할 수 있습니다.

잡 구성 문제#

많은 일반적인 파이프라인 문제는 파이프라인에 잡을 추가할 시점을 제어하는 데 사용되는 rules 또는 only/except 구성의 동작을 분석하여 해결할 수 있습니다. 이 두 구성을 같은 파이프라인에서 사용하면 안 됩니다. 이들은 다르게 동작합니다. 이렇게 혼합된 동작으로 파이프라인이 어떻게 실행되는지 예측하기 어렵습니다. only와 except는 더 이상 활발히 개발되지 않으므로 잡을 제어하기 위해 rules가 선호됩니다.

rules 또는 only/except 구성이 CI_PIPELINE_SOURCE, CI_MERGE_REQUEST_ID와 같은 사전 정의된 변수를 사용하는 경우, 첫 번째 문제 해결 단계로 해당 변수를 확인해야 합니다.

잡이나 파이프라인이 예상대로 실행되지 않음#

rules 또는 only/except 키워드는 잡이 파이프라인에 추가될지 여부를 결정합니다. 파이프라인이 실행되지만 잡이 파이프라인에 추가되지 않는 경우, 일반적으로 rules 또는 only/except 구성 문제로 인한 것입니다.

파이프라인이 오류 메시지 없이 전혀 실행되지 않는 경우, rules 또는 only/except 구성, 또는 workflow: rules 키워드로 인한 것일 수도 있습니다.

only/except에서 rules 키워드로 변환하는 경우, rules 구성 세부 정보를 신중하게 확인해야 합니다. only/except와 rules의 동작은 다르며 두 가지 사이를 마이그레이션할 때 예기치 않은 동작이 발생할 수 있습니다.

rules에 대한 일반적인 if 절은 예상대로 동작하는 규칙을 작성하는 방법에 대한 예시로 매우 도움이 됩니다.

파이프라인에 .pre 또는 .post 스테이지에만 잡이 있는 경우 실행되지 않습니다. 다른 스테이지에 적어도 하나의 잡이 있어야 합니다.

.gitlab-ci.yml 파일에 바이트 순서 표시(BOM)가 포함된 경우 예기치 않은 동작#

.gitlab-ci.yml 파일이나 포함된 다른 구성 파일에 UTF-8 바이트 순서 표시(BOM)가 있으면 잘못된 파이프라인 동작이 발생할 수 있습니다. 바이트 순서 표시는 파일 파싱에 영향을 미쳐 일부 구성이 무시될 수 있으며, 잡이 누락되거나 변수 값이 잘못될 수 있습니다. 일부 텍스트 편집기는 그렇게 구성된 경우 BOM 문자를 삽입할 수 있습니다.

파이프라인의 동작이 혼란스러운 경우 BOM 문자를 표시할 수 있는 도구로 BOM 문자의 존재를 확인할 수 있습니다. 파이프라인 편집기는 이 문자를 표시할 수 없으므로 외부 도구를 사용해야 합니다. 자세한 내용은 이슈 354026을 참조하세요.

changes 키워드가 있는 잡이 예기치 않게 실행됨#

파이프라인에 잡이 예기치 않게 추가되는 일반적인 이유는 특정 경우에 changes 키워드가 항상 true로 평가되기 때문입니다. 예를 들어, changes는 예약된 파이프라인 및 태그 파이프라인을 포함한 특정 파이프라인 유형에서 항상 true입니다.

changes 키워드는 only/except 또는 rules와 함께 사용됩니다. changes를 rules의 if 섹션이나 잡이 브랜치 파이프라인이나 머지 요청 파이프라인에만 추가되도록 보장하는 only/except 구성과 함께 사용하는 것이 좋습니다.

두 개의 파이프라인이 동시에 실행됨#

열린 머지 요청이 연결된 브랜치에 커밋을 푸시할 때 두 개의 파이프라인이 실행될 수 있습니다. 일반적으로 하나는 머지 요청 파이프라인이고 다른 하나는 브랜치 파이프라인입니다.

이 상황은 일반적으로 rules 구성으로 인해 발생하며, 중복 파이프라인 방지를 위한 몇 가지 방법이 있습니다.

파이프라인이 실행되지 않거나 잘못된 유형의 파이프라인이 실행됨#

파이프라인이 실행되기 전에 GitLab은 구성의 모든 잡을 평가하고 사용 가능한 모든 파이프라인 유형에 추가하려고 시도합니다. 평가가 끝날 때 파이프라인에 잡이 추가되지 않으면 파이프라인이 실행되지 않습니다.

파이프라인이 실행되지 않은 경우, 모든 잡에 파이프라인에 추가되는 것을 차단하는 rules 또는 only/except가 있을 가능성이 높습니다.

잘못된 파이프라인 유형이 실행된 경우, 잡이 올바른 파이프라인 유형에 추가되고 있는지 확인하기 위해 rules 또는 only/except 구성을 확인해야 합니다. 예를 들어, 머지 요청 파이프라인이 실행되지 않은 경우 잡이 대신 브랜치 파이프라인에 추가되었을 수 있습니다.

workflow: rules 구성이 파이프라인을 차단하거나 잘못된 파이프라인 유형을 허용했을 수도 있습니다.

풀 미러링을 사용하는 경우 풀 미러링 파이프라인 문제 해결 항목을 확인할 수 있습니다.

많은 잡이 있는 파이프라인이 시작에 실패함#

인스턴스에 정의된 CI/CD 제한보다 많은 잡이 있는 파이프라인은 시작에 실패합니다.

단일 파이프라인의 잡 수를 줄이려면 .gitlab-ci.yml 구성을 더 독립적인 부모-자식 파이프라인으로 분할할 수 있습니다.

파이프라인 경고#

파이프라인 구성 경고는 다음 경우에 표시됩니다:

• CI Lint 도구로 구성 유효성 검사.
• 파이프라인 수동 실행.

Job may allow multiple pipelines to run for a single action 경고#

if 절 없이 when 절과 함께 rules를 사용하면 여러 파이프라인이 실행될 수 있습니다. 일반적으로 이는 열린 머지 요청이 연결된 브랜치에 커밋을 푸시할 때 발생합니다.

중복 파이프라인 방지를 위해 workflow: rules를 사용하거나 어떤 파이프라인이 실행될 수 있는지 제어하기 위한 규칙을 다시 작성하세요.

파이프라인 오류#

오류: Identity verification is required in order to run CI jobs#

무료 플랜으로 GitLab.com에서 GitLab 호스팅 러너를 사용할 때 Identity verification is required in order to run CI jobs라는 오류 메시지가 표시되면 신원 확인을 완료해야 합니다.

이 요구 사항은 무료 컴퓨팅 리소스의 남용을 방지하는 데 도움이 됩니다. 위험 점수에 따라 이메일, 전화번호를 확인하거나 결제 방법을 추가해야 할 수 있습니다. 자세한 내용은 신원 확인을 참조하세요.

확인을 완료하려면:

1. 경고 배너에서 내 계정 확인을 선택합니다.
2. 프롬프트가 표시되면 신원 확인 단계를 따릅니다. 전화번호를 확인하거나 결제 방법을 추가해야 할 수 있습니다.
3. 새 커밋을 생성하거나 새 파이프라인을 수동으로 트리거합니다.

또는 다음을 수행할 수 있습니다:

• 유료 플랜으로 업그레이드합니다.
• 네임스페이스에 대한 추가 컴퓨팅 분을 구매합니다.
• GitLab 호스팅 러너 대신 프로젝트 또는 그룹 러너를 사용합니다.
• 그룹 소유자에게 자체 관리형 러너를 설정하도록 요청합니다.

A CI/CD pipeline must run and be successful before merge 메시지#

이 메시지는 프로젝트에서 파이프라인이 성공해야 함 설정이 활성화되어 있고 파이프라인이 아직 성공적으로 실행되지 않은 경우에 표시됩니다. 파이프라인이 아직 생성되지 않았거나 외부 CI 서비스를 기다리는 경우에도 적용됩니다.

프로젝트에 파이프라인을 사용하지 않는 경우, 머지 요청을 수락할 수 있도록 파이프라인이 성공해야 함을 비활성화해야 합니다.

Checking ability to merge automatically 메시지#

머지 요청에 몇 분이 지나도 사라지지 않는 Checking ability to merge automatically 메시지가 표시되면 다음 해결 방법 중 하나를 시도할 수 있습니다:

• 머지 요청 페이지를 새로 고침합니다.
• 머지 요청을 닫고 다시 엽니다.
• /rebase 빠른 작업으로 머지 요청을 리베이스합니다.
• 머지 요청이 병합 준비가 되었음을 이미 확인한 경우 /merge 빠른 작업으로 병합할 수 있습니다.

이 문제는 GitLab 15.5에서 해결되었습니다.

Checking pipeline status 메시지#

이 메시지는 머지 요청에 최신 커밋과 연결된 파이프라인이 아직 없을 때 회전 상태 아이콘([spinner])과 함께 표시됩니다. 다음과 같은 이유일 수 있습니다:

• GitLab이 아직 파이프라인 생성을 완료하지 않은 경우.
• 외부 CI 서비스를 사용하고 있으며 GitLab이 아직 해당 서비스의 응답을 받지 못한 경우.
• 프로젝트에서 CI/CD 파이프라인을 사용하지 않는 경우.
• 프로젝트에서 CI/CD 파이프라인을 사용하지만 구성으로 인해 머지 요청의 소스 브랜치에서 파이프라인이 실행되지 않은 경우.
• 최신 파이프라인이 삭제된 경우(이것은 알려진 문제입니다).
• 머지 요청의 소스 브랜치가 비공개 포크에 있는 경우.

파이프라인이 생성되면 메시지가 파이프라인 상태로 업데이트됩니다.

파이프라인이 성공해야 함 설정이 활성화된 경우 이러한 경우 중 일부에서 아이콘이 끝없이 회전하며 메시지가 멈출 수 있습니다. 자세한 내용은 이슈 334281을 참조하세요.

Project <group/project> not found or access denied 메시지#

이 메시지는 include로 구성이 추가되고 다음 중 하나에 해당하는 경우에 표시됩니다:

• 구성이 찾을 수 없는 프로젝트를 참조하는 경우.
• 파이프라인을 실행하는 사용자가 포함된 프로젝트에 접근할 수 없는 경우.

이를 해결하려면 다음을 확인하세요:

• 프로젝트 경로가 my-group/my-project 형식으로 되어 있고 저장소의 폴더가 포함되지 않는지 확인합니다.
• 파이프라인을 실행하는 사용자가 포함된 파일이 있는 프로젝트의 구성원인지 확인합니다. 사용자는 동일한 프로젝트에서 CI/CD 잡을 실행하는 권한도 있어야 합니다.

The parsed YAML is too big 메시지#

이 메시지는 YAML 구성이 너무 크거나 너무 깊게 중첩된 경우에 표시됩니다. 많은 수의 include와 전반적으로 수천 줄의 YAML 파일은 이 메모리 제한에 더 쉽게 도달합니다. 예를 들어, 200KB인 YAML 파일은 기본 메모리 제한에 도달할 가능성이 높습니다.

구성 크기를 줄이려면 다음을 수행할 수 있습니다:

• 파이프라인 편집기의 전체 구성 탭에서 확장된 CI/CD 구성의 길이를 확인합니다. 제거하거나 단순화할 수 있는 중복된 구성을 찾습니다.
• 긴 또는 반복된 script 섹션을 프로젝트의 독립 실행형 스크립트로 이동합니다.
• 부모 및 자식 파이프라인을 사용하여 일부 작업을 독립적인 자식 파이프라인의 잡으로 이동합니다.

GitLab Self-Managed에서는 크기 제한을 늘릴 수 있습니다.

.gitlab-ci.yml 파일 편집 시 500 오류#

포함된 구성 파일의 루프는 웹 편집기로 .gitlab-ci.yml 파일을 편집할 때 500 오류를 발생시킬 수 있습니다.

포함된 구성 파일이 서로에 대한 참조 루프를 생성하지 않는지 확인하세요.

Failed to pull image 메시지#

히스토리

• Allow access to this project with a CI_JOB_TOKEN 설정이 GitLab 16.3에서 Limit access to this project로 이름이 변경됨.

러너는 CI/CD 잡에서 컨테이너 이미지를 가져오려고 할 때 Failed to pull image 메시지를 반환할 수 있습니다.

러너는 다른 프로젝트의 컨테이너 레지스트리에서 image로 정의된 컨테이너 이미지를 가져올 때 CI/CD 잡 토큰으로 인증합니다.

잡 토큰 설정으로 인해 다른 프로젝트의 컨테이너 레지스트리에 대한 접근이 차단되면, 러너가 오류 메시지를 반환합니다.

예를 들면:

• WARNING: Failed to pull image with policy "always": Error response from daemon: pull access denied for registry.example.com/path/to/project, repository does not exist or may require 'docker login': denied: requested access to the resource is denied
  

• WARNING: Failed to pull image with policy "": image pull failed: rpc error: code = Unknown desc = failed to pull and unpack image "registry.example.com/path/to/project/image:v1.2.3": failed to resolve reference "registry.example.com/path/to/project/image:v1.2.3": pull access denied, repository does not exist or may require authorization: server message: insufficient_scope: authorization failed
  

이러한 오류는 다음이 모두 true인 경우에 발생할 수 있습니다:

• 이 프로젝트에 대한 접근 제한 옵션이 이미지를 호스팅하는 비공개 프로젝트에서 활성화된 경우.
• 이미지를 가져오려는 잡이 비공개 프로젝트의 허용 목록에 없는 프로젝트에서 실행 중인 경우.

이 문제를 해결하려면 컨테이너 레지스트리에서 이미지를 가져오는 CI/CD 잡이 있는 모든 프로젝트를 대상 프로젝트의 잡 토큰 허용 목록에 추가합니다.

이러한 오류는 다른 프로젝트의 이미지에 접근하기 위해 프로젝트 접근 토큰을 사용하려고 할 때도 발생할 수 있습니다. 프로젝트 접근 토큰은 하나의 프로젝트로 범위가 지정되므로 다른 프로젝트의 이미지에 접근할 수 없습니다. 더 넓은 범위의 다른 토큰 유형을 사용해야 합니다.

무작위 또는 간헐적인 Failed to pull image 오류#

CI/CD 잡에서 간헐적인 Failed to pull image 오류가 발생할 수 있습니다.

이 문제는 사용자가 이미지에 접근하는 다른 권한을 가지고 있는 경우, 러너가 이러한 이미지를 캐시하는 방식과 결합하여 발생할 수 있습니다. 봇 사용자는 다른 프로젝트 구성원과 다른 권한을 자주 가지므로 일반적으로 영향을 받습니다.

예를 들어, 파이프라인 이미지가 다른 프로젝트의 컨테이너 레지스트리에 호스팅되어 있을 수 있습니다. 모든 사용자가 두 프로젝트 모두에 접근할 수 있는 경우 이는 문제가 되지 않습니다. 그러나 사용자(봇 사용자 등)가 이미지를 호스팅하는 프로젝트에 접근할 수 없는 경우 Failed to pull image 오류가 발생할 수 있습니다.

러너가 이미지에 접근할 권한이 있는 사용자를 위해 이미지를 성공적으로 가져와 캐시하면 오류가 간헐적으로 발생합니다. 이 러너는 이제 이미지를 사용할 수 있으며 이미지를 가져오기 위해 다른 프로젝트에 접근할 필요가 없습니다. 다른 프로젝트에 접근할 수 없는 사용자를 포함하여 모든 사용자가 이 이미지로 CI/CD 잡을 실행할 수 있습니다. 그러나 러너가 이미지를 가져와 캐시한 적이 없는 경우, 이미지 프로젝트에 접근 권한이 없는 사용자는 Failed to pull image 오류가 발생합니다.

이 문제를 해결하려면 봇 사용자를 포함하여 파이프라인을 실행하는 모든 사용자가 가져오는 이미지를 호스팅하는 프로젝트에 접근할 수 있는지 확인하세요.

파이프라인 실행 시 Something went wrong on our end 메시지 또는 500 오류#

다음과 같은 파이프라인 오류가 발생할 수 있습니다:

• 푸시하거나 머지 요청을 생성할 때 Something went wrong on our end 메시지.
• API를 사용하여 파이프라인을 트리거할 때 500 오류.

이러한 오류는 프로젝트 가져오기 후 내부 ID 레코드가 동기화되지 않으면 발생할 수 있습니다.

이를 해결하려면 이슈 352382의 해결 방법을 참조하세요.

config should be an array of hashes 오류 메시지#

배열에서 여러 !reference 태그를 사용할 때 다음과 유사한 오류가 표시될 수 있습니다:

This GitLab CI configuration is invalid: jobs:my_job_name:parallel:matrix config should be an array of hashes.

script, rules, stages 키워드는 여러 참조 태그 사용을 지원하지만, 배열을 예상하는 다른 키워드는 그렇지 않습니다. 이 제한을 우회하기 위해 중첩을 사용하거나 대신 YAML 앵커를 사용할 수 있습니다.

오류: jobs:<job-name> config should contain either a trigger or a needs:pipeline.#

이 오류는 .gitlab-ci.yml의 잡이 needs 키워드를 사용하지만 script: 또는 trigger: 키워드를 사용하지 않을 때 발생할 수 있습니다.

모든 잡은 script 또는 trigger 키워드 중 하나를 사용해야 하므로, 둘 중 하나도 사용하지 않는 잡에 적절한 키워드를 추가하세요.

오류: config contains unknown keys: <key-name>#

<keyword> config contains unknown keys: <key-name>과 유사한 오류가 발생할 수 있습니다.

이 오류 메시지는 여러 가지 문제로 인해 발생할 수 있습니다:

• 키워드의 오타. 예: image(올바름) 대신 imag(잘못됨).
• 키워드나 잡의 잘못된 간격 또는 들여쓰기.

예를 들면:

test-job:
  artifacts:
    path:        # This is a typo, it should be `paths`
      - test
    image: test  # This indentation is incorrect, it should be at the same level as `script`.
  script:
    - echo