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. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality 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 파이프라인 위에 다양한 워크플로우를 모델링할 수 있는 프로그래밍 환경으로 변신시키고자 합니다. 현재 사용자들은 필요한 워크플로우를 구축하기 위해 웹훅이나 예약된 파이프라인 주변에 사용자 정의 자동화를 생성해야 합니다.

이 자동화를 사용자에게 더 쉽게 만들기 위해, 우리는 강력한 CI/CD 이벤트 시스템을 구축하여 GitLab 내외에서 일어나는 사건에 대응할 수 있도록 하고자 합니다.

전형적인 사용 사례는 다음과 같습니다: - 누군가 이슈를 생성할 때마다 CI/CD 작업을 실행하는 것 - 코멘트를 작성할 때마다 CI/CD 작업을 실행하는 것 - 병합 요청 상태를 “임시(draft)”에서 “검토 준비 완료(ready for review)”로 변경할 때마다 CI/CD 작업을 실행하는 것 - 그룹에 새 멤버를 추가할 때마다 CI/CD 작업을 실행하는 것

이러한 새로운 기술을 구축하기 위해, 우리는 다음을 해야 합니다: 1. 오늘보다 더 발전된 방식으로 GitLab 내에서 많은 계층적 이벤트를 발생시키기 2. GitLab 이벤트에 반응하는 자동화를 대규모로 실행할 수 있게 하는 것 3. 자동화 작성을 더 쉽게 만들기 위한 규약과 라이브러리 제공

목표

“GitLab Events Platform”이 GitLab 내에서 이벤트를 발생시키는 새로운 추상화를 구축하는 데 목적을 둘 때, “GitLab CI Events” 청사진의 목표는 다음과 같습니다: 1. 사용자가 이벤트를 구성했을 때 CI 파이프라인이 실행되는 방식을 정의하는 것 2. GitLab.com 규모와 그 이상에서 구독(subscription)을 이벤트에 매치(match)시키기 위해 필요한 기술 설명 3. 자동화 작업의 비용을 크게 줄일 수 있는 기술 설명

제안

결정 사항

요구 사항

수락된 제안은 다음 요구 사항과 특성을 고려해야 합니다:

  1. 이벤트 정의는 별도의 파일에서 이루어져야 합니다.
    • 모든 이벤트를 하나의 파일에 정의하는 경우, 파일이 지나치게 복잡해지고 사용자가 유지 관리하기 어려워집니다. 그러면 사용자들은 다시 include 키워드로 구성을 분리해야 하고 동일한 해결책이 만들어지게 됩니다.
    • 파이프라인의 구조, 사람들(designates), 잡들은 구독하는 이벤트와 구독의 목적에 따라 다를 것입니다.
  2. 단일 구독 구성 파일은 이벤트가 트리거될 때 만들어지는 단일 파이프라인을 정의해야 합니다.
    • 파이프라인 구성은 다른 파일을 include 키워드로 포함할 수 있습니다.
    • 파이프라인에는 많은 작업이 있을 수 있고, 하위 파이프라인이나 다중 프로젝트 파이프라인을 트리거할 수 있습니다.
  3. 이벤트와 처리 구문은 기존 CI 구성 구문을 사용해야 합니다.
    • 사용자가 적응하기 쉬워질 것입니다. 구현하는 데 필요한 작업이 적을 것입니다.
  4. 이벤트 구독과 이벤트 생성은 성능이 우수하고, 확장 가능하며 비차단적이어야 합니다.
    • 데이터베이스에서 읽는 것이 파일에서 읽는 것보다 일반적으로 더 빠릅니다.
    • CI 이벤트는 잠재적으로 많은 구독을 가질 수 있습니다. 이것은 파이프라인을 만들 YAML 파일을 평가하는 것을 포함합니다.
    • 주된 비즈니스 로직(예: 이슈 생성)은 특정 CI 이벤트(예: 이슈가 생성됨)에 대한 어떤 구독에도 영향을 받지 않아야 합니다.
  5. CI 이벤트 디자인은 유지 가능하고 확장 가능한 방식으로 구현되어야 합니다.
    • issues/create 이벤트가 있으면, 새로운 이벤트(merge_request/created)를 추가하는 것이 큰 노력이 들지 않을 것입니다.
    • 많은 이벤트가 추가될 것으로 기대됩니다. 개발자들이 도메인 이벤트(예: ‘이슈가 닫힘’)를 GitLab이 정의한 CI 이벤트로 등록하는 데는 위압적이지 않아야 합니다.
    • 또한 장기적으로 사용자 정의 CI 이벤트(e.g. ‘주문이 배송됨’)를 지원하는 기회를 고려해야 합니다.

옵션

현재 기술적으로 5가지 제안이 있습니다.

  1. 제안 1: .gitlab-ci.yml 파일 사용
  2. 제안 2: rules 키워드 사용
    • 매우 비효율적인 방법
  3. 제안 3: .gitlab/ci/events 폴더 사용
    • 매 이벤트마다 파일을 읽는 것을 포함함
  4. 제안 4: CI 구성 파일을 통해 이벤트 생성
    • 이벤트를 정의하기 위한 별도의 구성 파일
  5. 제안 5: 병합된 제안
    • 위에 나열된 모든 제안의 결합체