This page contains information related to upcoming products, features, and functionality.
It is important to note that the information presented is for informational purposes only.
Please do not rely on this information for purchasing or planning purposes.
The development, release, and timing of any products, features, or functionality may be subject to change or delay and remain at the
sole discretion of GitLab Inc.
Status | Authors | Coach | DRIs | Owning Stage | Created |
---|---|---|---|---|---|
proposed |
@furkanayhan
|
@grzesiek
|
@fabiopitino
@jreporter
@cheryl.li
| devops verify | 2023-03-15 |
GitLab CI 이벤트
요약
혁신을 끌어내고 더 많은 가치를 창출하기 위해, GitLab은 DevSecOps 프로세스와 관련된 자동화의 중심이 되기를 기대합니다. 우리는 GitLab을 CI/CD 파이프라인 위에 다양한 워크플로우를 모델링할 수 있는 프로그래밍 환경으로 바꾸고 싶습니다. 오늘날 사용자들은 필요한 워크플로를 구축하기 위해 웹훅이나 예약된 파이프라인 주변에 사용자 정의 자동화를 만들어야 합니다.
우리의 사용자들이 이 자동화를 보다 쉽게 만들기 위해, 우리는 파이프라인이 GitLab 내부나 외부에서 무엇이 일어나든지 상관없이 실행될 수 있게 하는 강력한 CI/CD 이벤트 시스템을 구축하고자 합니다.
전형적인 사용 사례는 누군가 이슈를 생성하거나 댓글을 게시하거나, Merge Request 상태를 “드래프트”에서 “리뷰 준비 완료”로 변경하거나, 그룹에 새 멤버를 추가할 때마다 CI/CD 작업을 실행하는 것입니다.
이러한 새로운 기술을 구축하기 위해, 우리는 다음을 해야 합니다:
- 오늘보다 발전된 방식으로 GitLab 내에서 많은 계층적 이벤트를 발생시킵니다.
- GitLab 이벤트에 반응하는 이 자동화를 대규모로 실행할 수 있도록 합니다.
- 자동화 작성을 보다 쉽게 만들기 위해 일련의 규칙과 라이브러리를 제공합니다.
목표
“GitLab 이벤트 플랫폼”은 GitLab에서 이벤트를 발생시키는 새로운 추상화를 구축하려는 목표를 가지고 있으며, “GitLab CI 이벤트” 청사진은 다음을 가능하게 하는 데 관한 것입니다:
- 사용자가 이벤트가 발생했을 때 CI 파이프라인이 실행되는 방식을 정의합니다.
- GitLab.com 규모 및 그 이상의 이벤트와의 구독을 매칭하기 위해 필요한 기술을 설명합니다.
- 자동화 작업의 비용을 크게 줄일 수 있는 기술을 설명합니다.
제안
결정
요구 사항
수락된 제안은 다음 요구 사항과 특성을 고려해야 합니다:
- 이벤트를 정의하는 것은 별도의 파일에서 이루어져야 합니다.
- 모든 이벤트를 단일 파일에 정의하면 해당 파일이 지나치게 복잡해지고 사용자들에게 유지 관리가 어려워집니다. 그러면 사용자들은 다시
include
키워드로 설정을 분리해야 하고 동일한 문제가 발생하게 됩니다. - 파이프라인의 구조, 개인 및 작업은 구독하는 이벤트 및 구독 목표에 따라 다를 것입니다.
- 모든 이벤트를 단일 파일에 정의하면 해당 파일이 지나치게 복잡해지고 사용자들에게 유지 관리가 어려워집니다. 그러면 사용자들은 다시
- 단일 구독 구성 파일은 이벤트가 트리거될 때 만들어지는 단일 파이프라인을 정의해야 합니다.
- 파이프라인 구성에 다른 파일을
include
키워드로 포함시킬 수 있습니다. - 파이프라인에는 많은 작업이 포함될 수 있으며 하위 파이프라인이나 다중 프로젝트 파이프라인을 트리거할 수 있습니다.
- 파이프라인 구성에 다른 파일을
- 이벤트 및 처리 구문은 가능한 경우 기존 CI 구성 구문을 사용해야 합니다.
- 사용자가 적응하기가 더 쉬울 것입니다. 구현하는 데 필요한 작업이 줄어들 것입니다.
- 이벤트 구독 및 이벤트 발생은 성능이 우수하고 확장 가능하며 논블로킹이어야 합니다.
- 데이터베이스에서 읽는 것이 파일에서 읽는 것보다 일반적으로 더 빠릅니다.
- CI 이벤트는 많은 구독을 가질 수 있습니다. 이는 파이프라인을 만들기 위해 적절한 YAML 파일을 평가하는 것도 포함합니다.
- 주요 비즈니스 로직(예: 이슈 생성)은 주어진 CI 이벤트(예: 이슈 생성)에 대한 구독에 의해 영향받아서는 안됩니다.
- CI 이벤트 디자인은 유지보수 가능하고 확장 가능한 방식으로 구현되어야 합니다.
- 만약
issues/create
이벤트가 있다면 어떤 새 이벤트(merge_request/created
)라도 큰 노력 없이 추가할 수 있어야 합니다. - 많은 이벤트가 추가될 것으로 예상됩니다. 개발자가 도메인 이벤트(예: ‘이슈 닫힘’)를 GitLab-defined CI 이벤트로 등록하는 일은 미미해야 합니다.
- 또한 장기적으로 사용자 정의 CI 이벤트 지원 기회를 고려해야 합니다(예: ‘주문 발송’).
- 만약
옵션
현재 기술적인 5가지 제안이 있습니다;
-
제안 1:
.gitlab-ci.yml
파일 사용 기반으로; -
제안 2:
rules
키워드 사용 매우 비효율적인 방법입니다. -
제안 3:
.gitlab/ci/events
폴더 사용 각 이벤트에 대해 파일을 읽는 것을 포함합니다. - 제안 4: CI 구성 파일을 통한 이벤트 생성 이벤트를 정의하는 별도의 구성 파일입니다.
- 제안 5: 결합된 제안 위에 나열된 모든 제안의 결합입니다.