테스트용 패키지 빌드

새 기능을 개발하거나 기존 기능을 수정하는 동안 해당 변경 사항을 포함하는 설치 가능한 패키지(또는 Docker 이미지)가 테스트용으로 사용 가능하면 도움이 됩니다. 이를 위해, Omnibus GitLab 저장소에서 파이프라인을 트리거할 수 있는 수동 작업이 GitLab CI/CD 파이프라인에 제공됩니다. 해당 파이프라인은 다음을 생성합니다:

• 우분투 16.04용 deb 패키지로서 빌드 결과물로 제공되는 Docker 이미지, 그리고
• Docker 이미지, GitLab Enterprise Edition의 이미지는 gitlab-ee로 명명되고, GitLab Community Edition의 이미지는 gitlab-ce로 명명됩니다.
• 이미지 태그는 해당 파이프라인을 트리거한 커밋입니다.

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

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

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

Trigger:package 작업이 완료되면 해당 생성물을 GitLab에 업로드하고, 이후에는 .deb 파일을 검색하거나 GitLab API를 사용하여 파일을 직접 가상 머신으로 다운로드할 수 있습니다. 이 생성물의 만료 기간이 짧으므로 약 일정 기간 이내에 자동으로 삭제됩니다.

구성 요소 버전 지정

GitLab 구성 요소(GitLab Workhorse, Gitaly, 또는 GitLab Pages와 같은)의 특정 브랜치, 커밋 또는 태그에서 패키지를 생성하려면 해당 구성 요소의 *_VERSION 파일에 브랜치 이름, 커밋 SHA 또는 태그를 지정할 수 있습니다. 예를 들어, 0-1-stable 브랜치를 사용하여 패키지를 빌드하려면 GITALY_SERVER_VERSION의 내용을 0-1-stable로 수정하고 해당 커밋을 푸시합니다. 이렇게 하면 빌드를 트리거할 수 있는 수동 작업이 생성됩니다.

Omnibus GitLab 저장소에서 브랜치 지정

특정 브랜치에서 필요한 변경 사항을 Omnibus GitLab 저장소에 이미 포함시킬 경우, .gitlab-ci.yml에서 OMNIBUS_BRANCH라는 CI/CD 변수에 해당 브랜치 이름을 지정하고 커밋을 푸시합니다. 이렇게 하면 빌드를 트리거할 수 있는 수동 작업이 생성됩니다.