작업 문제 해결

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated

작업을 사용할 때 다음과 같은 문제에 직면할 수 있습니다.

changes:를 사용할 때 작업 또는 파이프라인이 예기치 않게 실행됨

rules: changes 또는 only: changes를 사용할 때 작업이나 파이프라인이 예기치 않게 실행되는 경우가 있습니다.

병합 요청과 명시적인 연관이 없는 브랜치나 태그에서 파이프라인은 이전 SHA를 사용하여 차이를 계산합니다. 이 계산은 git diff HEAD~에 해당하며 예기치 않은 동작을 유발할 수 있습니다. 여기에는 다음이 포함됩니다:

  • 새 브랜치나 새 태그를 GitLab에 푸시할 때 changes 규칙이 항상 true로 평가됩니다.
  • 새 커밋을 푸시할 때 변경된 파일은 이전 커밋을 기준 SHA로 사용하여 계산됩니다.

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

CI/CD 변수의 파일 경로

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

docker_build:
  variables:
    DOCKERFILES_DIR: 'path/to/files/'  # 이 변수는 끝에 '/' 문자를 포함하면 안 됩니다.
  script: echo "A docker job"
  rules:
    - changes:
        - $DOCKERFILES_DIR/*

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

이 프로젝트에서 코드를 다운로드할 수 없습니다. 오류 메시지

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

CI/CD 작업은 일반적으로 작업이 시작될 때 프로젝트를 클론하며, 이 과정은 작업을 실행하는 사용자의 권한을 사용합니다. 모든 사용자, 관리자를 포함하여, 비공식 프로젝트의 소스를 클론하기 위해서는 해당 프로젝트의 직접 구성원이 되어야 합니다. 이 문제에 대한 이슈가 존재합니다.

보호된 매뉴얼 작업을 실행하려면:

  • 관리자를 비공식 프로젝트의 직접 구성원으로 추가하세요 (어떤 역할이라도).
  • 프로젝트의 직접 구성원인 사용자를 임계하다.

CI/CD 작업이 다시 실행될 때 최신 구성을 사용하지 않음

파이프라인의 구성은 파이프라인이 생성될 때만 가져옵니다. 작업을 다시 실행할 때는 매번 동일한 구성을 사용합니다. 구성 파일, 포함 include를 통해 추가된 별도의 파일을 업데이트하면 새 구성을 사용하기 위해서는 새로운 파이프라인을 시작해야 합니다.

작업이 단일 작업에 대해 여러 파이프라인이 실행되도록 허용할 수 있음 경고

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

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

이 GitLab CI 구성은 변수 표현식에 대해 유효하지 않습니다

CI/CD 변수 표현식 작업 중 여러 이 GitLab CI 구성은 유효하지 않습니다 오류를 받을 수 있습니다.

이러한 구문 오류는 인용 문자 사용이 잘못되어 발생할 수 있습니다.

변수 표현식에서는 문자열은 인용해야 하지만, 변수는 인용하지 않아야 합니다.

예를 들어:

variables:
  ENVIRONMENT: production

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

이 예제에서 두 if: 절은 유효합니다. 왜냐하면 production 문자열이 인용되어 있고, CI/CD 변수는 인용되지 않았기 때문입니다.

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

variables:
  ENVIRONMENT: production

job:
  script: echo
  rules:       # 이 규칙들은 모두 YAML 구문 오류를 발생시킵니다:
    - 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 변수가 없기 때문입니다.