Status | Authors | Coach | DRIs | Owning Stage | Created |
---|---|---|---|---|---|
proposed | devops verify | - |
GitLab Steps을 .gitlab-ci.yml과 함께 사용하는 방법
이 문서는 GitLab Steps이 .gitlab-ci.yml
에 통합되는 방법을 설명합니다.
GitLab Steps은 3단계 실행 주기를 사용하여 통합됩니다.
그리고 before_script:
, script:
, after_script:
을 대체할 것입니다.
-
setup:
: 리포지터리 클론, 아티팩트 복원 또는 모든 의존성 설치를 포함하여 환경을 프로비저닝하는 실행 단계입니다. 이 단계는 암묵적으로 클론, 아티팩트 복원 및 캐시 다운로드를 대체할 것입니다. -
run:
: 테스트 실행 또는 빌드를 실행하는 실행 단계입니다. -
teardown:
: 환경을 정리하거나 아티팩트를 업로드, 캐시를 저장하는 실행 단계입니다. 이 단계는 암묵적으로 아티팩트 및 캐시 업로드를 대체할 것입니다.
우리는 세 단계 실행을 달성하기 전에 사전 GitLab 통합이 필요 없는 최소한의 초기 지원을 제공할 것입니다.
단계 1: 초기 지원
초반에는 Step Runner가 사전 의존성 없이 외부적으로 사용될 것입니다:
-
step-runner
는 컨테이너 이미지의 일부로 제공될 것입니다. -
step-runner
는script:
섹션에서 명시적으로 실행될 것입니다. -
$STEPS
환경 변수는type: steps
으로 실행될 것입니다.
hello-world:
image: registry.gitlab.com/gitlab-org/step-runner
variables:
STEPS: |
- step: gitlab.com/josephburnett/component-hello-steppy@master
inputs:
greeting: "hello world"
script:
- /step-runner ci
단계 2: .gitlab-ci.yml
에 run:
추가
2단계에서는 run:
을 GitLab Steps를 사용하는 첫 번째 방법으로 추가할 것입니다:
-
run:
은type: steps
구문을 사용할 것입니다. -
run:
은before_script
,script
및after_script
사용을 대체할 것입니다. - Git 클론, 아티팩트 및 캐시 지원을 계속 지원할 것입니다.
- 무조건적으로 또는 작업이 취소될 때 실행되는
after_script
를 어떻게 지원할지 아직 정의되지 않았습니다. -
run:
은before_script:
,script:
,after_script:
와 결합하여 사용될 수 없을 것입니다. - GitLab Rails는
run:
을 구문분석하지 않고, Step Runner에서 제공하는 JSON 스키마를 통해 정적 유효성 검사만을 수행할 것입니다.
hello-world:
image: registry.gitlab.com/gitlab-org/step-runner
run:
- step: gitlab.com/josephburnett/component-hello-steppy@master
inputs:
greeting: "hello world"
다음 예제는 구문 검사에서 실패할 것입니다:
hello-world:
image: registry.gitlab.com/gitlab-org/step-runner
run:
- step: gitlab.com/josephburnett/component-hello-steppy@master
inputs:
greeting: "hello world"
script: echo "This is ambiguous and invalid example"
before_script:
, script:
, after_script:
에서의 전환
GitLab Rails는 *script:
구문을 관련된 run:
명세로 자동으로 변환할 것입니다:
- 현재
before_script:
과script:
은 실행을 위해 하나의 스크립트로 합쳐집니다. -
after_script:
섹션은 항상 별도의 문맥에서 실행되며, 별도로 실행할 단계를 나타냅니다. - 작업 상태나 타임아웃에 관계없이 항상 실행되고 별도의 타임아웃을 사용하는
after_script
의 기존 동작을 어떻게 유지할지 아직 정의되지 않았습니다. -
script:
을 단계 기반 실행으로 변환할 때 환경 변수를 정의하는 모든 암시적 동작을 유지할 것입니다.
예를 들어, 다음 CI/CD 구성:
hello-world:
before_script:
- echo "Run before_script"
script:
- echo "Run script"
after_script:
- echo "Run after_script"
다음과 같은 동등한 명세로 변환될 수 있습니다:
hello-world:
run:
- step: gitlab.com/gitlab-org/components/steps/legacy/script@v1.0
inputs:
script:
- echo "Run before_script"
- echo "Run script"
- step: gitlab.com/gitlab-org/components/steps/legacy/script@v1.0
inputs:
script:
- echo "Run after_script"
when: always
단계 3: .gitlab-ci.yml
에 setup:
및 teardown:
추가
setup:
과 teardown:
의 추가는 GitLab Runner가 암시적으로 제공하는 기능을 대체할 것입니다:
-
setup:
사용은 GitLab Runner가 리포지터리를 암시적으로 클론하는 것을 중지할 것입니다. - 이전 구문에 대한 백워드 호환성을 제공하기 위해, 명시된 경우
artifacts:
와cache:
는setup:
및teardown:
에 번역되어 추가될 것입니다. - 명시된 경우
release:
는teardown:
에 번역되어 추가될 것입니다. -
setup:
과teardown:
은default:
에서 사용되어 리포지터리의 클론 방법 또는 아티팩트 처리 방법과 같은 일반적인 작업 흐름을 단순화하는 데 사용될 수 있습니다. - 3단계 실행으로 단계를 분리함으로써
extends:
를 사용하여 단계의 구성을 더욱 쉽게 만드는 것도 포함하여 단계의 구성성을 더욱 향상시킵니다. -
hooks:pre_get_sources_script
은script:
과 유사하게 구현되며setup:
앞에 추가될 것입니다.
예를 들어, 다음 CI/CD 구성:
rspec:
script:
- echo "This job uses a cache."
artifacts:
paths: [binaries/, .config]
cache:
key: binaries-cache
paths: [binaries/*.apk, .config]
다음과 같이 Step Runner에서 실행될 동등한 명세로 변환될 수 있습니다:
rspec:
setup:
- step: gitlab.com/gitlab-org/components/git/clone@v1.0
- step: gitlab.com/gitlab-org/components/artifacts/download@v1.0
- step: gitlab.com/gitlab-org/components/cache/restore@v1.0
inputs:
key: binaries-cache
run:
- step: gitlab.com/gitlab-org/components/steps/legacy/script@v1.0
inputs:
script:
- echo "This job uses a cache."
teardown:
- step: gitlab.com/gitlab-org/components/artifacts/upload@v1.0
inputs:
paths: [binaries/, .config]
- step: gitlab.com/gitlab-org/components/cache/restore@v1.0
inputs:
key: binaries-cache
paths: [binaries/*.apk, .config]
default:
로 일반 작업 상속
시간이 지남에 따라 setup:
과 teardown:
은 매우 장황해질 수 있습니다. 이를 단순화하는 한 가지 방법은 default:
를 사용하여 공통 setup:
및 teardown:
작업을 상속하는 것입니다.
이전 예제는 다음과 같이 단순화될 수 있습니다:
default:
setup:
- step: gitlab.com/gitlab-org/components/git/clone@v1.0
- step: gitlab.com/gitlab-org/components/artifacts/download@v1.0
- step: gitlab.com/gitlab-org/components/cache/restore@v1.0
inputs:
key: binaries-cache
teardown:
- step: gitlab.com/gitlab-org/components/artifacts/upload@v1.0
inputs:
paths: [binaries/, .config]
- step: gitlab.com/gitlab-org/components/cache/restore@v1.0
inputs:
key: binaries-cache
paths: [binaries/*.apk, .config]
rspec:
run:
- step: gitlab.com/gitlab-org/components/steps/legacy/script@v1.0
inputs:
script:
- echo "This job uses a cache."
linter:
run:
- step: gitlab.com/gitlab-org/components/steps/legacy/script@v1.0
inputs:
script:
- echo "Run linting"
병렬 작업과 setup:
setup:
의 도입으로 향후 어느 시점에든 작업을 병렬화하는 효율적인 방법을 도입할 것입니다.
-
setup:
은 환경을 프로비저닝하는 데 필요한 모든 단계를 정의할 것입니다. -
setup:
의 결과는 병렬 작업을 위한 기본으로서 스냅샷으로 만들어지고 분배될 것입니다. 이때parallel: N
이 사용됩니다. -
run:
및teardown:
은 복제된 작업과 해당 서비스 위에서 실행될 것입니다. - 러너는 모든 병렬 작업을 제어하고 지능적으로 분배하여 작업의 고정된 부분(예: Git 클론, 아티팩트, 의존성 설치)에 대한 리소스 요구 사항을 크게 줄일 것입니다.
rspec-parallel:
image: ruby:3.2
services: [postgres, redis]
parallel: 10
setup:
- step: gitlab.com/gitlab-org/components/git/clone@v1.0
- step: gitlab.com/gitlab-org/components/artifacts/download@v1.0
inputs:
jobs: [setup-all]
- script: bundle install --without production
run:
- script: bundle exec knapsack
잠재적인 GitLab 러너 흐름:
- 러너가
setup:
및parallel:
이 구성된rspec-parallel
작업을 받습니다. - 러너는 블록 볼륨을 사용하여 Kubernetes 클러스터 상에서
setup
까지 작업을 실행합니다. - 그 후 러너는 Kubernetes에서 10개의 병렬 작업을 실행하고 2번의 블록 볼륨을 오버레이하며
run:
및teardown:
을 계속하여 실행합니다.