CI 구성 내부 구조

GitLab 프로젝트의 CI/CD 파이프라인 내부 구조, 워크플로 규칙, 기본 이미지, 변수, Stage, Dependency Proxy, 공통 job 정의, rules 및 모범 사례를 설명합니다.

워크플로 규칙 # GitLab 프로젝트의 파이프라인은 GitLab CI/CD의 workflow:rules 키워드 기능을 사용하여 생성됩니다. 파이프라인은 다음 시나리오에서 항상 생성됩니다: main 브랜치 (스케줄, 푸시, 머지 등 포함) 머지 리퀘스트 태그 Stable, auto-deploy , 보안 브랜치 파이프라인 생성은 다음 CI/CD 변수에도 영향을 받습니다: $FORCE_GITLAB_CI 가 설정된 경우 파이프라인이 생성됩니다. 사용을 권장하지 않습니다. $FORCE_GITLAB_CI 사용 금지 를 참조하세요. $GITLAB_INTERNAL 이 설정되지 않은 경우 파이프라인이 생성되지 않습니다. 그 외의 경우(예: MR이 없는 브랜치에 푸시할 때)에는 파이프라인이 생성되지 않습니다. 이 워크플로 규칙의 단일 진실 공급원(Single Source Of Truth, SSOT)은 .gitlab-ci.yml 에 정의되어 있습니다. $FORCE_GITLAB_CI 사용 금지 # 파이프라인은 매우 복잡하며 어떤 종류의 파이프라인을 트리거할지 명확하게 이해해야 합니다. 어떤 job을 실행해야 하고 어떤 job은 실행하지 않아야 하는지 알아야 합니다. $FORCE_GITLAB_CI 를 사용하여 파이프라인을 강제로 트리거하면, 어떤 종류의 파이프라인인지 실제로 알 수 없습니다. 그 결과 원하는 job이 실행되지 않거나, 관심 없는 job이 너무 많이 실행될 수 있습니다. 더 많은 컨텍스트와 배경 정보는 다음에서 확인할 수 있습니다: 예기치 않은 실행을 방지하기 위한 포괄적인 변경 금지 현재 이 변수가 사용되고 있는 곳의 목록이며, 점차 $FORCE_GITLAB_CI 사용을 줄여 나가야 합니다. JiHu 검증 파이프라인 $FORCE_GITLAB_CI 를 사용하지 않고 파이프라인을 활성화하는 방법은 다음 섹션을 참조하세요. $FORCE_GITLAB_CI의 대안 # 기본적으로 서로 다른 변수를 사용하여 서로 다른 파이프라인을 활성화합니다. 이를 수행하는 예시가 $START_AS_IF_FOSS 입니다. 크로스 프로젝트 FOSS 파이프라인을 트리거하려면 $START_AS_IF_FOSS 와 함께 $ENABLE_RSPEC_UNIT , $ENABLE_RSPEC_SYSTEM 등의 변수를 설정하여 as-if-foss 크로스 프로젝트 다운스트림 파이프라인에서 실행할 각 job을 활성화합니다. $FORCE_GITLAB_CI 에 비해 이 방식의 장점은 $START_AS_IF_FOSS 가 이 목적에만 사용되기 때문에 파이프라인 실행 방식을 완전히 제어할 수 있다는 것입니다. 이 변수 아래에서 파이프라인 동작을 변경해도 다른 유형의 파이프라인에는 영향을 미치지 않지만, $FORCE_GITLAB_CI 는 여러 목적으로 사용되기 때문에 파이프라인이 정확히 무엇인지 알 수 없습니다. 기본 이미지 # 기본 이미지는 .gitlab-ci.yml 에 정의되어 있습니다. 여기에는 Ruby, Go, Git, Git LFS, Chrome, Node, Yarn, PostgreSQL, Gra