본문으로 건너뛰기

프로젝트 CI/CD 설정

파이프라인 설정에 도달하려면 프로젝트의 Settings > CI/CD로 이동합니다. 프로젝트별로 다음과 같은 설정을 구성할 수 있습니다.

Git strategy for pipelines​

Git 전략을 사용하면 Job의 GitLab에서 리포지터리를 가져오는 기본 방법을 선택할 수 있습니다.

두 가지 옵션이 있습니다. 사용 :

  • git clone : 모든 Job에 대해 리포지터리를 처음부터 복제하기 때문에 속도가 더 느리며, 로컬 작업 복사본은 항상 원래 상태로 유지됩니다.
  • git fetch : GitLab의 기본값이며 로컬 작업 복사본을 재사용하므로 더 빠릅니다. (존재하지 않는 경우 clone으로 대체됨) 특히 대규모 리포지터리에 권장됩니다.

구성된 Git 전략은 .gitlab-ci.yml의 GIT_STRATEGY 변수에 의해 오버라이드(override) 될 수 있습니다.

Git shallow clone​

리포지터리를 복제할 때 GitLab CI/CD가 가져오는 변경사항의 수를 제한할 수 있습니다. git depth로 제한을 설정하면 파이프라인 실행 속도를 높일 수 있습니다.

GitLab 12.0 이상에서 새로 생성된 프로젝트의 git depth 기본값은 자동으로 50입니다. 허용되는 최대 값은 1000입니다.

얕은 클론을 비활성화하고 GitLab CI/CD가 매번 모든 분기 및 태그를 가져오도록 하려면 값을 비워두거나 0으로 설정합니다.

이 값은 .gitlab-ci.yml 파일의 GIT_DEPTH 변수로 재정의할 수도 있습니다.

Timeout​

제한 시간은 Job을 실행할 수 있는 최대 시간(분)을 정의합니다. 이것은 프로젝트의 Settings > CI/CD> General pipelines에서 구성할 수 있습니다. 기본값은 1 시간(h)입니다. Job 실행 시간에 엄격한 제한을 적용하려면 시간제한을 줄이거나 그렇지 않으면 늘리십시오. 어떤 경우에도 Job이 임계 값을 초과하면 실패로 표시됩니다.

CI/CD configuration file​

기본적으로 프로젝트의 루트 디렉토리에서 .gitlab-ci.yml 파일을 찾습니다. 필요한 경우 프로젝트 외부 위치를 포함하여 대체 경로와 파일 이름을 지정할 수 있습니다.

경로를 사용자 지정하려면 :

  1. 프로젝트의 Settings > CI/CD로 이동합니다.
  2. General pipelines 섹션을 확장합니다.
  3. CI/CD configuration file 필드에 값을 입력합니다.
  4. Save changes 버튼을 클릭합니다.

CI 구성이 기본 위치가 아닌 리포지터리 내에 저장되어 있는 경우, 경로는 루트 디렉토리에 상대적이어야 합니다. 유효한 경로 및 파일 이름의 예는 다음과 같습니다.

  • .gitlab-ci.yml (기본값)
  • .my-custom-file.yml
  • my/path/.gitlab-ci.yml
  • my/path/.my-custom-file.yml

외부 사이트에서 CI 구성을 호스팅하는 경우, URL 링크는 .yml으로 끝나야 합니다.

  • http://example.com/generate/ci/config.yml

GitLab 내의 다른 프로젝트에서 CI 구성을 호스팅 하는 경우, 경로는 다른 프로젝트의 루트 디렉터리에 상대적이어야 합니다. 끝에 그룹 및 프로젝트 이름을 포함합니다.

  • .gitlab-ci.yml@mygroup/another-project
  • my/path/.my-custom-file.yml@mygroup/another-project

별도의 프로젝트에서 구성 파일을 호스팅 하면 구성 파일을 더 엄격하게 제어할 수 있습니다. 예를 들면 :

  • 구성 파일을 호스팅 할 공개 프로젝트를 만듭니다.
  • 파일을 편집할 수 있는 사용자에게만 프로젝트에 대한 쓰기 권한을 부여합니다.

다른 사용자 및 프로젝트는 구성 파일을 편집하지 않고도 액세스 할 수 있습니다.

Test coverage parsing​

코드에서 테스트 커버리지를 사용하는 경우, GitLab은 정규 표현식을 사용하여 Job 로그에서 출력을 캡처할 수 있습니다. 파이프라인 설정에서 "Test coverage parsing" 섹션을 검색합니다.

GitLab Test coverage parsing | 인포그랩 GitLab

비활성화하려면 공백으로 두고, 활성화하려면 정규식을 입력합니다. https://rubular.com을 사용하여 정규식을 테스트할 수 있습니다 (Ruby의 경우). 정규식은 출력에서 찾은 마지막 일치를 반환합니다.

파이프라인이 성공하면 병합 요청 위젯과 Job 테이블에 커버리지가 표시됩니다. 파이프라인의 여러 Job에 커버리지 보고서가 있는 경우, 평균이 계산됩니다.

GitLab Merge Request 위젯 | 인포그랩 GitLab
GitLab 커버리지 보고서 | 인포그랩 GitLab

다양한 언어에 대한 알려진 커버리지 도구의 몇 가지 예는 Test coverage parsing 필드 아래에서 찾을 수 있습니다.

파이프라인의 가시성​

파이프라인 가시성은 다음에 의해 결정됩니다.

  • 현재 사용자 액세스 수준
  • 프로젝트의 Settings > CI/CD > General pipelines 아래의 Public pipelines 설정

참고 : 프로젝트 가시성을 비공개로 설정하면 Public pipelines 설정이 적용되지 않습니다.

또한 다음과 같은 관련 기능의 가시성을 결정합니다.

  • Job 출력 로그
  • Job 아티팩트
  • 파이프라인 보안 대시보드 (ULTIMATE)

게스트 사용자와 비 프로젝트 구성원에게는 Job 로그 및 아티팩트가 표시되지 않습니다.

Public pipelines이 활성화된 경우 (기본값) :

  • Public 프로젝트의 경우, 누구나 파이프라인 및 관련 기능을 볼 수 있습니다.
  • Internal 프로젝트의 경우, 외부 사용자를 제외하고 로그인한 사용자는 파이프라인 및 관련 기능을 볼 수 있습니다.
  • Private 프로젝트의 경우, 프로젝트 구성원(게스트 이상)은 파이프라인 및 관련 기능을 볼 수 있습니다.

Public pipelines이 비활성화된 경우 :

  • Public 프로젝트의 경우, 누구나 파이프라인을 볼 수 있지만 구성원만(Reporter 이상) 관련 기능에 액세스 할 수 있습니다.
  • Internal 프로젝트의 경우, 외부 사용자를 제외하고 로그인한 사용자는 파이프라인을 볼 수 있습니다. 단, Job 관련 기능에는 구성원만(Reporter 이상) 액세스 할 수 있습니다.
  • Private 프로젝트의 경우, 구성원만(Reporter 이상) 파이프라인을 보거나 관련 기능에 액세스 할 수 있습니다.

보류 중인 파이프라인 자동 취소​

새 파이프라인이 동일한 브랜치에서 실행될 때, 보류 중이거나 실행 중인 파이프라인을 자동으로 취소되도록 설정할 수 있습니다. 프로젝트 설정에서 활성화할 수 있습니다.

  1. Settings > CI/CD로 이동합니다.
  2. General pipelines을 확장합니다.
  3. Auto-cancel redundant, pending pipelines 체크박스를 체크합니다.
  4. Save changes 버튼을 클릭합니다.

인터럽트가 true로 설정된 Job만 취소된다는 점에 유의하십시오.

오래된 배포 Job 건너뛰기​

프로젝트에는 동일한 시간 프레임 내에 실행되도록 예약된 여러 동시 배포 Job이 있을 수 있습니다. 이로 인해 이전 배포 Job이 최신 배포 Job 이후에 실행되는 상황이 발생할 수 있으며, 이는 원하는 것이 아닐 수 있습니다.

이 시나리오를 방지하려면 :

  1. Settings > CI/CD로 이동합니다.
  2. General pipelines을 확장합니다.
  3. Skip outdated deployment jobs 체크박스를 체크합니다.
  4. Save changes 버튼을 클릭합니다.

활성화하면 새 배포가 시작될 때 이전 배포 Job을 건너뜁니다.

파이프라인 배지​

파이프라인 설정 페이지에서 프로젝트의 파이프라인 상태 및 테스트 커버리지 배지를 찾을 수 있습니다. 가장 최근에 성공한 파이프라인은 파이프라인 상태 및 테스트 커버리지 값을 판독하는 데 사용됩니다. 프로젝트의 파이프라인 설정 페이지를 방문하여 배지에 대한 정확한 링크를 확인하십시오. HTML 또는 마크다운 페이지에 배지 이미지를 삽입하는 방법도 확인할 수 있습니다.

GitLab Pipeline 배지 삽입 | 인포그랩 GitLab

파이프라인 상태 배지​

Job 상태에 따라 배지는 다음 값을 가질 수 있습니다.

  • pending
  • running
  • passed
  • failed
  • skipped
  • canceled
  • unknown

다음 링크를 사용하여 파이프라인 상태 배지 이미지에 액세스 할 수 있습니다.

https://gitlab.example.com/<namespace>/<project>/badges/<branch>/pipeline.svg

[건너뛰지 않은 상태만 표시] 파이프라인 상태 배지에 마지막으로 건너뛰지 않은 상태만 표시하려면, 쿼리 파라미터 ?ignore_skipped=true를 사용할 수 있습니다.

https://gitlab.example.com/<namespace>/<project>/badges/<branch>/pipeline.svg?ignore_skipped=true

테스트 커버리지 보고서 배지​

GitLab을 사용하면 각 Job 로그가 일치하는 커버리지 보고서의 정규 표현식을 정의할 수 있습니다. 즉, 파이프라인의 각 Job은 정의된 테스트 커버리지 백분율 값을 가질 수 있습니다.

테스트 커버리지 배지는 다음 링크를 사용하여 액세스 할 수 있습니다.

https://gitlab.example.com/<namespace>/<project>/badges/<branch>/coverage.svg

특정 Job에서 커버리지 보고서를 받으려면 job=coverage_job_name 파라미터를 URL에 추가할 수 있습니다. 예를 들어, 다음 마크다운 코드는 coverage Job의 테스트 커버리지 보고서 배지를 README.md에 포함시킵니다.

![coverage](https://gitlab.com/gitlab-org/gitlab/badges/master/coverage.svg?job=coverage)

배지 스타일​

style=style_name 파라미터를 URL에 추가하여 파이프라인 배지를 다양한 스타일로 렌더링 할 수 있습니다. 두 가지 스타일을 사용할 수 있습니다.

Flat (기본값)

https://gitlab.example.com/<namespace>/<project>/badges/<branch>/coverage.svg?style=flat
GitLab Pipeline 배지 Flat 스타일 | 인포그랩 GitLab

Flat square

https://gitlab.example.com/<namespace>/<project>/badges/<branch>/coverage.svg?style=flat-square
GitLab Pipeline 배지 Flat Square 스타일 | 인포그랩 GitLab

커스텀 배지 텍스트​

배지의 텍스트는 사용자 정의할 수 있습니다. 이는 동일한 파이프라인에서 실행되는 여러 커버리지 Job을 구별하는 데 유용할 수 있습니다. URL에 key_text=custom_text 및 key_width=custom_key_width 파라미터를 추가하여 배지 텍스트와 너비를 사용자 지정합니다.

https://gitlab.com/gitlab-org/gitlab/badges/master/coverage.svg?job=karma&key_text=Frontend+Coverage&key_width=130
GitLab Pipeline 배지 사용자 지정 텍스트 | 인포그랩 GitLab
GitLab 원문 보기