CI/CD 컴포넌트

Tier: Free, Premium, Ultimate Offering: GitLab.com, 자체관리형, GitLab Dedicated

CI/CD 컴포넌트는 재사용 가능한 단일 파이프라인 구성 단위입니다. 컴포넌트를 사용하여 큰 파이프라인의 작은 부분을 만들거나 완전한 파이프라인 구성을 작성할 수 있습니다.

컴포넌트는 input parameters로 동적 동작을 더 많이 설정할 수 있습니다.

CI/CD 컴포넌트는 include 키워드로 추가된 다른 종류의 구성요소와 유사하지만 여러 이점이 있습니다:

  • 컴포넌트는 CI/CD 카탈로그에 나열할 수 있습니다.
  • 특정 버전과 함께 릴리스되고 사용할 수 있습니다.
  • 하나의 프로젝트에 여러 개의 컴포넌트를 정의하고 함께 버전 관리할 수 있습니다.

자체 컴포넌트를 만드는 대신, 필요한 기능을 가진 공개된 컴포넌트를 CI/CD 카탈로그에서 찾을 수도 있습니다.

소개 및 실습 예제는 재사용 가능한 CI/CD 컴포넌트로 효율적인 DevSecOps 워크플로우를 참조하세요.

컴포넌트 프로젝트

  • GitLab 16.9에서 프로젝트 당 최대 컴포넌트 수가 10개에서 30개로 변경되었습니다.

컴포넌트 프로젝트는 하나 이상의 컴포넌트를 호스팅하는 리포지터리를 가진 GitLab 프로젝트입니다. 프로젝트의 모든 컴포넌트는 최대 30개까지 함께 버전 관리됩니다.

컴포넌트가 다른 컴포넌트와 다른 버전 관리를 필요로 하는 경우 해당 컴포넌트를 전용 컴포넌트 프로젝트로 이동해야 합니다.

컴포넌트 프로젝트 만들기

컴포넌트 프로젝트를 만들려면 다음을 해야 합니다:

  1. README.md 파일이 있는 새 프로젝트를 만듭니다:
    • 설명이 컴포넌트에 대한 명확한 소개를 제공하는지 확인합니다.
    • 프로젝트가 만들어진 후에는 프로젝트 아바타를 추가할 수 있습니다(선택사항).

    CI/CD 카달로그에 출판된 컴포넌트는 컴포넌트 프로젝트의 요약을 표시할 때 설명과 아바타를 사용합니다.

  2. 각 컴포넌트에 대한 YAML 구성 파일을 추가합니다. 필수 디렉터리 구조를 따릅니다. 예: 

    spec:
  inputs:
    stage:
      default: test
---
component-job:
  script: echo job 1
  stage: $[[ inputs.stage ]]

    컴포넌트를 사용하려면 즉시 사용할 수 있지만 컴포넌트를 CI/CD 카달로그에 출판할 것을 고려해볼 수 있습니다.

디렉터리 구조

리포지터리에는 다음이 있어야 합니다:

  • 모든 컴포넌트에 대한 세부 정보를 문서화하는 README.md Markdown 파일.
  • 모든 컴포넌트 구성을 포함하는 최상위 templates/ 디렉터리. 이 디렉터리에 컴포넌트를 정의할 수 있습니다:
    • templates/secret-detection.yml와 같이 각 컴포넌트를 위한 단일 파일로.
    • 여러 관련 파일을 번들로 묶는 컴포넌트에 대해 templates/secret-detection/template.yml와 같은 하위 디렉터리에 template.yml 파일을 포함하는 서브 디렉터리에.
note
각 컴포넌트는 자체의 README.md 파일을 가질 수 있으며 상위 README.md 파일에서 연결할 수 있습니다(선택사항). 이는 컴포넌트 프로젝트와 사용 방법에 대한 개요를 제공하는 데 도움이 됩니다.

또한 다음을 해야 합니다:

예:

  • 프로젝트에 단일 컴포넌트가 포함되어 있는 경우 디렉터리 구조는 다음과 유사해야 합니다: 

    ├── templates/
│   └── my-component.yml
├── LICENSE.md
├── README.md
└── .gitlab-ci.yml

  • 프로젝트에 여러 컴포넌트가 포함되어 있는 경우 디렉터리 구조는 다음과 유사해야 합니다: 

    ├── templates/
│   ├── my-simple-component.yml
│   └── my-complex-component/
│       ├── template.yml
│       ├── Dockerfile
│       └── test.sh
├── LICENSE.md
├── README.md
└── .gitlab-ci.yml

    이 예제에서:

    • my-simple-component 구성은 단일 파일에 정의됩니다.
    • my-complex-component 구성은 디렉터리에 여러 파일이 포함됩니다.

컴포넌트 사용

프로젝트의 CI/CD 구성에 컴포넌트를 추가하려면 include: component 키워드를 사용합니다. 컴포넌트 참조 형식은 <fully-qualified-domain-name>/<project-path>/<component-name>@<specific-version>으로 포맷됩니다. 예: 

include:
  - component: gitlab.example.com/my-org/security-components/secret-detection@1.0.0
    inputs:
      stage: build

이 예제에서:

  • gitlab.example.com은 GitLab 호스트와 일치하는 완전한 도메인 이름(FQDN)입니다. 프로젝트는 프로젝트와 동일한 GitLab 인스턴스에서만 참조할 수 있습니다.
  • my-org/security-components는 컴포넌트가 포함된 프로젝트의 전체 경로입니다.
  • secret-detection은 단일 파일 templates/secret-detection.yml 또는 templates/secret-detection/ 디렉터리에 정의된 컴포넌트 이름입니다.
  • 1.0.0은 버전입니다.

GitLab이 새 파이프라인을 생성하면 컴포넌트의 구성이 가져오되고 파이프라인 구성에 추가됩니다.

Self-Managed형 인스턴스에서 GitLab.com 컴포넌트를 사용하려면 컴포넌트 프로젝트를 미러해야 합니다.

컴포넌트 버전

가장 우선 순위가 높은 순으로, 컴포넌트 버전은 다음과 같습니다:

  • 커밋 SHA(예: e3262fdd0914fa823210cdb79a8c421e2cef79d8).
  • 태그, 예: 1.0.0. 동일한 이름의 태그와 커밋 SHA가 있는 경우 커밋 SHA가 우선합니다. CI/CD에 출시된 컴포넌트는 semantic version으로 태그가 지정되어야 합니다.
  • 브랜치 이름, 예: main. 동일한 이름의 브랜치와 태그가 있는 경우 태그가 우선합니다.
  • ~latest는 항상 CI/CD 카탈로그에 발행된 최신 의미 있는 버전을 가리킵니다. ~latest는 언제나 최신 버전을 사용하려는 경우에만 사용하며 이는 파손 변경 사항을 포함할 수 있습니다.

컴포넌트에서 지원하는 모든 버전을 사용할 수 있지만 CI/CD 카탈로그에 발행된 버전을 사용하는 것이 추천됩니다. 커밋 SHA나 브랜치 이름으로 참조된 버전은 CI/CD 카탈로그에는 발행되지 않을 수 있지만 테스트에 사용될 수 있습니다.

시맨틱 버전 범위

CI/CD 카탈로그 컴포넌트를 참조할 때 특별한 형식을 사용하여 범위 내에서 최신 시맨틱 버전을 지정할 수 있습니다.

다음을 가장 최신 릴리스로 지정하려면:

  • 마이너 버전의 경우 참조에 주 버전 및 마이너 버전 번호를 사용하되 패치 버전 번호는 사용하지 않습니다. 예를 들어 1.1을 사용하여 1.1.로 시작하는 최신 버전을 사용하며, 1.1.0 또는 1.1.9는 포함되지만 1.2.0는 포함되지 않습니다.
  • 메이저 버전의 경우 참조에 주 버전 번호만 사용합니다. 예를 들어 1을 사용하여 1.로 시작하는 최신 버전을 사용하며, 1.0.0 또는 1.9.9는 포함되지만 2.0.0는 포함되지 않습니다.
  • 모든 버전을 사용하려면 ~latest를 사용하여 최신 릴리스 버전을 사용합니다.

예를 들어, 컴포넌트가 다음과 같은 순서로 릴리스됩니다:

  1. 1.0.0
  2. 1.1.0
  3. 2.0.0
  4. 1.1.1
  5. 1.2.0
  6. 2.1.0
  7. 2.0.1

이 예에서 다음과 같이 컴포넌트를 참조하면:

  • 1은 1.2.0 버전을 사용합니다.
  • 1.1은 1.1.1 버전을 사용합니다.
  • ~latest는 2.1.0 버전을 사용합니다.

CI/CD 카탈로그

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-Managed형, GitLab Dedicated(전용)

CI/CD 카탈로그는 발행된 CI/CD 컴포넌트를 보유한 프로젝트 디렉터리으로, CI/CD 워크플로우를 확장하는 데 사용할 수 있습니다.

누구나 컴포넌트 프로젝트를 생성하고 이를 CI/CD 카탈로그에 추가하거나 제공되는 컴포넌트를 개선하기 위해 기존 프로젝트에 기여할 수 있습니다.

클릭하여 데모를 보려면 CI/CD 카탈로그 베타 제품 투어를 참조하세요.

CI/CD 카탈로그 보기

CI/CD 카탈로그에 액세스하여 사용 가능한 발행된 컴포넌트를 보려면 다음을 수행합니다:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택합니다.
  2. 탐색을 선택합니다.
  3. CI/CD 카탈로그를 선택합니다.

또는 이미 프로젝트의 파이프라인 편집기에 있는 경우 CI/CD 카탈로그 둘러보기를 선택할 수 있습니다.

CI/CD 카탈로그의 컴포넌트 가시성은 컴포넌트 소스 프로젝트의 가시성 설정을 따릅니다. 컴포넌트 소스 프로젝트의 가시성 설정이:

  • 비공개인 경우 해당 컴포넌트 소스 프로젝트에 적어도 게스트 역할이 할당된 사용자만이 볼 수 있습니다.
  • 내부인 경우 GitLab 인스턴스에 로그인한 사용자만이 볼 수 있습니다.
  • 공개인 경우 GitLab 인스턴스에 액세스할 수 있는 누구나 볼 수 있습니다.

컴포넌트 프로젝트 발행

CI/CD 카탈로그에 컴포넌트 프로젝트를 발행하려면 다음을 수행해야 합니다:

  1. 프로젝트를 카탈로그 프로젝트로 설정해야 합니다.
  2. 새 릴리스를 발행해야 합니다.

컴포넌트 프로젝트를 카탈로그 프로젝트로 설정

컴포넌트 프로젝트의 발행된 버전을 CI/CD 카탈로그에서 볼 수 있도록 하려면 프로젝트를 카탈로그 프로젝트로 설정해야 합니다.

전제 조건:

  • 프로젝트에서 소유자 역할을 가지고 있어야 합니다.

프로젝트를 카탈로그 프로젝트로 설정하려면:

  1. 왼쪽 사이드바에서 검색 또는 이동을 선택하고 프로젝트를 찾습니다.
  2. 설정 > 일반을 선택합니다.
  3. 가시성, 프로젝트 기능, 권한을 확장합니다.
  4. CI/CD 카탈로그 프로젝트 토글을 켭니다.

프로젝트가 새로운 릴리스를 발행한 후에야 카탈로그에서 프로젝트를 찾을 수 있습니다.

새 릴리스 발행

CI/CD 컴포넌트는 CI/CD 카탈로그에 나열되지 않은 상태에서도 사용할 수 있습니다. 그러나 카탈로그에 컴포넌트 릴리스를 발행하면 다른 사용자가 해당 릴리스를 찾을 수 있게 됩니다.

전제 조건:

컴포넌트의 새 버전을 카탈로그에 발행하려면:

  1. 프로젝트의 .gitlab-ci.yml 파일에 release 키워드를 사용하여 새 릴리스를 생성하는 작업을 추가합니다. 릴리스 작업을 실행하기 전에 태그 파이프라인이 컴포넌트를 테스트하도록 태그 파이프라인을 구성해야 합니다. 예를 들어: 

    create-release:
  stage: release
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  script: echo "$CI_COMMIT_TAG의 릴리스 생성"
  rules:
    - if: $CI_COMMIT_TAG
  release:
    tag_name: $CI_COMMIT_TAG
    description: "$CI_PROJECT_PATH의 컴포넌트 $CI_COMMIT_TAG 릴리스"

  2. 릴리스를 생성하기 위해 새 태그를 만듭니다. 이는 릴리스를 만드는 작업을 포함하는 태그 파이프라인을 트리거해야 합니다. 태그는 시맨틱 버전을 사용해야 합니다.

릴리스 작업이 성공적으로 완료되면 릴리스가 생성되고 새 버전이 CI/CD 카탈로그에 발행됩니다.

시맨틱 버전

컴포넌트를 카탈로그에 새 버전을 태깅하고 릴리스하는 경우 시맨틱 버전을 사용해야 합니다. 시맨틱 버전은 변경이 주 버전, 마이너 버전, 패치 또는 다른 종류의 변경인지를 알리는 표준입니다.

예를 들어, 1.0.0, 2.3.4, 1.0.0-alpha는 모두 유효한 시맨틱 버전입니다.

컴포넌트 프로젝트 발행 취소

카탈로그에서 컴포넌트 프로젝트를 제거하려면 프로젝트 설정에서 CI/CD 카탈로그 자원 토글을 끕니다.

caution
이 조치는 카탈로그에 게시된 컴포넌트 프로젝트 및 해당 버전에 대한 메타데이터를 삭제합니다. 프로젝트 및 해당 리포지터리는 여전히 존재하지만 카탈로그에서는 표시되지 않습니다.

다시 프로젝트를 카탈로그에 발행하려면 새 릴리스를 발행해야 합니다.

확인된 컴포넌트 생성자

일부 CI/CD 컴포넌트에는 GitLab이 인증한 사용자가 만들고 유지하는 것을 나타내는 아이콘이 부착됩니다:

  • GitLab에서 관리하는 것 (): GitLab이 만들고 유지하는 컴포넌트입니다.
  • GitLab 파트너 (): GitLab이 검증한 파트너가 만들고 유지하는 컴포넌트입니다.

모범 사례

이 섹션에서는 높은 품질의 컴포넌트 프로젝트를 만들기 위한 몇 가지 모범 사례를 설명합니다.

의존성 관리

컴포넌트가 순환적으로 다른 컴포넌트를 사용할 수 있는 경우가 있지만, 의존성을 주의 깊게 선택해야 합니다. 의존성을 관리하기 위해 다음을 준수해야 합니다:

  • 의존성을 최소화합니다. 소량의 중복은 일반적으로 의존성을 가지는 것보다 나은 경우가 많습니다.
  • 가능한 경우 로컬 의존성에 의존합니다. 예를 들어, include:local을 사용하여 여러 파일에서 동일한 Git SHA가 사용되도록하는 것이 좋은 방법입니다.
  • 다른 프로젝트의 컴포넌트에 의존할 때, 이동 대상 버전(~latest)이나 Git 참조를 사용하는 대신 카탈로그의 릴리스 버전에 해당하는 버전을 지정하세요. 릴리스나 Git SHA를 사용하면 항상 동일한 리비전을 가져오고 컴포넌트 소비자가 일관된 동작을 얻을 수 있습니다.
  • 의존성을 최신 릴리스에 고정시키고 업데이트하세요. 그런 다음 업데이트된 의존성이 포함된 컴포넌트의 새 릴리스를 게시하세요.

명확한 README.md 작성

각 컴포넌트 프로젝트는 명확하고 포괄적인 문서를 가져야합니다. 좋은 README.md 파일을 작성하려면:

  • 문서는 프로젝트에서 제공하는 컴포넌트의 기능에 대한 요약으로 시작해야 합니다.
  • 프로젝트에 여러 컴포넌트가 포함된 경우, 사용자가 빠르게 특정 컴포넌트의 세부 정보로 이동할 수 있도록 목차를 사용하세요.
  • 각 컴포넌트를 위한 ## 컴포넌트 섹션과 ### 컴포넌트 A와 같은 하위 섹션이 있는 섹션을 추가하세요.
  • 각 컴포넌트 섹션에서:
    • 컴포넌트의 기능에 대한 설명을 추가하세요.
    • 사용 방법을 보여주는 YAML 예제를 하나 이상 추가하세요.
    • 컴포넌트가 입력을 사용하는 경우, 이름, 설명, 유형 및 기본값이 있는 모든 입력을 보여주는 테이블을 추가하세요.
    • 컴포넌트가 변수나 비밀을 사용하는 경우 해당 정보도 문서화해야 합니다.
  • 기여가 환영되는 경우 ## 기여 섹션이 권장됩니다.

컴포넌트가 더 많은 지침이 필요한 경우, 컴포넌트 디렉터리의 마크다운 파일에서 추가 문서를 추가하고 메인 README.md 파일에서 해당 문서로 링크해야 합니다. 예를 들어: 

README.md    # 특정 문서.md로의 링크가 있는 경우
templates/
├── component-1/
│   ├── template.yml
│   └── docs.md
└── component-2/
    ├── template.yml
    └── docs.md

컴포넌트 README.md의 예는 GitLab CI/CD와 함께 AWS로 배포하는 컴포넌트의 README.md에서 확인할 수 있습니다.

컴포넌트 테스트

개발 워크플로우의 일환으로 CI/CD 컴포넌트를 테스트하는 것이 강력히 권장되며 일관된 동작을 보장하는 데 도움이 됩니다.

.gitlab-ci.yml 파일을 루트 디렉터리에 생성하여 CI/CD 파이프라인에서 변화를 테스트하세요 (기타 프로젝트와 마찬가지로). 컴포넌트의 동작 및 잠재적인 부작용을 모두 테스트하세요. 필요한 경우 GitLab API를 사용할 수 있습니다.

예를 들어: 

include:
  # 현재 SHA에서의 현재 프로젝트의 위치에 있는 컴포넌트를 포함
  - component: $CI_SERVER_FQDN/$CI_PROJECT_PATH/my-component@$CI_COMMIT_SHA
    inputs:
      stage: build

stages: [build, test, release]

# `my-component`의 컴포넌트 작업이 추가되었는지 확인
# 이 예제 작업은 포함된 컴포넌트가 예상대로 작동하는 지 테스트 할 수도 있습니다.
# 컴포넌트에서 생성된 데이터를 검사하거나 GitLab API 엔드포인트 또는 타사 도구를 사용할 수 있습니다.
ensure-job-added:
  stage: test
  image: badouralix/curl-jq
  # 컴포넌트에서 작업 이름으로 교체하세요.
  script:
    - |
      route="${CI_API_V4_URL}/projects/${CI_PROJECT_ID}/pipelines/${CI_PIPELINE_ID}/jobs"
      count=`curl --silent "$route" | jq 'map(select(.name | contains("component job of my-component"))) | length'`
      if [ "$count" != "1" ]; then
        exit 1; else
        echo "Component Job present"
      fi

# 이전 작업이 모두 성공한 새로운 태그를 위한 파이프라인이고,
# 모든 이전 작업이 성공하면 릴리스를 만듭니다.
create-release:
  stage: release
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  script: echo "Creating release $CI_COMMIT_TAG"
  rules:
    - if: $CI_COMMIT_TAG
  release:
    tag_name: $CI_COMMIT_TAG
    description: "릴리스 $CI_COMMIT_TAG of components repository $CI_PROJECT_PATH"

변화를 커밋하고 푸시한 후, 파이프라인은 컴포넌트를 테스트하고 이전 작업이 성공하면 릴리스를 생성합니다.

note
프로젝트가 비공개인 경우 인증이 필요합니다.

샘플 파일에 대한 컴포넌트 테스트

일부 경우에는 컴포넌트가 상호 작용하기 위해 소스 파일이 필요합니다. 예를 들어, Go 소스 코드를 빌드하는 컴포넌트는 Go 샘플이 필요합니다. 또는 Docker 이미지를 빌드하는 컴포넌트는 Dockerfile 샘플이 필요할 수 있습니다.

이러한 샘플 파일을 컴포넌트 프로젝트에 직접 포함하여 컴포넌트 테스트에 사용할 수 있습니다.

컴포넌트 테스트에 대한 예제를 컴포넌트 테스트 예제에서 자세히 알아보세요.

전역 키워드 사용 피하기

컴포넌트에서 전역 키워드를 사용하는 것을 피하세요. 컴포넌트에서 이러한 키워드를 사용하면 주요 .gitlab-ci.yml에 직접 정의되거나 다른 포함된 컴포넌트에 정의된 작업을 포함하여 파이프라인의 모든 작업에 영향을 줄 수 있습니다.

전역 키워드 대신 대안으로:

  • 컴포넌트 구성에 중복이 발생하더라도 각 작업에 구성을 직접 추가하세요.
  • 컴포넌트에서 extends 키워드를 사용하지만 컴포넌트가 구성에 Merge될 때 이름 충돌 위험을 줄이는 고유한 이름을 사용하세요.

예를 들어, default 전역 키워드를 사용하는 것을 피하세요: 

# 비권장
default:
  image: ruby:3.0

rspec-1:
  script: bundle exec rspec dir1/

rspec-2:
  script: bundle exec rspec dir2/

대신 다음을 수행할 수 있습니다:

  • 각 작업에 구성을 명시적으로 추가하세요: 

    rspec-1:
  image: ruby:3.0
  script: bundle exec rspec dir1/
  
rspec-2:
  image: ruby:3.0
  script: bundle exec rspec dir2/

  • 구성을 재사용하기 위해 extends를 사용하세요: 

    .rspec-image:
  image: ruby:3.0
  
rspec-1:
  extends:
    - .rspec-image
  script: bundle exec rspec dir1/
  
rspec-2:
  extends:
    - .rspec-image
  script: bundle exec rspec dir2/

하드코딩된 값을 입력으로 대체하기

CI/CD 컴포넌트에 하드코딩된 값을 사용하지 마세요. 하드코딩된 값은 컴포넌트 사용자가 컴포넌트의 내부 세부 정보를 검토하고 그에 맞게 파이프라인을 조정해야 하는 경우가 있습니다.

stage와 같은 문제가 있는 하드코딩된 값에는 불편한 키워드가 흔히 있습니다. 만약 컴포넌트 작업의 stage가 하드코딩되어 있다면, 컴포넌트를 사용하는 모든 파이프라인은 정확히 동일한 stage를 정의하거나 포함된 구성의 값을 재정의해야 합니다.

선호하는 방법은 동적 컴포넌트 구성을 위해 input 키워드를 사용하는 것입니다. 컴포넌트 사용자가 필요한 정확한 값을 지정할 수 있습니다.

예를 들어, 사용자가 정의할 수 있는 stage 구성이 있는 컴포넌트를 만들기 위해:

  • 컴포넌트 구성에서: 

    spec:
  inputs:
    stage:
      default: test
---
unit-test:
  stage: $[[ inputs.stage ]]
  script: echo unit tests
  
integration-test:
  stage: $[[ inputs.stage ]]
  script: echo integration tests

  • 컴포넌트를 사용하는 프로젝트에서: 

    stages: [verify, release]
  
include:
  - component: $CI_SERVER_FQDN/myorg/ruby/test@1.0.0
    inputs:
      stage: verify

사용자 지정 CI/CD 변수를 입력으로 대체

컴포넌트에서 CI/CD 변수를 사용할 때 inputs 키워드를 사용하는 것이 더 나은 해결책인 경우를 평가하세요. inputs가 더 나은 해결책일 때 사용자 정의 변수를 정의하도록 요구하는 것을 피하세요.

입력은 컴포넌트의 spec 섹션에서 명시적으로 정의되며, 변수보다 더 나은 유효성을 갖습니다. 예를 들어, 컴포넌트에 필요한 입력이 전달되지 않으면 GitLab에서는 파이프라인 오류를 반환합니다. 비교적으로, 변수가 정의되지 않으면 해당 값은 비어 있으며 오류가 발생하지 않습니다.

예를 들어, 스캐너의 출력 형식을 구성하기 위해 변수 대신 inputs를 사용하세요:

  • 컴포넌트 구성: 

    spec:
  inputs:
    scanner-output:
      default: json
---
my-scanner:
  script: my-scan --output $[[ inputs.scanner-output ]]

  • 컴포넌트를 사용하는 프로젝트: 

    include:
  - component: $CI_SERVER_FQDN/path/to/project/my-scanner@1.0.0
    inputs:
      scanner-output: yaml

다른 경우에는, 여전히 CI/CD 변수를 선호할 수 있습니다. 예를 들어:

CI/CD 템플릿을 컴포넌트로 변환

include: 구문을 사용하여 프로젝트에서 사용하는 기존 CI/CD 템플릿을 CI/CD 컴포넌트로 변환할 수 있습니다:

  1. 기존 컴포넌트 프로젝트의 일부로 컴포넌트를 그룹화할지 또는 새 컴포넌트 프로젝트를 만들지 결정하세요.
  2. 디렉터리 구조에 따라 컴포넌트 프로젝트에서 YAML 파일을 만드세요.
  3. 기존 템플릿 YAML 파일의 내용을 새 컴포넌트 YAML 파일로 복사하세요.
  4. 새 컴포넌트의 구성을 리팩터링하여:
  5. 컴포넌트 리포지터리의 .gitlab-ci.yml을 활용하여 컴포넌트의 변경 사항을 테스트하세요.
  6. 컴포넌트를 태그하고 릴리스하세요.

Go CI/CD 템플릿을 CI/CD 컴포넌트로 마이그레이션 실제 예제를 따라 자세히 알아보세요.

GitLab.com 컴포넌트를 Self-Managed형 인스턴스에서 사용

Tier: Premium, Ultimate Offering: Self-Managed, GitLab Dedicated

GitLab 인스턴스의 최신 설치에서는 게시된 CI/CD 컴포넌트가 없습니다. 인스턴스의 카탈로그를 채우려면 다음을 수행할 수 있습니다:

Self-Managed형 인스턴스에서 GitLab.com 컴포넌트를 미러링하려면:

  1. gitlab.com에 대해 네트워크 외부 요청이 허용되는지 확인하세요.
  2. 컴포넌트 프로젝트를 호스팅할 그룹을 만드세요(권장 그룹: components).
  3. 새 그룹에 컴포넌트 프로젝트를 미러로 생성하세요.
  4. 리포지터리를 미러링하면 리포지터리 설명이 복사되지 않으므로, 컴포넌트 프로젝트 미러에 프로젝트 설명을 작성하세요.
  5. 자체 호스트된 컴포넌트 프로젝트를 카탈로그 리소스로 설정하세요.
  6. 자체 호스트된 컴포넌트 프로젝트에서 태그별 파이프라인을 실행하여 새 릴리스를 게시하세요.

문제 해결

content not found 메시지

카탈로그 프로젝트에서 호스팅되는 컴포넌트를 참조하는 데 ~latest 버전 한정자를 사용할 때 다음과 유사한 오류 메시지를 받을 수 있습니다: 

This GitLab CI configuration is invalid: component 'gitlab.com/my-namespace/my-project/my-component@~latest' - content not found

~latest 동작은 GitLab 16.10에서 업데이트되었습니다. 이제 이 동작은 카탈로그 리소스의 최신 시맨틱 버전을 참조합니다. 이 문제를 해결하려면 새 릴리스를 생성하세요.