job을 사용할 때 다음과 같은 문제가 발생할 수 있습니다.

changes:를 사용할 때 job이나 파이프라인이 예기치 않게 실행되는 경우#

머지 리퀘스트 파이프라인 없이 rules: changes 또는 only: changes를 사용할 때 job이나 파이프라인이 예기치 않게 실행될 수 있습니다.

머지 리퀘스트와 명시적 연결이 없는 브랜치나 태그의 파이프라인은 이전 SHA를 사용하여 diff를 계산합니다. 이 계산은 git diff HEAD~와 동일하며 다음과 같은 예기치 않은 동작을 유발할 수 있습니다:

• GitLab에 새 브랜치나 새 태그를 푸시할 때 changes 규칙은 항상 true로 평가됩니다.

• 새 커밋을 푸시할 때 변경된 파일은 이전 커밋을 기본 SHA로 사용하여 계산됩니다.

또한 changes가 있는 규칙은 예약된 파이프라인에서 항상 true로 평가됩니다. 예약된 파이프라인이 실행될 때 모든 파일이 변경된 것으로 간주되므로 changes를 사용하는 예약된 파이프라인에 job이 항상 추가될 수 있습니다.

CI/CD 변수에서의 파일 경로#

CI/CD 변수에서 파일 경로를 사용할 때 주의하세요. 후행 슬래시는 변수 정의에서 올바르게 보일 수 있지만, script:, changes: 또는 다른 키워드에서 확장될 때 유효하지 않을 수 있습니다. 예를 들어:

docker_build:
  variables:
    DOCKERFILES_DIR: 'path/to/files/'  # This variable should not have a trailing '/' character
  script: echo "A docker job"
  rules:
    - changes:
        - $DOCKERFILES_DIR/*

DOCKERFILES_DIR 변수가 changes: 섹션에서 확장될 때 전체 경로는 path/to/files//*가 됩니다. 이중 슬래시는 사용된 키워드, 러너의 셸과 OS 등 다양한 요인에 따라 예기치 않은 동작을 유발할 수 있습니다.

You are not allowed to download code from this project. 오류 메시지#

GitLab 관리자가 비공개 프로젝트에서 보호된 수동 job을 실행할 때 파이프라인이 실패하는 것을 볼 수 있습니다.

CI/CD job은 보통 job이 시작될 때 프로젝트를 클론하며, 이는 job을 실행하는 사용자의 권한을 사용합니다. 관리자를 포함한 모든 사용자는 비공개 프로젝트의 소스를 클론하려면 해당 프로젝트의 직접 멤버여야 합니다. 이 동작을 변경하기 위한 이슈가 있습니다.

보호된 수동 job을 실행하려면:

• 관리자를 비공개 프로젝트의 직접 멤버로 추가하세요(어떤 권한이든 가능).

• 프로젝트의 직접 멤버인 사용자를 가장하세요.

다시 실행할 때 CI/CD job이 최신 설정을 사용하지 않는 경우#

파이프라인 설정은 파이프라인이 생성될 때만 가져옵니다. job을 재실행할 때는 매번 동일한 설정을 사용합니다. include로 추가된 별도 파일을 포함하여 설정 파일을 업데이트한 경우 새 설정을 사용하려면 새 파이프라인을 시작해야 합니다.

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

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

중복 파이프라인을 방지하려면 workflow: rules를 사용하거나 어떤 파이프라인이 실행될 수 있는지 제어하도록 규칙을 재작성하세요.

변수 표현식에 대한 This GitLab CI configuration is invalid#

CI/CD 변수 표현식으로 작업할 때 여러 This GitLab CI configuration is invalid 오류 중 하나를 받을 수 있습니다. 이러한 문법 오류는 따옴표 문자를 잘못 사용하여 발생할 수 있습니다.

변수 표현식에서 문자열은 따옴표로 묶어야 하며, 변수는 따옴표로 묶지 않아야 합니다. 예를 들어:

variables:
  ENVIRONMENT: production

job:
  script: echo
  rules:
    - if: $ENVIRONMENT == "production"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

이 예시에서 production 문자열은 따옴표로 묶이고 CI/CD 변수는 따옴표 없이 사용되므로 두 if: 절 모두 유효합니다.

반면 다음 if: 절은 모두 유효하지 않습니다:

variables:
  ENVIRONMENT: production

job:
  script: echo
  rules:       # These rules all cause YAML syntax errors:
    - if: ${ENVIRONMENT} == "production"
    - if: "$ENVIRONMENT" == "production"
    - if: $ENVIRONMENT == production
    - if: "production" == "production"

이 예시에서:

• if: ${ENVIRONMENT} == "production"은 ${ENVIRONMENT}가 if:의 CI/CD 변수에 유효한 형식이 아니므로 유효하지 않습니다.

• if: "$ENVIRONMENT" == "production"은 변수가 따옴표로 묶여 있으므로 유효하지 않습니다.

• if: $ENVIRONMENT == production은 문자열이 따옴표로 묶여 있지 않으므로 유효하지 않습니다.

• if: "production" == "production"은 비교할 CI/CD 변수가 없으므로 유효하지 않습니다.

HTTP/2 문제로 인해 get_sources job 섹션이 실패하는 경우#

때때로 job이 다음 cURL 오류와 함께 실패합니다:

++ git -c 'http.userAgent=gitlab-runner <version>' fetch origin +refs/pipelines/<id>:refs/pipelines/<id> ...
error: RPC failed; curl 16 HTTP/2 send again with decreased length
fatal: ...

Git과 libcurl을 HTTP/1.1 사용으로 구성하여 이 문제를 해결할 수 있습니다. 다음 위치에 설정을 추가할 수 있습니다:

• job의 pre_get_sources_script:

  job_name:
    hooks:
      pre_get_sources_script:
        - git config --global http.version "HTTP/1.1"
  

• Git 설정 환경 변수와 함께 러너의 config.toml:

  [[runners]]
  ...
  environment = [
    "GIT_CONFIG_COUNT=1",
    "GIT_CONFIG_KEY_0=http.version",
    "GIT_CONFIG_VALUE_0=HTTP/1.1"
  ]
  

resource_group을 사용하는 job이 멈추는 경우#

resource_group을 사용하는 job이 멈추면 GitLab 관리자는 레일스 콘솔에서 다음 명령을 실행해 볼 수 있습니다:

# find resource group by name
resource_group = Project.find_by_full_path('...').resource_groups.find_by(key: 'the-group-name')
busy_resources = resource_group.resources.where('build_id IS NOT NULL')

# identify which builds are occupying the resource
# (I think it should be 1 as of today)
busy_resources.pluck(:build_id)

# it's good to check why this build is holding the resource.
# Is it stuck? Has it been forcefully dropped by the system?
# free up busy resources
busy_resources.update_all(build_id: nil)

오류: 데이터 무결성 실패#

job 처리 중 data integrity failure 오류가 발생할 수 있습니다. 다운스트림 파이프라인을 위한 트리거 job, 러너 할당 대기 중인 job, 정리 중 멈춘 job 등 모든 job 유형에서 발생할 수 있습니다.

PostgreSQL 및 Sidekiq 로그에서 근본 원인을 확인하세요. GitLab Self-Managed 인스턴스의 일반적인 원인은 다음과 같습니다:

업그레이드 후 데이터베이스 시퀀스 손상 PostgreSQL 로그에 PG::UniqueViolation 오류가 포함됩니다. 관련 데이터베이스 트리거 함수가 올바른 시퀀스를 참조하는지 확인하세요. 업그레이드 후 오래된 Sidekiq 프로세스 오류가 간헐적으로 발생하며 job을 재시도하면 성공합니다. 모든 Sidekiq 노드가 예상 GitLab 버전을 실행하는지 확인하고 그렇지 않은 노드를 재시작하세요. 스키마 변경으로 인한 모호하거나 유효하지 않은 SQL PostgreSQL 로그에 job 처리 중 실행된 쿼리의 SQL 오류가 포함됩니다. 최근 스키마 변경이 이 job 유형에 대해 실행되는 쿼리에 영향을 미쳤는지 확인하세요.

오류가 지속되면 레일스 콘솔에서 job을 검사하여 failure_reason과 다운스트림 파이프라인이 생성되었는지 확인하세요.

You are not authorized to run this manual job 메시지#

수동 job을 실행하려고 할 때 이 메시지를 받고 실행 버튼이 비활성화될 수 있는 경우:

• 대상 환경이 보호된 환경이고 귀하의 계정이 배포 허용 목록에 포함되지 않은 경우.

• 오래된 배포 job 방지 설정이 활성화되어 있고 job을 실행하면 최신 배포를 덮어쓸 경우.

멈추거나 시간 초과를 초과한 후 job이 중단되는 경우#

job이 오랜 기간 진행되지 않으면 GitLab이 자동으로 job을 중단하고 특정 failure_reason을 기록합니다. 임계값은 job의 상태에 따라 달라집니다:

job이 대기하지 않고 즉시 실패한 경우에는 이것이 원인이 아닙니다. job을 자동으로 재시도하거나 전체 실패 사유 목록을 확인하려면 retry:when을 참조하세요.