Status | Authors | Coach | DRIs | Owning Stage | Created |
---|---|---|---|---|---|
proposed | devops verify | - |
GitLab CI 이벤트 제안 5: 통합 제안
이 제안에서는 응집된 이벤트 그룹을 위한 별도의 파일이 있습니다.
이 파일들은 .gitlab-ci.yml
구성 파일에 포함됩니다.
# my/events/packages.yaml
spec:
events:
- events/package/published
- events/audit/package/*
inputs:
env:
---
do_something:
script: ./run_for $[[ event.name ]] --env $[[ inputs.env ]]
rules:
- if: $[[ event.payload.package.name ]] == "my_package"
.gitlab-ci.yml
파일에서 구독을 활성화할 수 있습니다.
# .gitlab-ci.yml
include:
- local: my/events/packages.yaml
inputs:
env: test
GitLab은 포함된 파일의 변경을 감지하고 그들의 사양을 구문 분석합니다.
구독을 정의하는 데 필요한 모든 정보는 사양에 캡슐화되어 있어 전체 파일을 읽을 필요가 없습니다.
우리는 쉽게 spec
헤더를 읽고 이에 대한 체크섬을 계산하여 워크플로 식별자가 될 수 있습니다.
새로운 식별자를 보면 해당 프로젝트의 구독을 재정의하고 데이터베이스에 업셋하게 됩니다.
채널을 실행하는 게시자와 가입자를 매칭하기 위해 효율적인 GIN 인덱스 매칭 기술을 사용할 것입니다.
이 구문은 CI 컴포넌트와도 호환되며, GitLab 내에서 발생하는 이벤트를 대상으로 설계된 컴포넌트를 정의하는 데 용이합니다.
엔트리포인트 파일 변형 없음
이 제안의 또 다른 변형은 단일 GitLab CI YAML 구성 파일에서 벗어나는 것입니다.
이 경우 .gitlab/workflows/
와 같이 또 다른 검색 디렉터리를 정의할 것이고 거기에 모든 YAML 파일을 저장할 것입니다.
우리는 이들을 include
하지 않아도 될 것입니다. 왜냐하면 GitLab이 이를 자동으로 찾아낼 것이기 때문입니다.
이 기능을 이렇게 구현하기 위해서는 “.gitlab-ci.yml
파일의 사용자 정의 위치”와 같은 기능을 확장해야 할 것입니다.
예를 들어, 주요 구성 파일을 사용하지 않고 (GitLab CI YAML 파일은 여전히 지원됨):
# .gitlab/workflows/push.yml
spec:
events:
- events/repository/push
---
rspec-on-push:
script: bundle exec rspec
# .gitlab/workflows/merge_requests.yml
spec:
events:
- events/merge_request/push
---
rspec-on-mr-push:
script: bundle exec rspec
# .gitlab/workflows/schedules.yml
spec:
events:
- events/pipeline/schedule/run
---
smoke-test:
script: bundle exec rspec --smoke