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

omnibus-gitlab CI 파이프라인은 프로젝트의 모든 미러 간에 나뉜 파이프라인을 가진 중간 복잡도의 파이프라인입니다:

개발 저장소: 일반 기능 개발을 위한 저장소.
릴리스 미러: 릴리스 아티팩트를 빌드하기 위한 미러.
보안 미러: 보안 개발을 위한 미러.
QA 미러: 개발 목적으로 패키지 빌드 및 QA를 실행하기 위한 개발자를 위한 미러.

브랜치 및 태그 보호

보호된 브랜치

참고: 특별히 언급하지 않는 한, 나열된 사용자/그룹은 보호된 브랜치에 병합 및 푸시할 권한이 있습니다.

개발 저장소:
1. master: 유지보수자, Delivery team
2. *-stable: Delivery team, Release Managers
3. *-stable-ee: Delivery team, Release Managers
4. *-auto-deploy-*: 유지보수자, delivery group, managers group
릴리스 미러:
1. master: 유지보수자
2. *-stable: 유지보수자
3. *-stable-ee: 유지보수자
4. *-auto-deploy-*: 유지보수자
보안 미러:
1. master: GitLab Release Tools Bot, GitLab Bot, Delivery team, Release Managers
2. *-stable: GitLab Release Tools Bot, GitLab Bot, Delivery team, Release Managers
3. *-stable-ee: GitLab Release Tools Bot, GitLab Bot, Delivery team, Release Managers
4. *-auto-deploy-*: GitLab Release Tools Bot, GitLab Bot, Delivery team, Release Managers
QA 미러:
1. master: 개발자 (병합 전용), 유지보수자

참고: 개발자는 QA 미러의 master 브랜치에 접근할 수 있습니다. 이는 브랜치에 대한 트리거된 파이프라인을 실행하는 데 필요하기 때문입니다. 이 상황을 변경하기 위한 열린 이슈가 있습니다.

보호된 태그

특별히 명시되지 않는 한, 나열된 사용자/그룹은 보호된 태그에 대해 병합 및 푸시 권한이 있습니다.

개발 리포지토리:
1. * : Maintainers, Delivery team, Release Managers
릴리즈 미러:
1. *: Maintainers
보안 미러: 없음
QA 미러: 없음

리포지토리 간 미러링

대부분의 개발은 개발 리포지토리에서 이루어지며, 보안 관련 변경 사항은 보안 미러로 이동합니다. 이러한 변경 사항은 릴리즈 미러와 QA 미러로 미러링됩니다. 다음 다이어그램은 이러한 각 리포지토리 간에 미러링되는 내용을 설명합니다.

파이프라인 유형

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

파이프라인 유형	파이프라인이 실행되는 미러	비고
`DEPENDENCY_SCANNING_PIPELINE`	Canonical	의존성의 보안 취약성 검사. `DEPENDENCY_SCANNING` 변수를 `true`로 설정해야 합니다.
`DEPS_IO_VERSION_BUMP_PIPELINE`	Canonical	`deps.io`에 의해 수행된 브랜치 푸시 시. 브랜치에 `deps-` 접두사가 있어야 합니다.
`DEPS_IO_VERSION_CHECK_PIPELINE`	Canonical	업데이트를 감지하기 위해 `deps` 실행. `DEPS_PIPELINE` 변수를 `true`로 설정해야 합니다.
`LICENSE_PAGE_UPDATE_PIPELINE`	Canonical	라이센스 페이지 업데이트. `PAGES_UPDATE` 변수를 `true`로 설정해야 합니다.
`CACHE_UPDATE_PIPELINE`	Canonical, QA	젬 캐시 및 패키지 빌드 캐시 업데이트. `CACHE_UPDATE` 변수를 `true`로 설정해야 합니다.
`DURATION_PLOTTER_PIPELINE`	QA	빌드 기간을 플롯하기 위해 패키지 빌드. `DURATION_PLOTTER` 변수를 `true`로 설정해야 합니다.
`DOCS_PIPELINE`	Canonical, Security	브랜치 이름이 `docs-`로 시작하거나 `-docs`로 끝나야 합니다.
`PROTECTED_TEST_PIPELINE`	Canonical, Security	보호된 브랜치 및 태그에서. 트리거 작업 및 원치 않는 작업(예: danger-review)을 포함하지 않습니다.
`GITLAB_BRANCH_TEST_PIPELINE`	Canonical, Security	비보호 브랜치 푸시에서. 위험 리뷰와 같은 원치 않는 작업을 포함하지 않습니다. 트리거 작업을 포함합니다.
`GITLAB_MR_PIPELINE`	Canonical, Security	Canonical/Security의 브랜치에 있는 MR에서. 트리거 작업이 있습니다.
`AUTO_DEPLOY_BUILD_PIPELINE`	Release	자동 배포 태그가 푸시될 때 빌드됩니다.
`CE_BRANCH_BUILD_PIPELINE`	Release	일반 브랜치가 푸시될 때 빌드됩니다.
`CE_NIGHTLY_BUILD_PIPELINE`	Release	야간 CE 빌드.
`CE_RC_BUILD_PIPELINE`	Release	CE RC 태그가 푸시될 때 빌드됩니다.
`CE_TAG_BUILD_PIPELINE`	Release	안정적인 CE 태그가 푸시될 때 빌드됩니다.
`EE_BRANCH_BUILD_PIPELINE`	Release	일반 브랜치가 푸시될 때 빌드되지만, EE 파이프라인으로 강제되어야 합니다.
`EE_NIGHTLY_BUILD_PIPELINE`	Release	야간 EE 빌드. 파이프라인을 EE 파이프라인으로 강제해야 합니다.
`EE_RC_BUILD_PIPELINE`	Release	EE RC 태그가 푸시될 때 빌드됩니다.
`EE_TAG_BUILD_PIPELINE`	Release	안정적인 EE 태그가 푸시될 때 빌드됩니다.
`TRIGGER_CACHE_UPDATE_PIPELINE`	QA	트리거된 QA 파이프라인의 빌드 캐시를 업데이트합니다. `CACHE_UPDATE` 변수를 `true`로 설정해야 합니다.
`TRIGGERED_CE_PIPELINE`	QA	CE 패키지 및 이미지로 트리거된 e2e:test-on-omnibus 빌드입니다.
`TRIGGERED_EE_PIPELINE`	QA	EE 패키지 및 이미지로 트리거된 e2e:test-on-omnibus 빌드입니다.
`FORK_BRANCH_TEST_PIPELINE`	Forks	프로젝트의 포크에서 실행 시 테스트 스위트. 트리거 작업 및 원치 않는 작업(예: danger-review)을 포함하지 않습니다.
`FORK_MR_PIPELINE`	Forks	프로젝트의 포크에서 온 MR에서. 트리거 작업을 포함하지 않습니다.

브랜치 파이프라인

omnibus-gitlab은 아직 분리된 병합 요청 파이프라인을 사용하지 않습니다. 따라서, 브랜치 푸시로 인해 발생하는 파이프라인이 이 프로젝트에서 일반적으로 접하는 파이프라인입니다. 이 파이프라인은 개발 리포지토리, 보안 미러, 및 릴리즈 미러에서 사용됩니다.

태그 파이프라인

릴리즈 미러로의 태그 푸시는 릴리즈 작업으로 파이프라인을 시작합니다. 개발 리포지토리 및 보안 미러로의 태그 푸시는 일반 브랜치 푸시처럼 동작하며 (e2e:test-on-omnibus 파이프라인을 시작할 수 있는 옵션은 없습니다), 기본적인 스타일 검토 및 단위 테스트를 실행합니다.

일정 파이프라인

개발 리포지토리에는 두 개의 일정 파이프라인이 있습니다.

Dependencies Update - dependency_update 작업을 사용하여 구식 종속성을 확인하는 파이프라인입니다.
Generate license pages - S3 버킷의 라이선스 정보를 사용하여 라이선스 수집 웹페이지를 채우는 파이프라인입니다.

릴리즈 미러에는 두 개의 일정 파이프라인이 있습니다.

CE nightly - GitLab CE를 위한 야간 패키지 및 Docker 이미지를 빌드하는 파이프라인입니다.
EE nightly - GitLab EE를 위한 야간 패키지 및 Docker 이미지를 빌드하는 파이프라인입니다.

다른 미러에는 일정 파이프라인이 없습니다.

자동 배포 파이프라인

GitLab은 자동 배포 브랜치 및 태그를 릴리즈 과정에 사용합니다. 이 브랜치들은 <MAJOR>-<MINOR>-auto-deploy-<TIMESTAMP>라는 이름을 가지며, 태그는 <MAJOR>.<MINOR>.<TIMESTAMP>+<gitlab sha>.<omnibus-gitlab sha> 형식을 갖습니다.

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

트리거된 파이프라인

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

이 파이프라인은 개발자에게 변화를 테스트할 패키지 및 이미지를 제공할 뿐만 아니라 이 아티팩트에 대한 QA 실행을 자동으로 수행하는 것이 목표입니다. 또한 이 아티팩트를 사용하여 생성된 HA 인스턴스에 대한 QA 실행 옵션도 제공합니다.

CI 작업

개발 작업

`danger-review`

이 작업은 병합 요청에 대해 기본 요구 사항을 충족하는지 확인하기 위해 Danger 도구를 사용하여 검사를 수행합니다.

이 작업은 개발 리포지토리와 보안 미러에서 브랜치 및 태그 파이프라인에서만 실행됩니다.

`rubocop`

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

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

`docs-lint`

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

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

`review-docs-deploy`

현재 커밋의 변경 사항으로 GitLab Docs의 검토 앱을 배포하는 docs 빌드를 트리거하는 수동 작업입니다.

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

`review-docs-cleanup`

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

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

`<OS_NAME> knapsack`

RSpec 및 Chefspec을 사용하여 우리의 Chef 레시피 및 라이브러리를 커버하는 테스트가 있습니다. 이들은 knapsack의 도움으로 병렬화됩니다.

이 작업은 현재 사양 실행을 위해 이전 파이프라인 실행의 knapsack 보고서를 캐시에서 끌어와서 준비합니다.

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

`<OS_NAME> specs`

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

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

`update-knapsack`

이 작업은 단위 테스트의 각 개별 병렬 실행에서 보고서를 결합하고 최종 JSON 보고서를 준비합니다. 이 보고서는 MR 위젯에서 사양 상태를 표시하는 데 사용되며, 다음 파이프라인 실행에서 사용할 수 있도록 캐시에 업로드됩니다.

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

`Trigger:ce-package`

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

QA 실패를 디버그하려면 QA 실패 조사 섹션을 참조하십시오. 이 작업은 또한 Allure 보고서를 생성하며, Omnibus-GitLab에서의 테스트 보고서 생성에서 더 많은 정보와 데모를 확인할 수 있습니다.

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

`Trigger:ee-package`

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

이 작업은 브랜치 파이프라인에서 개발 리포지토리와 보안 미러에서만 실행됩니다.

`fetch-assets`

패키지를 빌드하기 위해, 우리는 이미 GitLab 또는 GitLab-FOSS 파이프라인에 의해 컴파일된 Rails 자산을 사용합니다. 이러한 파이프라인은 이를 Docker 이미지로 푸시하며, 우리는 여기서 이를 끌어와서 자산 자체를 미리 정의된 위치에 복사합니다.

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

`Trigger:package`

이 작업은 하나의 패키지를 빌드하며, 이는 아티팩트로 사용할 수 있습니다.

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

`Trigger:gitlab-docker`

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

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

`qa-subset-test`

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

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

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

`qa-remaining-test-manual`

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

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

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

`RAT`

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

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

`<OS_NAME>-branch`

이 작업은 지정된 OS에 대한 패키지를 빌드하고 결과 패키지를 S3 버킷에 푸시하며 아티팩트로 사용할 수 있도록 만듭니다.

이 작업은 브랜치 및 야간 파이프라인에서만 릴리스 미러에서 실행됩니다.

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

`Docker-branch`

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

이 작업은 브랜치 및 야간 파이프라인에서만 릴리스 미러에서 실행됩니다.

`QA-branch`

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

이 작업은 브랜치 및 야간 파이프라인에서만 릴리스 미러에서 실행됩니다.

릴리스 작업

`<OS_NAME>`

이 작업은 지정된 OS에 대한 패키지를 빌드하고 결과 패키지를 S3 버킷에 푸시하며 아티팩트로 사용할 수 있도록 만듭니다.

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

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

`<OS_NAME>-staging`

이 작업은 이전 작업에서 빌드된 패키지를 Packagecloud 인스턴스의 내부 스테이징 리포지토리에 업로드합니다.

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

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

`<OS_NAME>-release`

이 작업은 내부 스테이징 리포지토리에서 Packagecloud 인스턴스의 공개 리포지토리로 패키지를 가져옵니다.

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

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

`Docker`

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

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

`Docker-Release`

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

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

`Docker-QA`

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

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

`QA-Tag`

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

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

`AWS`

이 작업은 Ubuntu 20.04 패키지를 사용하여 비라이선스 AWS AMI를 빌드합니다.

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

`AWS-Ultimate`

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

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

`AWS-Premium`

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

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

`AWS-CE-Release`

이 작업은 현재 버전으로 AWS Marketplace의 GitLab Community Edition 목록을 업데이트합니다.

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

`AWS-Ultimate-Release`

이 작업은 현재 버전으로 AWS Marketplace의 GitLab Ultimate 목록을 업데이트합니다.

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

`AWS-Premium-Release`

이 작업은 현재 버전으로 AWS Marketplace의 GitLab Premium 목록을 업데이트합니다.

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

`create_omnibus_manifest`

이 작업은 dependency_scanning 작업에서 사용될 version-manifest.json 파일을 만듭니다.

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

`dependency_scanning`

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

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

`RAT-Nightly`

이 작업은 RAT 프로젝트에서 파이프라인을 트리거하여, 이 파이프라인에서 빌드된 야간 Ubuntu 22.04 패키지의 URL을 전달합니다.

그러면 해당 패키지를 사용하여 PostgreSQL HA 인스턴스가 실행되며, QA가 그 인스턴스를 대상으로 실행됩니다.

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

`RAT-Tag`

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

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

`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만 합니다.

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

`dependency_update`

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

이 작업은 DEPS_PIPELINE 변수가 존재할 때만 Development repository의 예약된 파이프라인에서 실행됩니다.

`dependencies_io_check`

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

이 작업은 분기가 deps로 시작할 때만 Development repository에서 실행됩니다 (이는 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 실행과 구별됩니다.

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

브랜치 및 태그 보호

보호된 브랜치

보호된 태그

리포지토리 간 미러링

파이프라인 유형

브랜치 파이프라인

태그 파이프라인

일정 파이프라인

자동 배포 파이프라인

트리거된 파이프라인

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-Release

Docker-QA

QA-Tag

AWS

AWS-Ultimate

AWS-Premium

AWS-CE-Release

AWS-Ultimate-Release

AWS-Premium-Release

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

도움말

기능 사용 가능성과 제품 평가판

도움받기

`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-Release`

`Docker-QA`

`QA-Tag`

`AWS`

`AWS-Ultimate`

`AWS-Premium`

`AWS-CE-Release`

`AWS-Ultimate-Release`

`AWS-Premium-Release`

`create_omnibus_manifest`

`dependency_scanning`

`RAT-Nightly`

`RAT-Tag`

`license-upload`

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

`dependency_update`

`dependencies_io_check`

`valdiate_packer_changes`

`pages`