테스트용 패키지 빌드

새로운 기능을 개발하거나 기존 기능을 수정하는 동안 해당 변경 사항을 포함한 설치 가능한 패키지(또는 Docker 이미지)가 테스트용으로 사용 가능하면 유용합니다. 이를 위해 GitLab CI/CD 파이프라인에서 매뉴얼 작업을 제공하여 Omnibus GitLab 리포지터리에서 해당 파이프라인을 트리거할 수 있습니다. 이때 아래와 같은 것들이 생성됩니다:

  • Ubuntu 16.04용 deb 패키지가 빌드 아티팩트로 제공되며,
  • Docker 이미지가 생성됩니다. Docker 이미지는 Omnibus GitLab 컨테이너 레지스트리에 푸시됩니다. GitLab Enterprise Edition용 이미지는 gitlab-ee로, GitLab Community Edition용 이미지는 gitlab-ce로 이름이 지정됩니다.
  • 이미지 태그는 해당 파이프라인을 트리거한 커밋입니다.

GitLab CE 또는 GitLab EE 프로젝트에 커밋을 푸시하면 해당 커밋의 파이프라인에 trigger-omnibus 작업이 qa 단계에 수동으로 트리거할 수 있습니다(트리거되지 않은 경우).

trigger-omnibus QA 작업 트리거

하위 파이프라인이 시작되면 trigger-omnibus를 선택하여 TRIGGERED_EE_PIPELINE이라는 하위 파이프라인으로 이동할 수 있습니다.

트리거된 하위 파이프라인

다음으로, trigger-package 단계에서 Trigger:package 작업을 선택하세요.

Trigger:package 작업이 완료되면 해당 아티팩트가 GitLab에 업로드되므로 .deb 파일을 찾아 다운로드하거나 GitLab API를 사용하여 파일을 직접 가상 머신에 다운로드할 수 있습니다. 이러한 아티팩트의 유효 기간이 짧으므로 대부분 1일 이내에 자동으로 삭제됩니다.

컴포넌트 버전 지정

GitLab Workhorse, Gitaly, 또는 GitLab Pages와 같은 GitLab 컴포넌트 중 특정 브랜치, 커밋 또는 태그에서 패키지를 생성하려는 경우 해당 컴포넌트의 *_VERSION 파일에 브랜치 이름, 커밋 SHA 또는 태그를 지정할 수 있습니다. 예를 들어, 0-1-stable 브랜치를 사용하는 패키지를 빌드하려면 GITALY_SERVER_VERSION의 내용을 0-1-stable로 수정하고 커밋을 푸시하면 매뉴얼 작업이 생성되어 빌드를 트리거할 수 있습니다.

Omnibus GitLab 리포지터리에서 브랜치 지정

구성 변경이 도입되어야 하고 Omnibus GitLab 리포지터리에 이미 해당 변경 사항이 특정 브랜치에 있을 경우, .gitlab-ci.ymlOMNIBUS_BRANCH이라는 CI/CD 변수를 특정 브랜치의 이름과 함께 지정하고 커밋을 푸시하면 매뉴얼 작업이 생성되어 빌드를 트리거할 수 있습니다.