• 브랜치 및 태그 보호
  • 보호된 브랜치
  • 보호된 태그
• 저장소 간 미러링
• 파이프라인 유형
  • 브랜치 파이프라인
  • 태그 파이프라인
  • 예약된 파이프라인
  • 자동 배포 파이프라인
  • 트리거된 파이프라인
• CI 작업
  • 개발 작업
    • danger-review
    • rubocop
    • docs-lint
    • review-docs-deploy
    • review-docs-cleanup
    • <OS_NAME> knapsack
    • <OS_NAME> specs
    • update-knapsack
    • Trigger:ce-package
    • Trigger:ee-package
    • fetch-assets
    • Trigger:package
    • Trigger:gitlab-docker
    • qa-subset-test
  • qa-remaining-test-manual
    • RAT
    • <OS_NAME>-branch
    • Docker-branch
    • QA-branch
• 릴리스 작업
  • <OS_NAME>
  • <OS_NAME>-staging
  • <OS_NAME>-release
  • Docker
  • Docker-릴리즈
  • Docker-QA
  • QA-Tag
  • AWS
  • AWS-Ultimate
  • AWS-Premium
  • AWS-CE-릴리즈
  • AWS-Ultimate-릴리즈
  • AWS-Premium-릴리즈
  • create_omnibus_manifest
  • dependency_scanning
  • RAT-Nightly
  • RAT-Tag
  • license-upload
• Housekeeping Jobs
  • update-gems-cache 및 update-trigger-package-cache
  • dependency_update
  • dependencies_io_check
  • valdiate_packer_changes
  • pages

저장소, 브랜치 및 CI 파이프라인

omnibus-gitlab CI 파이프라인은 프로젝트의 모든 미러 간에 파이프라인이 분리되어 있는 다소 복잡한 구조를 가지고 있습니다.

1. Development repository: 일반 기능 개발용
2. 릴리스 미러: 릴리스 artifact 빌드용
3. 보안 미러: 보안 개발용
4. QA 미러: 개발용 패키지 빌드 및 QA를 위한 개발자용

브랜치 및 태그 보호

보호된 브랜치

참고: 별도로 지정하지 않은 경우 나열된 사용자/그룹은 보호된 브랜치에 대해 푸시 및 머지 권한이 있습니다.

1. Development repository:
   1. master: Maintainers, Delivery team
   2. *-stable: Delivery team, 릴리스 관리자
   3. *-stable-ee: Delivery team, 릴리스 관리자
   4. *-auto-deploy-*: Maintainers, delivery group, managers group
2. 릴리스 미러:
   1. master: Maintainers
   2. *-stable: Maintainers
   3. *-stable-ee: Maintainers
   4. *-auto-deploy-*: Maintainers
3. 보안 미러:
   1. master: GitLab 릴리스 도구 봇, GitLab Bot, Delivery team, 릴리스 관리자
   2. *-stable: GitLab 릴리스 도구 봇, GitLab Bot, Delivery team, 릴리스 관리자
   3. *-stable-ee: GitLab 릴리스 도구 봇, GitLab Bot, Delivery team, 릴리스 관리자
   4. *-auto-deploy-*: GitLab 릴리스 도구 봇, GitLab Bot, Delivery team, 릴리스 관리자
4. QA 미러:
   1. master: 개발자(머지 전용), Maintainers

참고: QA 미러의 개발자는 해당 브랜치에 대한 액세스 권한이 있어야하는데, 그것은 브랜치에 대한 트리거된 파이프라인을 실행하는 데 필요하기 때문입니다. 이 문제를 변경하는 데 대한 오픈 이슈가 있습니다.

보호된 태그

참고: 별도로 지정하지 않은 경우 나열된 사용자/그룹은 보호된 태그에 대해 푸시 및 머지 권한이 있습니다.

1. Development repository:
   1. *: Maintainers, Delivery team, 릴리스 관리자
2. 릴리스 미러:
   1. *: Maintainers

3. 보안 미러: Nil

4. QA 미러: Nil

저장소 간 미러링

대부분의 개발은 Development repository에서 이루어지며, 보안 관련 변경 사항은 Security mirror로 전달됩니다. 그런 다음 이러한 변경 사항은 릴리스 미러 및 QA 미러로 미러링됩니다. 다음 다이어그램은 각 저장소 간에 미러링되는 내용을 설명합니다.

파이프라인 유형

omnibus-gitlab의 작업은 여러 미러에 걸쳐 퍼져 있기 때문에, 작업을 실행할 위치/시간을 지정하는 데 rules 키워드를 사용한 CI 구성이 상대적으로 복잡해집니다. 따라서 omnibus-gitlab에서는 각 필요한 파이프라인 유형을 PIPELINE_TYPE이라는 특정 변수로 지정하고, 필요에 따라 다양한 파이프라인 유형에 작업을 연결하는 다른 방식이 사용됩니다. 다양한 파이프라인 유형은 아래 표에 문서화되어 있습니다:

브랜치 파이프라인

omnibus-gitlab은 아직 분리된 병합 요청 파이프라인을 사용하지 않습니다. 그래서 브랜치 푸시로 인해 발생하는 파이프라인은 이 프로젝트에서 일반적으로 마주하는 파이프라인입니다. 이러한 파이프라인은 개발 저장소, 보안 미러, 그리고 릴리스 미러에서 사용됩니다.

태그 파이프라인

릴리스 미러로의 태그 푸시는 릴리스 작업을 시작시킵니다. 개발 저장소 및 보안 미러로의 태그 푸시는 일반적인 브랜치 푸시와 동일하게 작동합니다(단, e2e:test-on-omnibus 파이프라인을 시작할 수없다는 차이점이 있음) 및 기본적인 스타일 체크 및 유닛 테스트를 실행합니다.

예약된 파이프라인

개발 저장소에서 두 개의 예약된 파이프라인이 있습니다.

1. 의존성 업데이트 - dependency_update 작업을 사용하여 구버전 의존성을 확인하는 파이프라인
2. 라이센스 페이지 생성 - 라이센스 수집 웹페이지를 S3 버킷의 라이센스 정보로 채우는 파이프라인

릴리스 미러에서 두 개의 예약된 파이프라인이 있습니다.

1. CE nightly - GitLab CE용 nightly 패키지 및 도커 이미지를 빌드하는 파이프라인
2. EE nightly - GitLab EE용 nightly 패키지 및 도커 이미지를 빌드하는 파이프라인

다른 미러에는 예약된 파이프라인이 없습니다.

자동 배포 파이프라인

GitLab은 릴리스 프로세스에 대해 자동 배포 브랜치와 태그를 사용합니다. 이러한 브랜치는 <주요>-<마이너>-auto-deploy-<타임스탬프>로 명명되며, 태그는 <주요>.<마이너>.<타임스탬프>+<gitlab sha>.<omnibus-gitlab sha> 형식을 갖습니다.

GitLab 환경에 변경 사항을 배포하는 데 필요한 특정 작업만이 이 파이프라인의 일부가 될 것입니다.

트리거된 파이프라인

우리는 “e2e:test-on-omnibus” 파이프라인을 QA 미러에서 실행하기 위해 트리거된 파이프라인을 사용합니다. 이것은 개발 저장소나 GitLab 프로젝트에서 파이프라인을 트리거할 수 있습니다.

본 파이프라인은 개발자들에게 변경 사항을 테스트할 수 있는 패키지와 이미지를 제공하고, 이러한 artifact에 대한 자동 QA 실행을 수행하는 것을 목적으로 합니다. 또한, 이러한 artifact를 사용하여 생성된 HA 인스턴스에 대한 QA 실행을 수행할 수 있는 옵션을 제공합니다.

CI 작업

개발 작업

danger-review

이 작업은 Danger 도구를 사용하여 병합 요청을 체크하여 일부 기본 요구사항을 충족시키는지 확인합니다.

이 작업은 브랜치 및 태그 파이프라인에서만 개발 저장소 및 보안 미러에서 실행됩니다.

rubocop

소스 코드 파일을 확인하여 특정한 스타일 요구사항을 충족하는지 확인합니다.

이 작업은 브랜치 및 태그 파이프라인에서만 개발 저장소 및 보안 미러에서 실행됩니다.

docs-lint

특정한 스타일 요구사항을 충족하는지 확인하기 위해 문서 파일을 확인합니다.

이 작업은 브랜치 및 태그 파이프라인에서만 개발 저장소 및 보안 미러에서 실행됩니다.

review-docs-deploy

gitlab-docs에서 문서 빌드를 트리거하고, 현재 커밋의 변경 사항을 반영하는 GitLab Docs의 리뷰 앱을 배포하는 수동 작업입니다.

이 작업은 브랜치 파이프라인에서만 개발 저장소에서 실행됩니다.

review-docs-cleanup

review-docs-deploy에 의해 생성된 환경을 정지하는 수동 작업. 병합 요청이 병합되면 자동으로 실행됩니다.

이 작업은 브랜치 파이프라인에서만 개발 저장소에서 실행됩니다.

<OS_NAME> knapsack

RSpec 및 Chefspec를 사용하여 Chef 레시피 및 라이브러리를 테스트합니다. knapsack의 도움을 받아 병렬로 실행됩니다.

이 작업은 브랜치 및 태그 파이프라인에서만 개발 저장소 및 보안 미러에서 실행됩니다.

<OS_NAME> specs

실제로 knapsack를 통해 rspec를 실행하는 작업. parallel 키워드를 사용하여 6개로 병렬화됩니다.

이 작업은 브랜치 및 태그 파이프라인에서만 개발 저장소 및 보안 미러에서 실행됩니다.

update-knapsack

단위 테스트의 각 병렬 실행에서 나오는 knapsack 보고서를 결합하여 최종 JSON 보고서를 준비합니다. 이 보고서는 MR 위젯에서 spec 상태를 표시하는 데 사용되며, 다음 파이프라인 실행에 대한 캐시에도 업로드됩니다.

이 작업은 브랜치 및 태그 파이프라인에서만 개발 저장소 및 보안 미러에서 실행됩니다.

Trigger:ce-package

이것은 수동 작업으로, 재생시 QA mirror에서 파이프라인을 트리거하여 개발 목적으로 패키지 빌드 및 QA를 실행합니다. 개발자는 테스트를 위해 패키지나 Docker 이미지를 얻거나 MR 변경 사항에 대해 전체 QA 스위트를 실행하는 데 사용할 수 있습니다.

QA 실패를 디버깅하려면 Investigate QA failures 섹션을 참조하십시오. 이 작업은 또한 Allure 보고서를 생성하며 자세한 정보 및 데모는 Omnibus-GitLab에서의 테스트 보고서 생성에서 확인할 수 있습니다.

이 작업은 브랜치 파이프라인에서만 Development repository 및 Security mirror에서 실행됩니다.

Trigger:ee-package

Trigger:ce-package와 동일하지만 EE 패키지를 빌드합니다.

이 작업은 브랜치 파이프라인에서만 Development repository 및 Security mirror에서 실행됩니다.

fetch-assets

패키지 빌드를 위해 이미 GitLab 또는 GitLab-FOSS 파이프라인에서 컴파일된 Rails 에셋을 활용합니다. 이러한 파이프라인은 Docker 이미지로 푸시하고, 여기에서 해당 이미지를 가져와 에셋 자체를 지정된 위치로 복사합니다.

이 작업은 브랜치, 태그 및 트리거된 파이프라인에서만 Release mirror 및 QA mirror에서 실행됩니다.

Trigger:package

이 작업은 아티팩트로 사용 가능한 단일 패키지를 빌드합니다.

이 작업은 트리거된 파이프라인에서만 QA mirror에서 실행됩니다.

Trigger:gitlab-docker

이 작업은 Trigger:package 작업에서 빌드된 패키지를 사용하여 GitLab Docker 이미지를 빌드합니다.

이 작업은 트리거된 파이프라인에서만 QA mirror에서 실행됩니다.

qa-subset-test

이 작업은 테스트 스위트의 하위 집합을 실행하며, 수동으로 Trigger:CE-package 또는 Trigger:EE-package 작업이 수동으로 트리거될 때 자동으로 트리거됩니다.

이 작업은 GitLab QA Mirror에서 파이프라인을 트리거하며, Trigger:gitlab-docker 작업에서 생성된 GitLab Docker 이미지 및 GitLab Rails 파이프라인에서 빌드된 GitLab QA Docker 이미지를 전달하여 이 문제에서 언급된 테스트의 하위 집합을 사용하여 이러한 이미지를 사용하여 실행합니다.

이 작업은 트리거된 파이프라인에서만 QA mirror에서 실행됩니다.

qa-remaining-test-manual

이것은 수동 트리거 작업으로, qa-subset-test 작업에서 실행되지 않는 나머지 테스트를 실행합니다.

MR 파이프라인에서 이 QA 작업을 실행하려면 수동으로 Trigger:CE-package 또는 Trigger:EE-package 작업을 트리거해야 합니다.

이 작업은 GitLab QA Mirror에서 파이프라인을 트리거하며, Trigger:gitlab-docker 작업에서 생성된 GitLab Docker 이미지 및 GitLab Rails 파이프라인에서 빌드된 GitLab QA Docker 이미지를 전달하여 전체 스위트를 이러한 이미지를 사용하여 실행합니다.

RAT

이 수동 작업은 RAT 프로젝트에서 파이프라인을 트리거하며, Trigger:package 작업에서 빌드된 패키지의 URL을 전달하여 해당 패키지를 사용하여 PostgreSQL HA 인스턴스를 생성하고 GET을 사용하여 해당 인스턴스에서 실행하여 QA를 실행합니다.

이 작업은 트리거된 EE 파이프라인에서만 QA mirror에서 실행됩니다.

<OS_NAME>-branch

이러한 작업은 지정된 OS용 패키지를 빌드하고 나아가 S3 버킷에 결과 패키지를 푸시하는 작업입니다.

이 작업은 브랜치 및 nightly 파이프라인에서만 Release mirror에서 실행됩니다.

NOTE: Raspberry Pi 작업은 CE 브랜치에서만 실행되며, SLES 작업은 EE 브랜치에서만 실행됩니다.

Docker-branch

이 작업은 Ubuntu 22.04-branch 작업 중에 빌드된 패키지를 사용하여 GitLab Docker 이미지를 빌드합니다. 이미지는 GitLab 컨테이너 레지스트리에 푸시됩니다.

이 작업은 브랜치 및 nightly 파이프라인에서만 Release mirror에서 실행됩니다.

QA-branch

이 작업은 Rails 코드베이스의 qa 디렉터리에서 GitLab QA Docker 이미지를 빌드합니다.

이 작업은 브랜치 및 nightly 파이프라인에서만 Release mirror에서 실행됩니다.

릴리스 작업

<OS_NAME>

이러한 작업은 지정된 OS용 패키지를 빌드하고 결과 패키지를 S3 버킷에 푸시하는 작업입니다.

이 작업은 태그 파이프라인에서만 Release mirror에서 실행됩니다.

NOTE: Raspberry Pi 작업은 CE 태그에서만 실행되며, SLES 작업은 EE 태그에서만 실행됩니다.

<OS_NAME>-staging

이러한 작업은 이전 작업에서 빌드된 패키지를 내부 스테이징 저장소인 Packagecloud instance에 업로드합니다.

이 작업은 태그 파이프라인에서만 Release mirror에서 실행됩니다.

NOTE: Raspberry Pi 작업은 CE 태그에서만 실행되며, SLES 작업은 EE 태그에서만 실행됩니다.

<OS_NAME>-release

이러한 작업은 내부 스테이징 저장소에서 패키지를 공개 리포지토리인 Packagecloud instance로 가져옵니다.

이 작업은 태그 파이프라인에서만 릴리스 미러에서 실행됩니다.

참고: Raspberry Pi 작업은 CE 태그에서만 실행되며, SLES 작업은 EE 태그에서만 실행됩니다.

Docker

이 작업은 Ubuntu 22.04-branch 작업 중에 빌드된 패키지를 사용하여 GitLab Docker 이미지를 빌드합니다. 그런 다음 해당 이미지를 내부 GitLab 컨테이너 레지스트리에 푸시합니다.

이 작업은 태그 파이프라인에서만 릴리스 미러에서 실행됩니다.

Docker-릴리즈

이 작업은 내부 GitLab 컨테이너 레지스트리에서 GitLab Docker 이미지를 가져와 Dockerhub에 푸시합니다.

이 작업은 태그 파이프라인에서만 릴리스 미러에서 실행됩니다.

Docker-QA

이 작업은 Rails 코드베이스의 qa 디렉터리에서 GitLab QA Docker 이미지를 빌드하고 내부 GitLab 컨테이너 레지스트리에 푸시합니다.

이 작업은 릴리스 미러 및 태그 파이프라인에서만 실행됩니다.

QA-Tag

이 작업은 내부 GitLab 컨테이너 레지스트리에서 GitLab QA Docker 이미지를 가져와 Dockerhub에 푸시합니다.

이 작업은 릴리스 미러 및 태그 파이프라인에서만 실행됩니다.

AWS

이 작업은 Ubuntu 20.04 패키지를 사용하여 라이선스 없는 AWS AMI(Amazon Machine Image)를 빌드합니다.

이 작업은 릴리스 미러 및 태그 파이프라인에서만 실행됩니다.

AWS-Ultimate

이 작업은 Ubuntu 20.04 패키지를 사용하여 내장된 Ultimate 라이선스가 포함된 AWS AMI(Amazon Machine Image)를 빌드합니다.

이 작업은 릴리스 미러 및 EE 태그 파이프라인에서만 실행됩니다.

AWS-Premium

이 작업은 Ubuntu 20.04 패키지를 사용하여 내장된 Premium 라이선스가 포함된 AWS AMI(Amazon Machine Image)를 빌드합니다.

이 작업은 릴리스 미러 및 EE 태그 파이프라인에서만 실행됩니다.

AWS-CE-릴리즈

이 작업은 현재 버전을 사용하여 AWS Marketplace의 GitLab Community Edition 목록을 업데이트합니다.

이 작업은 릴리스 미러 및 CE 태그 파이프라인에서만 실행됩니다.

AWS-Ultimate-릴리즈

이 작업은 현재 버전을 사용하여 AWS Marketplace의 GitLab Ultimate 목록을 업데이트합니다.

이 작업은 릴리스 미러 및 EE 태그 파이프라인에서만 실행됩니다.

AWS-Premium-릴리즈

이 작업은 현재 버전을 사용하여 AWS Marketplace의 GitLab Premium 목록을 업데이트합니다.

이 작업은 릴리스 미러 및 EE 태그 파이프라인에서만 실행됩니다.

create_omnibus_manifest

이 작업은 dependency_scanning 작업에서 사용할 version-manifest.json 파일을 생성합니다.

이 작업은 릴리스 미러 및 태그 및 nightly 파이프라인에서만 실행됩니다.

dependency_scanning

이 작업은 패키지의 모든 구성 요소에 대해 종속성 스캔을 실행하여 알려진 취약점이 있는지 확인합니다.

이 작업은 릴리스 미러 및 태그 및 nightly 파이프라인에서만 실행됩니다.

RAT-Nightly

이 작업은 이 파이프라인에서 빌드된 nightly Ubuntu 22.04 패키지의 URL을 전달하여 RAT 프로젝트에서 파이프라인을 트리거하고 해당 패키지를 사용하여 PostgreSQL HA 인스턴스를 실행하여 해당 인스턴스에서 QA를 실행합니다.

이 작업은 릴리스 미러에서만 nightly 파이프라인에서 실행됩니다.

RAT-Tag

이 작업은 이 파이프라인에서 빌드된 Ubuntu 22.04 패키지의 URL을 전달하여 RAT 프로젝트에서 파이프라인을 트리거하고 해당 패키지를 사용하여 PostgreSQL HA 인스턴스를 실행하여 해당 인스턴스에서 QA를 실행합니다.

이 작업은 릴리스 미러에서만 EE 태그 파이프라인에서 실행됩니다.

license-upload

이 작업은 패키지의 모든 종속성의 라이선스 정보를 컴파일하고 S3 버킷에 업로드합니다. 이는 Development repository의 pages 예약된 작업에서 사용하여 License collection webpage을 작성합니다.

Housekeeping Jobs

update-gems-cache 및 update-trigger-package-cache

.gems-cache 및 .trigger-package-cache 공유 cache 정의에서 확장된 작업은 캐시를 pull만 합니다.

이 캐시는 각각 update-gems-cache 및 update-trigger-package-cache 작업이 CACHE_UPDATE가 존재할 때 예약된 파이프라인에서 업데이트됩니다.

dependency_update

이 작업은 우리의 패키지에 포함된 다양한 구성 요소의 버전 업데이트를 자동으로 확인하기 위해 Dependencies.io를 사용하고, 업데이트가 발견되면 Development repository에 대한 병합 요청을 엽니다.

이 작업은 DEPS_PIPELINE 변수가 있는 경우에만, 예약된 파이프라인에서만 Development repository에서만 실행됩니다.

dependencies_io_check

이 작업은 dependency_update 작업이 병합 요청을 작성할 때, QA mirror에서 e2e:test-on-omnibus 파이프라인을 자동으로 트리거합니다. (Trigger:ce-package 작업과 유사)

이 작업은 dependency_update 작업이 병합 요청을 작성하는 경우에만 Development repository에서 실행됩니다. 브랜치 이름이 deps로 시작될 때 실행됩니다 (dependency_update 작업이 병합 요청에 사용하는 형식입니다).

valdiate_packer_changes

이 작업은 packer 구성 파일인 https://dev.gitlab.org/gitlab/omnibus-gitlab/-/tree/master/support/packer이 유효한지 확인합니다.

이 작업은 packer 구성 파일 중 하나가 수정될 때, Development repository 및 Security mirror인 https://gitlab.com/gitlab-org/security/omnibus-gitlab에서만 실행됩니다.

pages

이 작업은 GitLab Pages와 관련이 있으며, GitLab의 각 릴리스에 포함된 다양한 구성 요소의 라이선스 정보를 포함하는 정적 웹사이트를 생성합니다.

이 작업은 DEPS_PIPELINE 변수가 없는 예약된 파이프라인에서만 Development repository에서만 실행됩니다 (dependency_update 실행과 구별하기 위해).