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

omnibus-gitlab CI 파이프라인은 프로젝트의 모든 미러 간에 파이프라인이 분할된 다소 복잡한 구조를 갖고 있습니다:

  1. 일반 기능 개발용 개발 저장소.
  2. 릴리스 아티팩트 빌드용 릴리스 미러.
  3. 보안 개발용 보안 미러.
  4. 개발자가 패키지 빌드 및 개발용 QA를 실행하는 QA 미러.

브랜치 및 태그 보호

보호된 브랜치

참고: 다른 사항이 명시되지 않은 경우, 목록에 나열된 사용자/그룹은 보호된 브랜치에 대해 병합 및 푸시 권한이 있습니다.

  1. 개발 저장소
    1. master: Maintainers, 배달팀
    2. *-stable : 배달팀, 릴리스 매니저
    3. *-stable-ee : 배달팀, 릴리스 매니저
    4. *-auto-deploy-* : Maintainers, delivery 그룹, managers 그룹
  2. 릴리스 미러:
    1. master: Maintainers
    2. *-stable : Maintainers
    3. *-stable-ee : Maintainers
    4. *-auto-deploy-* : Maintainers
  3. 보안 미러:
    1. master: GitLab 릴리스 도구 봇, GitLab 봇, 배달팀, 릴리스 매니저
    2. *-stable: GitLab 릴리스 도구 봇, GitLab 봇, 배달팀, 릴리스 매니저
    3. *-stable-ee: GitLab 릴리스 도구 봇, GitLab 봇, 배달팀, 릴리스 매니저
    4. *-auto-deploy-*: GitLab 릴리스 도구 봇, GitLab 봇, 배달팀, 릴리스 매니저
  4. QA 미러:
    1. master: 개발자 (병합 전용), Maintainers

참고: QA 미러의 master 브랜치에 개발자가 액세스하는 이유는 해당 브랜치에 대상 파이프라인을 실행해야 하기 때문입니다. 이 상황을 변경하기 위한 오픈 이슈가 있습니다.

보호된 태그

참고: 다른 사항이 명시되지 않은 경우, 목록에 나열된 사용자/그룹은 보호된 태그에 대해 병합 및 푸시 권한이 있습니다.

  1. 개발 저장소:
    1. * : Maintainers, 배달팀, 릴리스 매니저
  2. 릴리스 미러:
    1. *: Maintainers

  3. 보안 미러: 없음

  4. QA 미러: 없음

저장소 간 미러링

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

`mermaid graph TD A[개발 저장소] -->|보호된 브랜치| B[보안 미러] A[개발 저장소] -->|보호된 브랜치| C[릴리스 미러] A[개발 저장소] -->|모든 브랜치| D[QA 미러] B[보안 미러] -->|보호된 브랜치| C[릴리스 미러] B[보안 미러] -->|모든 브랜치| D[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 gem 캐시 및 패키지 빌드 캐시를 업데이트합니다. 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 보호되지 않은 브랜치 푸시에서 수행됩니다. danger-review와 같은 원하지 않는 작업을 포함하지 않습니다. 트리거 작업은 포함됩니다.
GITLAB_MR_PIPELINE Canonical, Security Canonical/Security의 브랜치를 가진 MR에서 수행됩니다(GitLab 및 팀 멤버의 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_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:package-and-test 빌드를 트리거합니다.
TRIGGERED_EE_PIPELINE QA EE 패키지 및 이미지로 e2e:package-and-test 빌드를 트리거합니다.
FORK_BRANCH_TEST_PIPELINE Forks 프로젝트의 포크에서 실행될 때 테스트 스위트를 실행합니다. 트리거 작업 및 danger-review와 같은 원하지 않는 작업을 포함하지 않습니다.
FORK_MR_PIPELINE Forks 프로젝트의 포크에서 실행될 MR입니다. 트리거 작업을 포함하지 않습니다.

브랜치 파이프라인

omnibus-gitlab은 아직 분리된 MR 파이프라인을 사용하지 않습니다. 따라서 브랜치 푸시로 인한 파이프라인이 이 프로젝트에서 만날 수 있는 일반적인 파이프라인입니다. 이러한 파이프라인은 개발 리포지토리, 보안 미러, 및 릴리스 미러에서 사용됩니다.

태그 파이프라인

릴리스 미러로의 태그 푸시는 릴리스 작업으로 파이프라인을 시작합니다. 개발 리포지토리 및 보안 미러로의 태그 푸시는 기본적인 스타일 체크와 유닛 테스트를 실행하는 일반적인 브랜치 푸시처럼 동작합니다(단, e2e:package-and-test 파이프라인을 시작할 옵션이 없음).

예약된 파이프라인

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

  1. 의존성 업데이트 - dependency_update 작업을 사용하여 오래된 종속성을 확인하는 파이프라인입니다.
  2. 라이선스 페이지 생성 - S3 버킷에서 라이선스 정보를 사용하여 라이선스 컬렉션 웹페이지를 채우는 파이프라인입니다.

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

  1. CE 매일밤 - GitLab CE용 매일 패키지와 Docker 이미지를 빌드하는 파이프라인입니다.
  2. EE 매일밤 - GitLab EE용 매일 패키지와 Docker 이미지를 빌드하는 파이프라인입니다.

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

자동 배포 파이프라인

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

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

트리거된 파이프라인

QA 미러에서 “e2e:package-and-test” 파이프라인을 실행하기 위해 트리거된 파이프라인을 사용합니다. 이는 개발 저장소 또는 GitLab 프로젝트의 파이프라인에서 트리거될 수 있습니다.

이 파이프라인은 개발자들에게 변경 사항을 테스트하기 위한 패키지 및 이미지를 제공하고, 이러한 아티팩트에 대해 자동으로 QA 실행을 수행하는 것을 목적으로 합니다. 또한, 이러한 아티팩트를 사용하여 생성된 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의 도움을 받아 병렬화되었습니다.

이 작업은 이전 파이프라인 실행의 knapsack 리포트를 캐시에서 가져와 현재 스펙 실행을 준비합니다.

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

<OS_NAME> specs

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

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

update-knapsack

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

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

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

이 작업은 artifact로 사용할 단일 패키지를 빌드합니다.

이 작업은 트리거된 파이프라인의 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>-브랜치

이 작업은 지정된 OS용 패키지를 빌드하고 결과 패키지를 S3 버킷에 푸시하여 이를 아티팩트로 사용할 수 있게 합니다.

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

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

도커-브랜치

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

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

QA-브랜치

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

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

릴리스 작업

<OS_NAME>

이 작업은 지정된 OS용 패키지를 빌드하고 결과 패키지를 S3 버킷에 푸시하여 이를 아티팩트로 사용할 수 있게 합니다.

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

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

<OS_NAME>-staging

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

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

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

<OS_NAME>-릴리스

이 작업은 내부 스테이징 저장소에서 패키지를 가져와 Packagecloud 인스턴스의 공개 저장소에 올립니다.

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

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

도커

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

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

도커-릴리스

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

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

도커-QA

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

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

QA-태그

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

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

AWS

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

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

AWS-Ultimate

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

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

AWS-Premium

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

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

AWS-CE-릴리스

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

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

AWS-Ultimate-Release

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

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

AWS-Premium-Release

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

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

create_omnibus_manifest

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

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

dependency_scanning

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

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

RAT-Nightly

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

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

RAT-Tag

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

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

license-upload

이 작업은 패키지의 모든 종속성의 라이센스 정보를 컴파일하여 S3 버킷에 업로드합니다. 이는 개발 리포지토리의 pages 예약된 작업에서 사용되어 라이센스 컬렉션 웹페이지를 작성합니다.

Housekeeping Jobs

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

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

이러한 캐시는 CACHE_UPDATE가 존재할 때 각각의 작업에서 스케줄된 파이프라인에서 업데이트됩니다.

dependency_update

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

이 작업은 DEPS_PIPELINE 변수가 존재할 때 개발 리포지토리에서 스케줄된 파이프라인에서만 실행됩니다.

dependencies_io_check

이 작업은 dependency_update 작업에서 만든 병합 요청에 의해 머지 요청이 발생할 때, QA 미러에서 e2e:package-and-test 파이프라인을 자동으로 트리거합니다 (Trigger:ce-package 작업과 유사).

이 작업은 dependency_update 작업이 머지 요청에 사용하는 형식인 브랜치 이름이 deps로 시작할 때 개발 리포지토리에서만 실행됩니다.

valdiate_packer_changes

이 작업은 packer 구성 파일이 유효한지 여부를 확인합니다.

이 작업은 Developemnt repository 및 Security mirror에서 packer 구성 파일 중 하나가 수정될 때만 실행됩니다.

페이지

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

이 작업은 개발 리포지토리 및 DEPS_PIPELINE 변수가 없는 예약된 파이프라인에서만 실행됩니다(이를 dependency_update 실행과 구분하기 위함).