Omnibus GitLab 릴리스 프로세스
우리의 주요 목표는 Omnibus 패키지에 포함된 GitLab의 버전을 명확히 하는 것입니다.
공식 Omnibus GitLab 패키지는 어떻게 빌드되나요?
공식 패키지 빌드는 GitLab Inc.에 의해 완전히 자동화됩니다.
빌드 유형을 구분할 수 있습니다:
- https://packages.gitlab.com에 릴리스용 패키지
- S3 버킷에서 사용 가능한 브랜치에서 빌드된 테스트 패키지
두 유형은 동일한 인프라에서 빌드됩니다.
인프라
각 패키지는 해당 대상 플랫폼에 빌드됩니다 (CentOS 6 패키지는 CentOS6 서버, Debian 8 패키지는 Debian 8 서버 등). 빌드 서버 수는 다양하지만 플랫폼 당 최소 하나의 빌드 서버가 항상 있습니다.
Omnibus GitLab 프로젝트는 GitLab CI를 완전히 활용합니다. 즉, Omnibus GitLab 리포지토리로의 각 푸시는 GitLab CI에서 빌드를 트리거하고, 그 후에 패키지가 생성됩니다.
우리는 Omnibus GitLab 패키지를 사용하여 GitLab.com을 배포하므로, GitLab.com에 문제가 있거나 패키지의 보안 릴리스로 인해 패키지를 빌드하기 위해 별도의 원격이 필요합니다.
이 원격은 https://dev.gitlab.org/에 위치해 있습니다. https://dev.gitlab.org/의 Omnibus GitLab 프로젝트와 다른 공개 리모트 간의 유일한 차이점은 프로젝트에 활성화된 GitLab CI가 있고, 프로젝트에 할당된 특정 러너가 빌드 서버에서 실행된다는 것입니다. 이는 GitLab Shell과 같은 모든 GitLab 구성 요소에 대해서도 동일하게 적용됩니다.
모든 빌드 서버는 GitLab Runner를 실행하며 모든 러너는 프로젝트에 연결하기 위해 배포 키를 사용합니다. 빌드 서버는 또한 https://packages.gitlab.com의 공식 패키지 저장소와 테스트 패키지를 저장하는 특별한 Amazon S3 버킷에 액세스할 수 있습니다.
빌드 과정
GitLab Inc.는 모든 릴리스 작업을 자동화하기 위해 릴리스 도구 프로젝트를 사용합니다. 릴리스 관리자가 릴리스 프로세스를 시작하면 Omnibus GitLab에 대해 몇 가지 중요한 작업이 수행됩니다:
- 프로젝트의 모든 원격이 동기화됩니다.
- 컴포넌트의 버전은 GitLab CE/EE 리포지토리에서 읽힌 후 Omnibus GitLab 리포지토리에 기록됩니다 (예:
VERSION,GITLAB_SHELL_VERSION). - 특정 Git 태그가 생성되어 Omnibus GitLab 리포지토리로 동기화됩니다.
https://dev.gitlab.org/의 Omnibus GitLab 리포지토리가 업데이트되면 GitLab CI 빌드가 트리거됩니다.
구체적인 단계는 Omnibus GitLab 리포지토리의 .gitlab-ci.yml 파일에서 볼 수 있습니다. 빌드는 동시에 모든 플랫폼에서 실행됩니다.
빌드 중에 Omnibus GitLab은 외부 라이브러리를 소스 위치에서 가져오고 GitLab, GitLab Shell, GitLab Workhorse 등의 GitLab 구성 요소는 https://dev.gitlab.org/에서 가져올 것입니다.
빌드가 완료되고 .deb 또는 .rpm 패키지가 빌드되면 빌드 유형에 따라 패키지가 https://packages.gitlab.com 또는 임시로 (30일 이상 된 파일은 삭제됨) S3 버킷에 푸시됩니다.
구성 요소 버전 수동 지정
개발 환경에서
- 패키지할 GitLab의 태그를 선택합니다 (예:
v6.6.0). - Omnibus GitLab 리포지토리에 릴리스 브랜치를 만듭니다 (예:
6-6-stable). -
패치 릴리스를 수행하는 경우와 같이 릴리스 브랜치가 이미 있는 경우 로컬 머신으로 최신 변경 사항을 가져왔는지 확인합니다:
git pull https://gitlab.com/gitlab-org/omnibus-gitlab.git 6-6-stable # 기존 릴리스 브랜치 -
config/software/의 파일의 리비전을 설정하기 위해support/set-revisions를 사용합니다. 이 명령은 태그 이름을 가져와서 Git SHA1를 찾아내고 다운로드 소스를 https://dev.gitlab.org/로 설정합니다. EE 릴리스의 경우set-revisions --ee를 사용합니다:# 사용법: set-revisions [--ee] GITLAB_RAILS_REF GITLAB_SHELL_REF GITALY_REF GITLAB_ELASTICSEARCH_INDEXER_REF # GitLab CE의 경우: support/set-revisions v1.2.3 v1.2.3 1.2.3 1.2.3 1.2.3 # GitLab EE의 경우: support/set-revisions --ee v1.2.3-ee v1.2.3 1.2.3 1.2.3 1.2.3 -
새 버전을 릴리스 브랜치에 커밋합니다:
git add VERSION GITLAB_SHELL_VERSION GITALY_SERVER_VERSION git commit -
Omnibus GitLab에 GitLab 태그에 해당하는 주석이 달린 태그를 생성합니다. Omnibus 태그는
MAJOR.MINOR.PATCH+OTHER.OMNIBUS_RELEASE와 같은 모양을 가집니다. 여기서MAJOR.MINOR.PATCH는 GitLab 버전이고,OTHER는ce,ee또는rc1(또는rc1.ee)와 같은 것일 수 있으며,OMNIBUS_RELEASE는 번호 (0부터 시작)입니다:git tag -a 6.6.0+ce.0 -m 'GitLab을 v6.6.0에 고정'경고: Omnibus GitLab 태그에 하이픈
-을 사용하지 마세요.상위 태그를 Omnibus 태그 시퀀스로 변환하는 예시:
상위 태그 omnibus 태그 시퀀스 v7.10.47.10.4+ce.0,7.10.4+ce.1,...v7.10.4-ee7.10.4+ee.0,7.10.4+ee.1,...v7.11.0.rc1-ee7.11.0+rc1.ee.0,7.11.0+rc1.ee.1,... -
브랜치 및 태그를 https://gitlab.com 및 https://dev.gitlab.org/에 푸시합니다:
git push git@gitlab.com:gitlab-org/omnibus-gitlab.git 6-6-stable 6.6.0+ce.0 git push git@dev.gitlab.org:gitlab/omnibus-gitlab.git 6-6-stable 6.6.0+ce.0https://dev.gitlab.org/에 주석이 달린 태그를 푸시하면 패키지 릴리스가 트리거됩니다.
패키지 게시
패키지 빌드의 진행 상황은 https://dev.gitlab.org/gitlab/omnibus-gitlab/builds에서 추적할 수 있습니다. 성공적인 빌드 후에는 packagecloud 저장소로 자동으로 푸시됩니다.
클라우드 이미지 업데이트
클라우드 이미지 릴리스 프로세스는 여기에 문서화되어 있습니다: https://handbook.gitlab.com/handbook/alliances/cloud-images/.
새 이미지는 다음 경우에 릴리스됩니다:
- GitLab의 새로운 월간 릴리스가 있는 경우
- 패치 릴리스에서 보안 취약점이 수정된 경우
- 이미지에 중대한 문제가 영향을 미치는 패치가 있는 경우
새 이미지는 패키지 릴리스 후 3 영업일 이내에 릴리스되어야 합니다.
이미지별 릴리스 문서:
- (폐기 예정) OpenShift.
도움말