• 요약
• 도전 과제
  • GitLab CI 템플릿의 문제점
• 기회
• 용어집
• CI 구성 요소
  • 구성 요소의 정의
  • 예측 가능한 구성 요소
  • 구성 요소의 구조
    • FQDN
    • 구성 경로
    • 구성 요소 버전
    • ~latest 버전
  • 미래 자원 유형에 대한 참고 사항
• 입력 매개변수
  • CI 구성 보간 관점과 제한 사항
  • 왜 입력 매개변수가 환경 변수가 아닌가요?
  • 기존 include: 구문의 입력 매개변수
  • 파이프라인용 입력 매개변수
• 컴포넌트 저장소
  • 컴포넌트 저장소의 구조
• CI 카탈로그
  • 카탈로그 리소스
  • 카탈로그에 새로운 리소스 버전 릴리스하기
  • GitLab이 유지보수하는 카탈로그 리소스
• 구현 지침
• 반복
• 제한 사항
• 담당자

CI/CD 카탈로그

참고: 이 문서는 CI/CD 카탈로그 기능에 대한 미래 계획을 다룹니다. GitLab에서 이미 사용 가능한 기능에 대한 정보는 CI/CD 구성 요소 문서를 참고하세요.

요약

CI/CD 파이프라인 구성 요소 카탈로그의 목표는 파이프라인 구성을 재사용하는 것을 더 쉽고 효율적으로 만드는 것입니다. 파이프라인 구성을 발견하고 이해하며 재사용하는 방법을 제공함으로써 더 순조로운 경험을 제공합니다. 또한 CI/CD 파이프라인 구성 요소 카탈로그는 사용자들이 파이프라인 구성에 대해 협력하고 발전시키며 시간이 지남에 따라 개선될 수 있도록 하는 프레임워크를 제시합니다.

이 청사진은 CI/CD 카탈로그의 파이프라인 구성을 구축하는 데 대한 구조적 지침을 정의합니다. 이 청사진은 또한 솔루션의 장기적인 방향을 반복 및 개선하기 위한 것을 정의합니다.

도전 과제

• GitLab CI/CD는 새로운 사용자들에게 높은 학습 곡선을 가질 수 있습니다. 사용자들은 파이프라인을 구성하는 방법을 이해하기 위해 문서와 YAML 참조를 읽어야 합니다.
• 개발자들은 기존의 CI/CD 템플릿을 재사용하는 데 어려움을 겪고 결과적으로 루프를 다시 작성해야 할 수 있습니다 YAML 구성을 반복하여 작성해야 하는 결과를 얻을 수 있습니다.
• GitLab CI 템플릿은 특정 목적을 위한 파이프라인 또는 작업에 대한 거푸집을 제공합니다. 그러나 현재 버전 관리는 GitLab 인스턴스와 함께 제공되기 때문에 어렵습니다. 자세한 내용은 이 이슈를 참고하세요.
• GitLab CI/CD 사용자(파이프라인 작성자)들은 현재 자체적인 방법으로 조직 내에서 공유 파이프라인 구성을 구성합니다. 이러한 구성은 대부분 문서화되지 않습니다.
• 발견 가능한 구성은 GitLab CI 템플릿 뿐입니다. 그러나 내부 문서가 없으므로 실제 YAML을 복사하여 편집창에서 내용을 읽지 않고는 그들이 무엇을 하는지 및 사용하는 방법을 파악하는 것이 어려워집니다.
• 추가적인 GitLab 기능(CD, 보안, 테스트 등)을 도입하는 것이 어렵습니다.
• 재사용 가능한 CI 구성에 대한 테스트 프레임워크가 없습니다. 많은 구성은 개별 변경에 대해 단위 테스트 되지 않습니다.
• 커뮤니티, 협력사, 제3자, 개별 기여자는 GitLab 관리 템플릿에 기여하려면 GitLab 기여 프로세스를 진행해야 합니다. 자세한 내용은 이 이슈를 참고하세요.
• GitLab은 추가된 후 거의 유지되지 않는 템플릿을 포함해 100개 이상의 템플릿을 보유하고 있습니다.

GitLab CI 템플릿의 문제점

• GitLab CI 템플릿은 결정적인 동작을 고려하여 설계되지 않았습니다.
• GitLab CI 템플릿은 재사용을 고려하여 설계되지 않았습니다.
• Jobs/ 템플릿은 stage: 속성을 하드 코딩하지만 사용자는 템플릿의 사용자가 필요한 stage를 어떻게든 재정의하거나 미리 알아야 합니다.
  • 사용자는 주어진 단계 내에서 작업을 가져오거나 컴포넌트를 사용할 때 입력 매개변수로 단계 이름을 전달해야 합니다.
  • 올바른 단계를 매핑하는 데 실패하면 혼란스러운 오류가 발생할 수 있습니다.
• 일부 템플릿은 AutoDevOps와 함께 작동하도록 설계되었지만 충분히 범용적이지 않습니다 (예시).
• 많은 CI 템플릿은 튜토리얼/거푸집 스타일의 템플릿입니다(언어별).
  • 이들은 사용자에게 일반적인 파이프라인이 어떻게 보일지 보여주도록 만들어졌지만 사용자 관점에서 높은 사용자 지정이 필요합니다.
  • 이러한 경우 사용자 경험(UX)이 다릅니다: 파이프라인 편집기 커서 위치로 복사하여 붙여넣기가 필요합니다.
• SAST.latest.gitlab-ci.yml과 같은 일부 템플릿은 조건부로 여러 작업을 동일한 파이프라인에 추가합니다.
  • 이러한 작업들은 이상적으로 자식 파이프라인으로 실행되어 부모 파이프라인에서 보고서를 이용할 수 있어야 합니다.
  • 부모-자식 파이프라인이 사용되기 위해서 이 에픽이 필요합니다.
• 일부 템플릿은 variables, image 및 기타 상위 키워드를 잘못 사용하지만, 이는 템플릿에서 정의된 작업뿐만 아니라 모든 파이프라인 작업에서 이를 정의합니다.
  • 이러한 기술은 템플릿이 필요하지 않은 작업을 수정할 때 상속 문제를 도입합니다.

기회

• 사용자가 필요한 것을 검색하여 찾을 수 있는 파이프라인 구성 카탈로그를 보유하게 되면 새로운 사용자들에게 진입 장벽이 크게 낮아질 수 있습니다.
• 고객들은 이미 자체적인 공유 구성의 카탈로그를 전개하려고 노력하고 있습니다. 제품에서 파이프라인 구성을 직접 작성, 패키지화 및 공유하는 표준화된 방법을 제공할 수 있습니다.
• 새로운 파이프라인 구성(예: 재사용 가능한 작업 단계)을 구현하면 카탈로그의 항목이 될 수 있습니다. 카탈로그는 새로운 구성의 채택을 촉진할 수 있습니다.
• 카탈로그는 우리의 파트너와의 관계를 강화하는 장소가 될 수 있으며, 파트너가 제공하고 유지하는 구성요소가 될 수 있습니다.
• 발견 가능성 및 더 나은 버전 관리 메커니즘을 통해 더 많은 개선과 더 나은 협력이 가능해질 수 있습니다.
• 경쟁 환경에서 이러한 기능의 필요성이 나타나고 있습니다.
  • R2DevOps는 GitLab 파이프라인의 CI 템플릿 카탈로그를 구현합니다.
  • GitHub Actions은 재사용 가능한 작업 단계의 광범위한 카탈로그를 제공합니다.
  • CircleCI Orbs는 재사용 가능한 YAML 구성 패키지를 제공합니다.

용어집

이 섹션은 이 문서 전반에서 사용되는 일부 용어를 정의합니다. 이 용어들로 우리는 새로운 통찰을 발견하여 디자인을 정립하는 과정에서 변경될 수 있는 추상적인 개념을 식별하는 데 그칩니다.

• Component(구성 요소)는 파이프라인 구성의 재사용 가능한 단위의 일반 용어입니다. 구성 요소는 템플릿(include 구문을 통해 사용 가능) 또는 단계가 될 수 있습니다.
• Component project(구성 요소 프로젝트)는 하나 이상의 구성 요소를 포함하는 GitLab 프로젝트입니다. 구성 요소 프로젝트는 카탈로그에 나열될 수 있으므로 코드베이스에서는 이를 카탈로그 리소스로도 지칭합니다.
• Catalog(카탈로그)는 구성 요소 프로젝트의 모음입니다.
• Version(버전)은 카탈로그에 발행된 구성 요소 프로젝트 릴리스입니다.
• Publishing(발행)은 구성 요소 프로젝트 릴리스를 카탈로그에 나열하는 행위입니다.
• Step(단계)은 작업 실행을 위한 지시사항 모음을 포함하는 구성 요소입니다.
• Template(템플릿)은 프로젝트의 파이프라인 구성에 포함할 수 있는 CI/CD 구성 조각을 포함하는 구성 요소입니다.

CI 구성 요소

구성 요소의 정의

파이프라인 구성 요소는 단일 파이프라인 구성 단위를 추상화하는 재사용 가능한 목적 단위입니다. 구성 요소는 파트 또는 전체 파이프라인 구성을 구성하는 데 사용됩니다. 구성 요소는 입력 매개변수를 선택적으로 사용하여 다양한 파이프라인 컨텍스트에서 적응 가능하고 재사용 가능하며 구현 세부 정보를 캡슐화하고 격리합니다.

구성 요소를 사용하면 파이프라인을 세부 사항이 하나의 장소에 정의되는 대신 추상화를 사용하여 조립할 수 있습니다. 구성 요소를 파이프라인에서 사용할 때 사용자는 구성 요소의 구현 세부 정보를 알 필요가 없으며 제공된 인터페이스에만 의존해야 합니다.

파이프라인 구성 요소는 해당 구성 요소가 사용될 수 있는 파이프라인 구성 컨텍스트를 나타내는 유형을 정의합니다. 예를 들어, 유형 X의 구성 요소는 유형 X 사용 사례에 따라만 사용할 수 있습니다.

구성 요소로 이루어진 시스템의 최상의 경험을 위해서는 구성 요소가 다음과 같아야합니다:

• 단일 목적: 구성 요소는 단일 목표에 집중해야 하며 범위는 가능한 한 작아야 합니다.
• 격리: 구성 요소가 파이프라인에서 사용될 때, 해당 구현 세부 정보가 구성 요소 자체 외부로 누출되어서는 안 됩니다.
• 재사용 가능: 구성 요소는 다른 파이프라인에서 사용할 수 있도록 설계됩니다. 구성 요소는 구축된 가정에 따라 보다 일반적이거나 특정할 수 있습니다. 일반적인 구성 요소는 보다 재사용 가능하지만 더 많은 사용자 정의가 필요할 수 있습니다.
• 버전 관리: 구성 요소를 사용할 때 우리는 관심 있는 버전을 명시해야 합니다. 버전은 구성 요소의 정확한 인터페이스와 동작을 식별합니다.
• 해결 가능: 구성 요소가 다른 구성 요소에 종속되는 경우 이 종속성은 명시적이어야 하며 추적 가능해야 합니다.

예측 가능한 구성 요소

결국, 우리는 CI 카탈로그 구성 요소를 예측할 수 있기를 원합니다. 고정된 @ 버전을 사용하여 경로별로 구성 요소를 포함하면, 포함된 상황과 관계없이 항상 같은 구성을 반환해야 합니다. 결과적인 구성은 특정한 구성 버전과 include:inputs 키워드를 통해 전달된 입력 집합에 대해 항상 동일해야 하므로 결정론적이어야 합니다.

구성 요소를 포함함으로써 부작용을 발생해서는 안 되며 참조 투명성을 가져야 합니다.

구성 요소를 예측 가능하게 만드는 것은 과정이며, 지금 바로 사용자와 고객에게 중단적일 수 있는 디자인을 이해하기 위해 MVP에 대해 반복하고 필요한 디자인을 더 잘 이해하기 위해 우리는 이를 초기에 달성할 수 없을 수 있습니다.

구성 요소를 더 예측 가능하게 만들기 위해 일부 최상위 키워드(예: include: remote:)를 제한하는 것을 고려했지만, 우리는 먼저 구성 요소를 더 예측 가능하게 하기 위해 반복해야 한다는 것에 동의했습니다. 예측 가능성, 결정론성, 참조 투명성, CI 구성 요소를 더 예측 가능하게 만드는 것은 여전히 중요하지만 초기 반복에서는 이를 달성할 수 없을 수 있습니다.

구성 요소의 구조

파이프라인 구성 요소는 <FQDN>/<구성-요소-경로@버전> 형식의 고유 주소로 식별됩니다.

• FQDN(Fully Qualified Domain Name).
• 해당 구성을 정의하는 리포지토리 또는 디렉터리의 경로.
• 특정 버전

예를 들면: gitlab.com/gitlab-org/dast@1.0.

FQDN

초기에는 FQDN이 GitLab 호스트와 일치하는 구성 주소만 지원합니다.

구성 경로

구성 경로에 의해 식별되는 디렉터리는 적어도 구성 YAML을 포함하고 있어야 하며 선택적으로 관련 README.md 설명 파일을 포함할 수 있습니다.

구성 경로는 다음과 같을 수 있습니다:

• 프로젝트 경로: gitlab.com/gitlab-org/dast. 기본 구성이 처리됩니다.
• 명시적 구성 경로: gitlab.com/gitlab-org/dast/api-scan. 이 경우에는 명시적으로 api-scan 구성이 처리됩니다.
• 지역 디렉터리에 대한 상대경로: ./path/to/component. 이 경로에는 구성을 정의하는 구성 YAML이 포함되어야 합니다. 현재 파일의 경로에 상대적인 경로를 나타내기 위해 경로는 ./ 또는 ../로 시작해야 합니다.

상대적인 지역 경로는 전체 구성 주소의 약어 형식으로, gitlab-org/dast 프로젝트의 mydir/file.yml 파일에서 호출된 경우 다음과 같이 확장됩니다:

gitlab.com/gitlab-org/dast/mydir/path/to/component@<현재_SHA>

구성 요소 YAML 파일은 구성 유형이 다음 중 하나인 파일명 규칙을 따라야 합니다:

구성 요소가 사용되는 컨텍스트에 따라 올바른 YAML 파일을 가져옵니다. 예를 들어:

• 구성 gitlab.com/gitlab-org/dast@1.0을 포함하는 경우, gitlab-org/dast 리포지토리의 루트 디렉터리에 있는 template.yml 파일이 예상됩니다.
• 구성 gitlab.com/gitlab-org/dast/api-scan@1.0을 포함하는 경우, gitlab-org/dast 리포지토리의 api-scan 디렉터리 내에 있는 template.yml 파일이 예상됩니다.

구성 YAML 파일은 다음 규칙을 준수해야합니다:

• 참조할 수 있는 이름을 가져야 합니다.
• 파일명에 유형을 지정해야 하며, 이는 사용 방법을 정의합니다(포함할 수 있는 원시 구성, 자식 파이프라인 워크플로, 작업 단계).
• 유형에 따라 콘텐츠를 정의해야 합니다.
• 동적인 값에 대해 입력 매개변수를 지정해야 합니다. 구성은 동적 값과 환경 변수 대신 입력 매개변수에 의존해야 합니다.
• 정적으로 검증되어야 합니다(예: JSON 스키마 검증기 사용).

spec:
  inputs:
    website:
    environment:
      default: test
    test_run:
      options:
        - unit
        - integration
        - system
---
# 구성 요소의 내용

구성 요소 버전

구성 요소의 버전은 다음과 같은 우선 순위로 될 수 있습니다.

1. 커밋 SHA - 예시: gitlab.com/gitlab-org/dast@e3262fdd0914fa823210cdb79a8c421e2cef79d8
2. 태그 - 예시: gitlab.com/gitlab-org/dast@1.0
3. 가장 최근에 발행된 릴리스를 가리키는 특별한 이동 대상 버전 - 예시: gitlab.com/gitlab-org/dast@~latest
4. 브랜치 이름 - 예시: gitlab.com/gitlab-org/dast@master

태그와 동일한 이름의 브랜치가 존재하는 경우, 태그가 브랜치보다 우선합니다. 마찬가지로, 특정 태그의 이름이 e3262fdd0914fa823210cdb79a8c421e2cef79d8인 경우 커밋 SHA가 우선합니다(존재하는 경우).

릴리스되지 않은 모든 수정 사항을 참조할 수 있어야 하므로, 구성 요소는 Git 리포지토리에 정의되어야 합니다.

로컬 경로로 구성 요소를 참조할 때(예: ./path/to/component), 해당 구성 요소의 버전은 암시적이며 현재 파이프라인 컨텍스트의 커밋 SHA와 일치합니다.

~latest 버전

~latest 버전 한정자의 사용은 카탈로그에 발행된 릴리스에만 제한됩니다.

우리는 ~latest가 카탈로그 자원으로 표시되지 않은 프로젝트에서 지원되어야 하는지에 대해 논의했습니다.

이 결정에 대한 다양한 이유가 있습니다.

1. 버전은 카탈로그에서 목록에서 제외될 수 있으며, ~latest는 이를 반영해야 합니다.
2. 카탈로그는 개인 자원을 지원할 것입니다. 현재 구성 요소 프로젝트가 릴리스를 가질 필요가 없지만 카탈로그에는 발행되지 않은 자원에 대한 유효한 요구 사항이 없습니다.
3. 미래에는 릴리스하는 것과 릴리스를 카탈로그에 발행하는 것을 분리하여, 사용자가 발행되는 릴리스를 선택할 수 있도록 합니다.
4. 카탈로그에 릴리스를 발행할 때 의미 있는 버전 관리를 강제할 수 있으며, 표준을 따르지 않는다면 거부합니다. 릴리스 모델에서 의미 있는 버전 관리를 강제할 수 없기 때문에 이것은 역 호환성을 갖지 않습니다.
5. 최신 버전은 카탈로그 자원 데이터 구조에 대한 비정규화될 가능성이 높으며, 카탈로그 자원을 표시하거나 구성 요소 버전을 가져올 때 더 뛰어난 성능을 위한 쿼리에 유리할 것입니다.

위의 모든 사항에서, 카탈로그 자원 및 발행되지 않은 구성 요소 프로젝트에 대해 ~latest를 모두 지원하는 경우 불일치와 예상치 못한 동작을 유발할 수 있습니다. 카탈로그에서 발행된 버전만 지원하도록 시작하여 나중에 사용자 요구에 따라 발행되지 않은 구성 요소 프로젝트를 지원하는 범위를 확대할 수 있는 자유를 가지게 됩니다.

미래 자원 유형에 대한 참고 사항

카탈로그에서 여러 유형의 자원을 지원하기 위해 미래에는 프로젝트의 루트 디렉토리에 catalog-resource.yml 파일을 정의해야 할 것입니다:

name: DAST
description: 취약점을 찾기 위해 웹 엔드포인트를 검사합니다.
category: 보안
tags: [동적 분석, 보안 스캐너]
type: 구성요소_저장소

이 파일은 리소스 내용에 대한 메타데이터를 색인화하는 데 사용될 수 있습니다. 예를 들어, 사용자는 리포지토리의 구성 요소를 나열하고 검색 목적을 위해 추가 데이터를 색인화할 수 있습니다.

name: DAST
description: 취약점을 찾기 위해 웹 엔드포인트를 검사합니다.
category: 보안
tags: [동적 분석, 보안 스캐너]
type: 구성요소_저장소
metadata:
  components:
    - all-scans
    - scan-x
    - scan-y

입력 매개변수

구성 요소에 입력 매개변수가 있는 경우, 다음 스키마에 따라 지정되어야 합니다:

spec:
  inputs:
    website: # 기본적으로 모든 선언된 입력은 필수입니다.
    environment:
      default: test # 제공되지 않은 경우 기본값을 적용합니다. 이는 입력을 선택 사항으로 만듭니다.
    flags:
      default: null # 기본값으로 전혀 값이 없는 입력을 완전히 선택 사항으로 만듭니다.
    test_run:
      options: # 기본값이 없으므로 목록에서 선택해야 합니다.
        - unit
        - integration
        - system

이 경우 YAML은 2개의 문서를 포함합니다. 첫 번째 문서는 사양을 나타내고 두 번째 문서는 내용을 나타냅니다.

구성 요소를 사용할 때 입력 매개변수는 다음과 같이 전달됩니다:

include:
  - component: gitlab.com/org/my-component@1.0
    inputs:
      website: ${MY_WEBSITE} # 변수 확장
      test_run: system
      environment: $[[ inputs.environment ]] # 상위 입력의 보간 처리

변수 확장은 include:inputs 구문 및 상위 제공된 입력의 보간을 지원해야 합니다.

입력 매개변수는 가능한 한 빨리 유효성이 검사되어야 합니다:

1. org/my-component 프로젝트 내부의 gitlab-template.yml 파일을 읽습니다.
2. 사양에서 spec:inputs를 구문 분석하고 이 스키마에 대해 매개변수를 유효성을 검사합니다.
3. 성공적으로 유효성을 검사하면 내용을 구문 분석하여 계속 진행합니다. 그렇지 않은 경우 오류를 반환합니다.
4. 구성 요소의 내용에서 입력 매개변수를 보간합니다.

spec:
  inputs:
    environment:
      options: [test, staging, production]
---
"run-tests-$[[ inputs.environment ]]":
  script: ./run-test

scan-website:
  script: ./scan-website $[[ inputs.environment ]]
  rules:
    - if: $[[ inputs.environment ]] == 'staging'
    - if: $[[ inputs.environment ]] == 'production'

$[[ inputs.XXX ]]를 사용하여 입력은 내용 구문 분석 직후에 즉시 보간됩니다.

CI 구성 보간 관점과 제한 사항

spec:inputs를 사용하면 사용자는 CI 구성을 위한 입력 인수를 정의할 수 있게 됩니다. include:inputs를 사용하면 이러한 인수를 CI 구성 요소로 전달할 수 있습니다.

$[[ inputs.something ]]의 inputs는 보간 블록에서 자신의 인수에 액세스할 수 있도록 제공할 “객체” 또는 “컨테이너”가 될 것입니다. 그러나 이는 예를 들어 다음과 같이 다양한 방향으로 발전할 수 있습니다.

1. 사용자가 환경 변수에 더 쉽게 액세스할 수 있도록 variables 또는 env 객체를 제공할 수 있습니다.
2. 블록 평가를 확장하여 다른 곳에서 전달된 JSON 또는 YAML 객체를 더 쉽게 탐색할 수 있습니다.
3. 또한 리포지토리 파일, 스니펫 또는 관련 문제에 대한 액세스를 제공할 수 있습니다.

CI 구성 보간은 상대적으로 계산 집약적인 기술이며 특히 우리는 이 메커니즘이 GitLab.com에서 자주 사용될 것이라 예상하기 때문에 그렇습니다. 이 기술을 책임있게 사용하도록 사용자들이 보장하기 위해 우리는 운영 체계를 안전하게 유지하기 위해 다양한 제한을 도입했습니다. 그러나 이러한 제한은 응용 프로그램 수준에서 사용 가능한 제한 사항 (지원되는 최대 YAML 크기, YAML 파일 구문 분석 시간 초과 등)이 이미 있으므로 사용자에게 영향을 미쳐서는 안 됩니다. 도입된 보간 제한 가운데 일부는 다음과 같습니다.

1. 보간 블록은 1킬로바이트보다 크면 안 됩니다.
2. 보간이 있는 YAML 값은 1메가바이트보다 크면 안 됩니다.
3. YAML 구성에 포함된 항목은 50만 개를 초과할 수 없습니다.

왜 입력 매개변수가 환경 변수가 아닌가요?

오늘날까지 우리는 정보를 전달하기 위해 환경 변수를 활용해 왔습니다. 예를 들어, 우리는 상류 파이프라인에서 하류 파이프라인으로 정보를 전달하기 위해 환경 변수를 사용합니다.

환경 변수를 사용하여 구성 요소로 정보를 전달하는 것은 프로그래밍 언어에서 전역 변수를 선언하는 것과 같습니다. 우리가 선언하는 변수가 많아질수록 변수 충돌의 위험이 높아지고 변수 범위가 커집니다.

입력 매개변수는 구성 요소로 전달되는 변수처럼 특정 범위 내에 존재하며 외부로 누출되지 않습니다. 입력은 상류 include에서 상속되지 않습니다. 명시적으로 전달되어야 합니다.

이 패러다임은 더 견고하고 격리된 구성 요소를 구축하고 계약을 선언하고 강제하는 데 도움이 됩니다.

기존 include: 구문의 입력 매개변수

include:component를 통해 구성요소에 입력 매개변수를 추가하는 것을 고려할 수 있기 때문에 다른 include: 유형에서도 inputs: 구문을 통해 입력을 지원 확장할 수 있는 기회가 있습니다.

include:
  - component: gitlab.com/org/my-component@1.0
    inputs:
      foo: bar
  - local: path/to/file.yml
    inputs:
      foo: bar
  - project: org/another
    file: .gitlab-ci.yml
    inputs:
      foo: bar
  - remote: http://example.com/ci/config
    inputs:
      foo: bar
  - template: Auto-DevOps.gitlab-ci.yml
    inputs:
      foo: bar

그런 다음 포함되는 구성은 YAML에서 명세 부분을 정의하여 입력을 지정해야 합니다.

spec:
  inputs:
    foo:
---
# 구성의 나머지 부분

YAML이 include:inputs를 사용하여 내용을 포함하지만 포함하는 YAML이 명세에 spec:inputs을 정의하지 않으면 오류가 발생해야 합니다.

파이프라인용 입력 매개변수

입력은 트리거될 때 파이프라인에 매개변수를 전달하는 데 사용될 수도 있으며 즉시 유효성을 검사할 수 있습니다.

오늘날 우리는 매개변수를 명시적으로 사용하는 다양한 사용 사례가 있습니다.

1. Run Pipeline UI 양식.
   • 오늘 문제점: 우리는 UI에 환경 변수를 노출시키기 위해 variables:*:description로 최상위 변수를 사용하고 있습니다. 이 방법의 문제점은 책임의 혼합과 선행 순위에서 변수가 얻는 점프입니다 (YAML 변수에서 파이프라인 변수로). 이 솔루션에 검증 및 기능을 추가하는 것은 도전적이고 복잡합니다.
2. API를 통해 파이프라인 트리거. 예를 들어POST /projects/:id/pipelines/trigger로 { inputs: { provider: 'aws' } }
3. trigger: 구문을 사용하여 파이프라인 트리거.

deploy-app:
  trigger:
    project: org/deployer
    inputs:
      provider: aws
      deploy_environment: staging

Run Pipeline UI 양식의 문제를 해결하기 위해 우리는 완전히 inputs 명세를 최대한 활용할 수 있습니다.

spec:
  inputs:
    concurrency:
      default: 10    # 입력 상자에 기본 값으로 표시됨
    provider: # 양식 유효성에서 `required`를 강제할 수 있음
      description: 배포 공급자 # 선택 사항: 입력 레이블로 렌더링.
    deploy_environment:
      options: # 아래에 정의된 옵션의 순서대로 선택 상자 렌더링
        - staging    # 1번 옵션
        - canary     # 2번 옵션
        - production # 3번 옵션
      default: staging # UI에서 기본 선택됨.
                      # `default:`가 명시되지 않은 경우 사용자는 명시적으로 옵션을 선택해야 함
      description: 배포 환경 # 선택 사항: 입력 레이블로 렌더링.
---
# 파이프라인 구성의 나머지 부분

컴포넌트 저장소

컴포넌트 저장소는 하나 이상의 파이프라인 컴포넌트를 전용으로 호스팅하는 GitLab 프로젝트/저장소입니다.

컴포넌트 저장소는 카탈로그 리소스가 될 수 있습니다. 컴포넌트 저장소에 적절한 아바타와 프로젝트 설명을 설정하여 카탈로그에서의 검색 가능성을 향상시키는 것이 매우 권장됩니다.

카탈로그에 출시된 컴포넌트 저장소는 저장소의 루트 디렉터리에 README.md 파일이 있어야 합니다. README.md은 컴포넌트 저장소의 문서화를 나타내므로 카탈로그에 나열되지 않을 때라도 권장됩니다.

컴포넌트 저장소의 구조

컴포넌트 저장소는 하나 이상의 컴포넌트를 호스팅할 수 있습니다. 작성자는 단일 컴포넌트를 하나의 저장소에 정의할지 또는 여러 개의 일관된 컴포넌트를 동일한 저장소에 포함할지 결정할 수 있습니다.

컴포넌트 저장소는 프로젝트 전체 경로에 의해 식별됩니다.

예를 들어, Rails 앱의 RSpec 테스트를 실행하는 컴포넌트를 개발하고 있다고 상상해 봅시다. myorg/rails-rspec라는 프로젝트를 생성합니다.

다음 디렉터리 구조는 저장소당 1개의 컴포넌트를 지원합니다:

.
├── template.yml
├── README.md
└── .gitlab-ci.yml

프로젝트에서 변경 사항이 적절히 확인되도록 하기 위해 .gitlab-ci.yml을 권장합니다.

이제 해당 컴포넌트는 gitlab.com/myorg/rails-rspec 경로로 식별됩니다. 이 경로는 또한 프로젝트 경로에 매핑됩니다. 루트 디렉터리에 template.yml 파일과 README.md를 기대합니다.

다음 디렉터리 구조는 저장소당 여러 개의 컴포넌트를 지원합니다:

.
├── .gitlab-ci.yml
├── README.md
├── unit/
│   └── template.yml
├── integration/
│   └── template.yml
└── feature/
    └── template.yml

이 예에서는 RSpec로 실행되는 여러 테스트 프로필을 정의하고 있습니다. 사용자는 이 중 하나 이상을 선택하여 사용할 수 있습니다.

각각의 컴포넌트는 gitlab.com/myorg/rails-rspec/unit, gitlab.com/myorg/rails-rspec/integration, 그리고 gitlab.com/myorg/rails-rspec/feature 경로에 의해 식별됩니다.

이 디렉터리 구조는 두 가지 전략을 지원할 수도 있습니다:

.
├── template.yml       # myorg/rails-rspec
├── README.md
├── LICENSE
├── .gitlab-ci.yml
├── unit/
│   └── template.yml   # myorg/rails-rspec/unit
├── integration/
│   └── template.yml   # myorg/rails-rspec/integration
└── feature/
    └── template.yml   # myorg/rails-rspec/feature

위의 구조를 사용하면 최상위 컴포넌트를 만들어 기본 컴포넌트로 사용할 수 있습니다. 예를 들어, myorg/rails-rspec은 모든 테스트 프로필을 함께 실행할 수 있습니다. 그러나 더 구체적인 테스트 프로필은 별도로 사용할 수도 있습니다(예: myorg/rails-rspec/integration).

참고: 컴포넌트의 중첩은 허용되지 않습니다. 이 제한은 프로젝트 수준에서의 일관성을 촉진하고 복잡성을 낮춥니다.

CI 카탈로그

CI 카탈로그는 사용자가 CI/CD에서 활용할 수 있는 리소스의 색인입니다. 초기에는 사용자가 검색하고 파이프라인에서 사용할 수 있는 컴포넌트 저장소 목록을 포함합니다. 사용자는 권한과 프로젝트 가시성 수준에 따라 리소스만 볼 수 있습니다. 인증되지 않은 사용자는 공개 리소스만 볼 수 있습니다.

프로젝트 관리자는 프로젝트를 비공개 또는 공개로 설정하는 책임이 있습니다. CI 카탈로그는 프로젝트가 커뮤니티 카탈로그에 나타나지 않도록 하는 등의 보안 기능을 제공해서는 안 됩니다. 프로젝트가 공개되어 있으면 누구에게나 보이게 됩니다.

카탈로그 페이지는 사용자 검색을 세분화하기 위해 다양한 필터를 제공할 수 있습니다. 사용자가 소속된 그룹의 리소스와 같은 사전 정의된 필터를 포함합니다.

미래에는 카탈로그에 다른 유형의 리소스(예: 통합, 프로젝트 템플릿, 컨테이너 이미지 등)도 포함될 수 있습니다.

카탈로그에 컴포넌트 저장소를 나열하려면 프로젝트를 카탈로그 리소스로 표시해야 합니다. 초기에는 프로젝트 설정으로 그렇게 합니다.

프로젝트를 “카탈로그 리소스”로 표시하면 최종적으로 카탈로그에 표시될 수 있습니다.

설정이 활성화되면 데이터베이스 레코드를 생성하고 활성화가 해제되면 레코드의 상태를 수정할 수 있습니다.

카탈로그 리소스

게시된 후, 카탈로그 리소스는 최소한 다음 속성을 갖추어야 합니다:

• path: 고유하게 식별되어야 합니다.
• name: 컴포넌트 저장소의 경우 프로젝트 이름일 수 있습니다.
• documentation: README.md 파일을 사용할 것이며, 이는 필수적입니다.
• versions: 리소스의 하나 이상의 릴리스.

카탈로그 리소스의 다른 속성:

• description: 컴포넌트 저장소의 경우 프로젝트 설명일 수 있습니다.
• 아바타 이미지: 프로젝트 아바타를 사용할 수 있습니다.
• 인기 지표(별, 포크).
• 분류: 사용자는 카테고리를 선택하거나 검색 태그를 정의해야 합니다.

최초에는 리소스에 릴리스 태그가 없을 수 있습니다. 사용자는 브랜치 이름이나 커밋 SHA를 지정하여 리소스 저장소를 사용할 수 있을 것입니다. 그러나 이러한 유형의 버전 한정자는 다양한 이유로 카탈로그 리소스 페이지에 나열되지 않아야 합니다:

• 브랜치와 태그 목록이 매우 커질 수 있습니다.
• 브랜치와 태그가 최종 사용자에게 의미가 없을 수 있습니다.
• 브랜치와 태그가 버전 관리를 충분히 전달하지 못할 수 있습니다.

카탈로그 리소스를 카탈로그에 나열하려면 먼저 프로젝트를 위해 릴리스를 생성해야 합니다.

카탈로그에 새로운 리소스 버전 릴리스하기

리소스에 대해 발행될 버전은 프로젝트 릴리스에 있어야 합니다. 프로젝트 릴리스를 생성하는 것은 리소스를 버전 관리하는 공식적인 행위입니다.

리소스 페이지는 다음과 같은 내용을 포함해야 합니다:

• 최신 릴리스가 명시되어 있는 것(예: 기본 버전).
• 리소스의 이전 릴리스를 검토하고 활용할 수 있는 기능.
• README.md에 의해 나타낸 문서.

사용자들은 CI 파이프라인 작업에서 소프트웨어가 지속적으로 제공되는 원칙을 따르는 방식으로 리소스의 새로운 버전을 릴리스할 수 있어야 합니다.

구성 요소 리포지토리와 이를 포함하는 구성 요소들이 품질 기준을 충족하는지 확인하기 위해 사용자들은 새로운 버전을 릴리스하기 전에 이를 테스트할 수 있어야 합니다.

새로운 리소스 버전 릴리스 중 실행할 수 있는 몇 가지 체크의 예시:

• 프로젝트가 루트 디렉토리에 README.md를 포함하는지 확인합니다.
• 프로젝트 설명이 존재하는지 확인합니다.
• 구성 요소 리포지토리에 사용 가능한 구성 요소의 인덱스가 있는 경우 각 구성 요소가 유효한 YAML을 가지고 있는지 확인합니다.

프로젝트에 대한 새로운 릴리스가 생성되면 리소스의 메타데이터를 색인화합니다. 우리는 CI 카탈로그의 메인 페이지를 설계하는 데 더 많은 유연성을 갖기 위해 처음에는 가능한 많은 메타데이터를 색인화하고 싶습니다. 우리는 CI 카탈로그에서 리소스를 올바르게 시각화하기 위해 데이터 부족으로 제약받기 원치 않습니다. 이를 위해 릴리스되는 모든 리소스를 찾아야 하고 그들의 데이터와 메타데이터를 색인화해야 할 수 있습니다. 예시: CI 구성 요소의 spec: 섹션의 내용을 색인화합니다.

구성 요소 리포지토리의 개발 워크플로우에 대한 예시를 확인하세요.

GitLab이 유지보수하는 카탈로그 리소스

GitLab은 모든 SaaS 프로젝트가 사용할 수 있는 카탈로그 리소스를 제공합니다. 이러한 프로젝트는 components 최상위 그룹 내에 위치할 것입니다. 추가로, 우리는 해당 프로젝트를 검증된 생성자로 표시하여 신뢰도를 높일 것입니다.

components 그룹은 개발 공간뿐만 아니라 GitLab 제품의 기능입니다. GitLab 어디에서든 이 그룹 내에 위치한 구성 요소를 참조할 수 있습니다.

components 하위에 있는 각 프로젝트는 관련 제품 범주를 보유하는 팀에 의해 명시적으로 소유되어야 합니다. 예: SAST와 관련된 구성 요소는 SAST 제품을 관리하는 팀에 의해 소유됩니다.

다른 주요 대안은 다음과 같습니다:

• gitlab-org/gitlab-components 하위 그룹.
  • 소유자를 명확히하는 장점이 있습니다 (GitLab 조직).
  • verbose 경로와 구성 요소가 제품의 일부이며 짧은 경로를 가치 있게 여겼습니다. 또한 SaaS의 구성 요소가 가용성이 보장되어야 하며 gitlab-org 출처 그룹이 있으면 혼란스러울 뿐만 아니라 명명 충돌에 민감해질 수 있습니다.
• 새로운 최상위 그룹 gitlab-components.
  • 덜 verbose한 경로를 가지는 장점이 있었지만 gitlab- 접두어는 중복되었습니다.
  • 기존의 GitLab 그룹에 이미 적용된 보안 및 규정 표준을 복제할 필요가 있습니다. 그러나 최종적으로 components 그룹은 GitLab 기능의 일부이며 gitlab-org와 별도의 개발 환경을 가질 자격이 있다는 것의 상충으로 끝났습니다.
• 커뮤니티 기여자가 사용하는 gitlab-community/cicd-components.
  • AppSec가 이미 이 그룹에 대한 보안 및 규정을 제어하고 있는 장점이 있습니다.
  • 단점은 gitlab-community이 주로 gitlab-org에서 fork된 것을 포함하고 있다는 것입니다. 이는 혼란스러울 수 있습니다.

구현 지침

• 최소 사용자 베이스부터 시작하십시오. gitlab-org 및 gitlab-com 그룹을 위한 기능을 dogfood화하십시오. 공학 생산성과 다른 그룹들이 파이프라인 구성을 작성하는 데 참여할 수 있게 합니다.
• 수집된 모든 피드백을 통합할 수 있도록 보장하십시오. 초기 채택자들과 함께 실행 기대치를 가지고 있어야 합니다.
• 초기 반복에서 기존 기능을 최대한 활용하세요. 초기 반복에서 바퀴를 재발명하지 마십시오. 예: 제목, 설명, 아바타 등을 빌드하기 위해 프로젝트 기능 재사용.
• 구성요소의 개발 라이프사이클을 위해 GitLab 기능을 활용하세요(testing via .gitlab-ci.yml, 릴리스 관리, 파이프라인 편집기 등).
• 자기 관리 지원을 고려하여 카탈로그 및 워크플로우를 설계하세요.
• 향후 유형의 파이프라인 구성 요소 및 사용 방법을 지원할 수 있도록 카탈로그 및 워크플로우를 설계하세요.
• 결정론적 패키지 관리자를 구축하는 관련 산업에서의 최고의 실천 방법을 따르는 컴포넌트 및 카탈로그를 디자인하세요.

반복

첫 반복 계획은 다음과 같습니다:

1. 실험 단계
   • namespace 액터와 함께 기능 플래그 뒤의 MVC 빌드.
   • 초기 채택을 시작하기 위해 기능 플래그를 gitlab-com 및 gitlab-org 네임스페이스에만 활성화.
   • 피드백을 기반으로 솔루션과 UX를 정제.
   • 이 기능의 초기 채용자를 찾아 그들의 피드백에 대해 반복합니다.
2. 새로운 파이프라인 구성 설계 (다른 단계와 병행)
   • 새로운 파이프라인 구성 (단계, 워크플로우, 템플릿)에 대한 제안을 작업하기 위한 기술 및 설계 프로세스를 시작.
   • 새로운 구성을 구현하세요. 카탈로그는 이에 호환되어야 합니다.
   • 새로운 구성을 dogfood화하고 피드백에 따라 반복합니다.
   • 비공개 카탈로그에서 새로운 구성을 릴리스합니다.
3. Ultimate 플랜 그룹을 위한 비공개 카탈로그 릴리스
   • 피드백에 대해 반복합니다.
4. 모든 GitLab 사용자를 위한 공개 카탈로그 릴리스 (prospect 기능)
   • 새로운 버전의 GitLab CI 템플릿을 구성 요소로서 릴리스합니다. 가능한 경우 새로운 구성을 사용합니다.
   • 자체 관리형 관리자가 GitLab.com이나 저장소 익스포트로부터 구성 요소를 가져와 자체 관리형 카탈로그를 채울 수 있도록 허용합니다.
   • 피드백에 대해 반복합니다.

2023년 10월에 네임스페이스 뷰로 릴리스한 후에 (이전에는 비공개 카탈로그 뷰로 불림) 우리는 2개의 별도 뷰 (네임스페이스 뷰 및 전역 뷰)에서 벗어나 성능을 결합하면서 전체적인 뷰를 단일 전역 뷰로 이동하는 중점을 변경했습니다.

제한 사항

기능을 노출하는 모든 MVC는 처음부터 제한 사항이 추가되어야 합니다. 기능을 사용한 후에 제한을 하는 것보다 새로운 기능을 제한된 상태로 추가하는 것이 더 안전합니다. 사용자 수요에 따라 제한 사항을 나중에 완화할 수 있습니다.

추가할 수 있는 일부 제한 사항:

• 단일 프로젝트가 포함하거나 내보낼 수 있는 구성 요소의 수
• .gitlab-ci.yml 파일이 사용할 수 있는 가져오기(import)의 수
• 구성 요소가 선언/사용할 수 있는 가져오기(import)의 수
• 중첩된 가져오기(import)의 최대 레벨
• 내보낸 구성 요소 이름의 최대 길이

담당자

제안:

DRI(본인에게 직접적인 책임이 있는 사람):

도메인 전문가: