Skip to Content
Infra & DevOpsGitLab CI/CD의 커밋·파이프라인·레지스트리 변수
☁️ Infra & DevOps2019년 6월 9일

GitLab CI/CD의 커밋·파이프라인·레지스트리 변수

#gitlab#ci-cd#infra-devops#pipeline#docker

GitLab CI 작업에서 사용할 수 있는 환경 변수를 확인하며 남긴 메모입니다. 커밋과 파이프라인을 식별하는 값, 프로젝트·레지스트리 주소를 직접 적지 않고 제공되는 변수를 활용할 수 있습니다.

변수마다 제공되는 조건과 시점이 다르므로, 모든 파이프라인에서 같은 값이 들어온다고 가정하지 않아야 합니다.

커밋과 브랜치 식별

변수의미
CI_COMMIT_SHA작업 대상의 전체 커밋 SHA
CI_COMMIT_SHORT_SHA짧게 표시한 커밋 SHA
CI_COMMIT_REF_NAME브랜치 또는 태그 이름
CI_COMMIT_REF_SLUG이름을 제한된 문자와 길이로 정리한 값
CI_COMMIT_TAG태그 파이프라인에서의 태그 이름

브랜치 이름에는 /처럼 Docker 이미지 태그에 그대로 쓰기 어려운 문자가 있을 수 있습니다. 브랜치를 포함하려면 CI_COMMIT_REF_SLUG를 사용하는 방식을 검토할 수 있습니다.

bash
IMAGE_TAG="${CI_COMMIT_REF_SLUG}-${CI_COMMIT_SHORT_SHA}"

짧은 SHA나 slug가 모든 상황에서 고유한 식별자를 보장하지는 않습니다. 정확한 빌드 추적이 필요하면 전체 커밋과 파이프라인 정보도 함께 남겨야 합니다.

파이프라인과 작업 식별

변수의미
CI_PIPELINE_IDGitLab 인스턴스 안의 파이프라인 ID
CI_PIPELINE_IID프로젝트 안의 파이프라인 IID
CI_JOB_ID개별 작업 ID
CI_JOB_NAME작업 이름
CI_JOB_STAGE작업이 속한 stage
CI_PROJECT_PATH네임스페이스를 포함한 프로젝트 경로

같은 커밋으로 파이프라인을 다시 실행할 수도 있으므로 커밋과 실행 이력의 식별은 구분하면 좋습니다. IID 역시 단순한 누적 실행 횟수로 해석하기보다 프로젝트 범위의 식별자로 사용합니다.

레지스트리 로그인과 이미지 태깅

GitLab Container Registry를 사용하는 작업에서는 CI_REGISTRY, CI_REGISTRY_IMAGE, CI_REGISTRY_USER, CI_REGISTRY_PASSWORD 등을 사용할 수 있습니다. 레지스트리 기능과 작업 권한이 준비돼 있어야 합니다.

다음은 Docker CLI와 접근 가능한 Docker daemon이 있는 Runner를 전제로 한 설명용 작업입니다. 실제 구축했던 파이프라인 전체를 옮긴 예시는 아닙니다.

yaml
.gitlab-ci.yml의 작업 예시
build-image:
  stage: build
  script:
    - printf '%s' "$CI_REGISTRY_PASSWORD" | docker login "$CI_REGISTRY" --username "$CI_REGISTRY_USER" --password-stdin
    - docker build --tag "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA" .
    - docker push "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"

비밀번호는 명령 인자 -p에 넣는 대신 표준 입력으로 전달합니다. 예제는 레지스트리 인증과 태깅을 보여 주며, Runner의 Docker 실행 환경까지 구성하지는 않습니다.

변수의 제공 시점과 로그 출력

현재 GitLab 문서는 변수를 pre-pipeline·pipeline·job-only 단계로 구분합니다. 작업 실행 때만 생기는 값을 그보다 앞선 파이프라인 구성 판단에 사용할 수는 없습니다.

값을 확인하려고 전체 env 출력을 공유하면 토큰과 자격 증명까지 섞일 수 있습니다. 필요한 변수 이름과 제공 조건은 공식 문서에서 확인하고, 로그에는 공개해도 되는 식별 정보만 남기는 편이 좋습니다.

참고 자료

Last updated on