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

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

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

특정 CI/CD 기능에 문제가 있다면 해당 기능의 관련 문제 해결 섹션을 참조합니다:

• 캐시
• CI/CD job 토큰
• 컨테이너 레지스트리
• Docker
• 다운스트림 파이프라인
• 환경
• GitLab Runner
• ID 토큰
• Job
• Job 아티팩트
• 머지 리퀘스트 파이프라인, 병합 결과 파이프라인, 머지 트레인
• 파이프라인 에디터
• 변수
• 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 파일이나 개별 job 설정을 붙여 넣어 기본 문법을 확인할 수 있습니다.

프로젝트에 .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 문제 해결에서 중요한 부분은 파이프라인에 어떤 변수가 존재하는지, 그 값이 무엇인지 확인하는 것입니다. 파이프라인 설정의 많은 부분이 변수에 의존하므로, 변수를 확인하는 것은 문제의 원인을 찾는 가장 빠른 방법 중 하나입니다.

문제가 있는 각 job에서 사용 가능한 변수의 전체 목록을 내보내십시오. 예상하는 변수가 존재하는지, 그 값이 예상한 대로인지 확인합니다.

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

표준 파이프라인 실행에서는 사용하지 않지만 필요할 때 디버깅용으로 사용할 수 있는 CI/CD 변수를 정의할 수 있습니다. 변수를 추가하면 파이프라인이나 개별 job을 수동으로 실행할 때 변수 값을 설정하여 명령의 동작을 수정할 수 있습니다. 예를 들면 다음과 같습니다:

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

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

의존성#

의존성 관련 문제는 파이프라인에서 예기치 않은 문제가 발생하는 또 다른 흔한 원인입니다.

의존성 버전 확인#

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

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

버전 고정#

의존성이나 이미지의 최신 버전을 항상 사용하고 싶을 수 있지만, 업데이트에는 예기치 않게 호환성을 깨는 변경 사항이 포함될 수 있습니다. 예상치 못한 변경을 피하려면 주요 의존성과 이미지를 고정하는 것을 고려합니다. 예를 들면 다음과 같습니다:

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

그럼에도 중요한 보안 업데이트가 있을 수 있으므로 의존성과 이미지 업데이트를 정기적으로 확인해야 합니다. 이후 업데이트된 이미지나 의존성이 파이프라인에서 여전히 정상 동작하는지 검증하는 과정을 거쳐 버전을 수동으로 업데이트할 수 있습니다.

Job 출력 확인#

출력을 상세하게 만들기#

--silent를 사용하면 job 로그의 출력량을 줄일 수 있습니다. 하지만 이로 인해 job에서 무엇이 잘못되었는지 파악하기 어려워질 수 있습니다. 가능하다면 --verbose 사용을 고려합니다. --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.

출력과 리포트를 아티팩트로 저장#

일부 도구는 job 이 실행되는 동안에만 필요한 파일을 생성하지만, 이러한 파일의 내용은 디버깅에 활용할 수 있습니다. 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

job의 명령을 로컬에서 실행#

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

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

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

Job 설정 문제#

흔히 발생하는 파이프라인 문제는 rules 또는 only/except 설정의 동작을 분석하면 대부분 해결할 수 있습니다. 이 설정은 job 이 파이프라인에 추가되는 시점을 제어하는 데 사용됩니다. 이 두 설정은 동작 방식이 다르므로 같은 파이프라인에서 함께 사용해서는 안 됩니다. 이렇게 혼용하면 파이프라인이 어떻게 실행될지 예측하기 어렵습니다. only와 except는 더 이상 적극적으로 개발되지 않으므로, job을 제어할 때는 rules 를 사용하는 것을 권장합니다.

rules 또는 only/except 설정에서 CI_PIPELINE_SOURCE, CI_MERGE_REQUEST_ID와 같은 사전 정의된 변수를 사용한다면, 첫 번째 문제 해결 단계로 해당 변수를 확인해야 합니다.

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

rules 또는 only/except 키워드는 job 이 파이프라인에 추가되는지 여부를 결정합니다. 파이프라인은 실행되지만 job 이 파이프라인에 추가되지 않는다면, 대개 rules 또는 only/except 설정 문제 때문입니다.

오류 메시지 없이 파이프라인이 전혀 실행되지 않는 것처럼 보인다면, 이 역시 rules 또는 only/except 설정이나 workflow: rules 키워드 때문일 수 있습니다.

only/except에서 rules 키워드로 전환하는 경우, rules 설정 세부 정보를 주의해서 확인해야 합니다. only/except와 rules의 동작 방식이 다르므로 둘 사이를 마이그레이션할 때 예기치 않은 동작이 발생할 수 있습니다.

rules에서 자주 사용하는 if 절은 원하는 대로 동작하는 규칙을 작성하는 방법의 예시로 매우 유용합니다.

파이프라인에 .pre 또는 .post Stage의 job만 있다면 파이프라인이 실행되지 않습니다. 다른 Stage에 최소 하나 이상의 job 이 있어야 합니다.

.gitlab-ci.yml 파일에 BOM(바이트 순서 표시)이 있을 때 발생하는 예기치 않은 동작#

.gitlab-ci.yml 파일이나 다른 include 된 설정 파일에 UTF-8 바이트 순서 표시(Byte-Order Mark, BOM)가 있으면 파이프라인이 잘못 동작할 수 있습니다. 바이트 순서 표시는 파일 파싱에 영향을 줍니다. 그 결과 일부 설정이 무시되거나, job 이 누락되거나, 변수 값이 잘못될 수 있습니다. 일부 텍스트 에디터는 설정에 따라 BOM 문자를 삽입할 수 있습니다.

파이프라인이 혼란스럽게 동작한다면, BOM 문자를 표시할 수 있는 도구로 BOM 문자가 있는지 확인할 수 있습니다. 파이프라인 에디터는 이 문자를 표시할 수 없으므로 외부 도구를 사용해야 합니다. 자세한 내용은 issue 354026을 참조합니다.

changes 키워드를 사용한 job 이 예기치 않게 실행됨#

job 이 예기치 않게 파이프라인에 추가되는 흔한 이유는 특정 상황에서 changes 키워드가 항상 true로 평가되기 때문입니다. 예를 들어 예약된 파이프라인이나 태그에 대한 파이프라인 등 특정 파이프라인 유형에서는 changes가 항상 true 입니다.

changes 키워드는 only/except 또는 rules와 함께 사용합니다. changes는 job 이 브랜치 파이프라인이나 머지 리퀘스트 파이프라인에만 추가되도록 보장하는 rules 또는 only/except 설정의 if 섹션과 함께 사용하는 것을 권장합니다.

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

열려 있는 머지 리퀘스트가 연결된 브랜치에 커밋을 푸시하면 두 개의 파이프라인이 실행될 수 있습니다. 보통 하나는 머지 리퀘스트 파이프라인이고 다른 하나는 브랜치 파이프라인입니다.

이 상황은 보통 rules 설정 때문에 발생하며, 중복 파이프라인을 방지하는 여러 방법이 있습니다.

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

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

파이프라인이 실행되지 않았다면, 모든 job에 파이프라인 추가를 막는 rules 또는 only/except가 설정되어 있을 가능성이 큽니다.

잘못된 유형의 파이프라인이 실행되었다면, job 이 올바른 파이프라인 유형에 추가되도록 rules 또는 only/except 설정을 확인해야 합니다. 예를 들어 머지 리퀘스트 파이프라인이 실행되지 않았다면, job 이 대신 브랜치 파이프라인에 추가되었을 수 있습니다.

workflow: rules 설정이 파이프라인을 막았거나 잘못된 파이프라인 유형을 허용했을 가능성도 있습니다.

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

job 이 많은 파이프라인이 시작에 실패함#

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

단일 파이프라인의 job 수를 줄이려면 .gitlab-ci.yml 설정을 더 독립적인 parent-child 파이프라인으로 분리할 수 있습니다.

파이프라인 경고#

다음을 수행할 때 파이프라인 설정 경고가 표시됩니다:

• CI Lint 도구로 설정을 검증할 때입니다.
• 파이프라인을 수동으로 실행할 때입니다.

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

rules를 if 절 없이 when 절과 함께 사용하면 여러 파이프라인이 실행될 수 있습니다. 이는 보통 열려 있는 머지 리퀘스트가 연결된 브랜치에 커밋을 푸시할 때 발생합니다.

중복 파이프라인을 방지하려면 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. 알림 배너에서 Verify my account를 선택합니다.
2. 안내가 표시되면 본인 인증 단계를 따릅니다. 전화번호를 인증하거나 결제 수단을 추가해야 할 수 있습니다.
3. 새 커밋을 만들거나 새 파이프라인을 수동으로 트리거합니다.

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

• 유료 플랜으로 업그레이드합니다.
• 네임스페이스에 대한 추가 컴퓨팅 시간을 구매합니다.
• GitLab 호스팅 러너 대신 프로젝트 또는 그룹 러너를 사용합니다.
• 그룹 Owner에게 셀프 매니지드 러너를 설정해달라고 요청합니다.

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

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

프로젝트에서 파이프라인을 사용하지 않는다면 머지 리퀘스트를 수락할 수 있도록 Pipelines must succeed를 비활성화해야 합니다.

Checking ability to merge automatically 메시지#

머지 리퀘스트가 Checking ability to merge automatically 메시지에서 멈춰 몇 분이 지나도 사라지지 않는다면, 다음 방법 중 하나를 시도해 볼 수 있습니다:

• 머지 리퀘스트 페이지를 새로 고칩니다.
• 머지 리퀘스트를 닫았다가 다시 엽니다.
• /rebase 퀵 액션으로 머지 리퀘스트를 리베이스합니다.
• 머지 리퀘스트가 머지할 준비가 되었다고 이미 확인했다면 /merge 퀵 액션으로 머지할 수 있습니다.

Checking pipeline status 메시지#

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

• GitLab 이 아직 파이프라인 생성을 완료하지 않았습니다.
• 외부 CI 서비스를 사용 중이며 GitLab 이 아직 해당 서비스로부터 응답을 받지 못했습니다.
• 프로젝트에서 CI/CD 파이프라인을 사용하지 않습니다.
• 프로젝트에서 CI/CD 파이프라인을 사용하고 있지만, 설정 때문에 머지 리퀘스트의 소스 브랜치에서 파이프라인이 실행되지 못했습니다.
• 최신 파이프라인이 삭제되었습니다(이는 알려진 이슈입니다).
• 머지 리퀘스트의 소스 브랜치가 비공개 포크에 있습니다.

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

이러한 경우 일부에서는 Pipelines must succeed 설정이 활성화되어 있으면 아이콘이 계속 회전하며 메시지가 멈춘 상태로 남을 수 있습니다. 자세한 내용은 issue 334281을 참조합니다.

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

이 메시지는 include로 설정을 추가했고 다음 중 하나에 해당할 때 표시됩니다:

• 설정이 찾을 수 없는 프로젝트를 참조합니다.
• 파이프라인을 실행하는 사용자가 include 된 프로젝트에 접근할 수 없습니다.

이를 해결하려면 다음을 확인합니다:

• 프로젝트 경로가 my-group/my-project 형식이며 리포지터리 내 폴더를 포함하지 않는지 확인합니다.
• 파이프라인을 실행하는 사용자가 include 된 파일을 포함한 프로젝트의 멤버인지 확인합니다. 사용자는 동일한 프로젝트에서 CI/CD job을 실행할 권한도 있어야 합니다.

The parsed YAML is too big 메시지#

이 메시지는 YAML 설정이 너무 크거나 너무 깊게 중첩되었을 때 표시됩니다. include가 많고 전체 줄 수가 수천 줄에 달하는 YAML 파일은 이 메모리 제한에 걸리기 쉽습니다. 예를 들어 200KB 크기의 YAML 파일은 기본 메모리 제한에 걸릴 가능성이 큽니다.

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

• 파이프라인 에디터의 Full configuration 탭에서 확장된 CI/CD 설정의 길이를 확인합니다. 제거하거나 단순화할 수 있는 중복 설정을 찾습니다.
• 길거나 반복되는 script 섹션을 프로젝트 내 별도 스크립트로 옮깁니다.
• parent 및 child 파이프라인을 사용해 일부 작업을 독립된 child 파이프라인의 job으로 옮깁니다.

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

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

include 된 설정 파일이 순환 참조를 이루면 웹 에디터로 .gitlab-ci.yml 파일을 편집할 때 500 오류가 발생할 수 있습니다.

include 된 설정 파일들이 서로 순환 참조를 만들지 않도록 합니다.

Failed to pull image 메시지#

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

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

job 토큰 설정이 다른 프로젝트의 컨테이너 레지스트리 접근을 막으면 러너는 오류 메시지를 반환합니다.

예를 들면 다음과 같습니다:

• 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
  

다음이 모두 참일 때 이러한 오류가 발생할 수 있습니다:

• 이미지를 호스팅하는 비공개 프로젝트에서 Limit access to this project 옵션이 활성화되어 있습니다.
• 이미지를 가져오려는 job 이 비공개 프로젝트의 허용 목록에 없는 프로젝트에서 실행되고 있습니다.

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

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

무작위 또는 간헐적으로 발생하는 Failed to pull image 오류#

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

이 문제는 사용자마다 이미지 접근 권한이 다르고, 러너가 이러한 이미지를 캐시하는 방식이 결합되어 발생할 수 있습니다. 봇 사용자는 다른 프로젝트 멤버와 권한이 다른 경우가 많아 흔히 영향을 받습니다.

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

러너가 이미지에 접근 권한이 있는 사용자를 위해 이미지를 성공적으로 가져와 캐시하면 오류가 간헐적으로 나타나게 됩니다. 이 러너는 이제 이미지를 보유하고 있으므로 이미지를 가져오기 위해 다른 프로젝트에 접근할 필요가 없습니다. 다른 프로젝트에 접근 권한이 없는 사용자를 포함한 모든 사용자가 이 이미지로 CI/CD job을 실행할 수 있습니다. 하지만 러너가 이미지를 가져와 캐시한 적이 없다면, 이미지가 있는 프로젝트에 접근 권한이 없는 사용자는 Failed to pull image 오류를 받게 됩니다.

이 문제를 해결하려면 봇 사용자를 포함해 파이프라인을 실행하는 모든 사용자가 pull 되는 이미지를 호스팅하는 프로젝트에 접근할 수 있도록 합니다.

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

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

• 푸시하거나 머지 리퀘스트를 생성할 때 Something went wrong on our end 메시지가 표시됩니다.
• API로 파이프라인을 트리거할 때 500 오류가 발생합니다.

이러한 오류는 프로젝트를 import 한 후 내부 ID 기록이 동기화되지 않을 때 발생할 수 있습니다.

이를 해결하려면 issue 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 키워드는 여러 reference 태그 사용을 지원하지만, 배열을 기대하는 다른 키워드는 지원하지 않습니다. 중첩을 사용해 이 제한을 우회하거나, 대신 YAML 앵커를 사용할 수 있습니다.

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

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

모든 job은 script 또는 trigger 키워드 중 하나를 사용해야 하므로, 둘 중 어느 것도 사용하지 않는 job에는 적절한 키워드를 추가합니다.

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

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

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

• 키워드에 오타가 있는 경우입니다. 예를 들어 image(올바름) 대신 imag(잘못됨)를 사용한 경우입니다.
• 키워드나 job의 공백 또는 들여쓰기가 잘못된 경우입니다.

예를 들면 다음과 같습니다:

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