CI/CD 구성 요소

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-Managed, GitLab Dedicated Status: Beta

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

입력 매개변수로 구성된 컴포넌트는 보다 동적인 동작이 가능합니다.

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

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

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

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

컴포넌트 프로젝트

  • 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와 같이 각 컴포넌트를 위한 단일 파일로.
    • 다수의 관련 파일을 묶어둔 컴포넌트에 대한 하위 디렉토리로, 해당 디렉토리에는 template.yml 파일이 있습니다. 예시: templates/secret-detection/template.yml.

참고: 각 컴포넌트가 자체 README.md 파일을 가지고 있어도 됩니다. 이는 더 상세한 정보를 제공하고 최상위 README.md 파일에서 링크될 수 있습니다. 이를 통해 컴포넌트 프로젝트와 사용 방법에 대한 더 나은 개요를 제공합니다.

또한 다음을 해야 합니다:

  • 프로젝트의 .gitlab-ci.yml를 구성하여 컴포넌트를 테스트하고 새 버전을 릴리스할 수 있도록 합니다.
  • 사용된 오픈 소스 라이선스의 사용을 커버하는 선택한 라이선스가 포함된 LICENSE.md 파일을 추가합니다. 예를 들어 MIT 또는 Apache 2.0 라이선스 등이 있습니다.

예시:

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

    ├── 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 또는 template.yml을 포함하는 templates/secret-detection/로 정의된 구성 요소의 이름입니다.
  • 1.0.0은 구성 요소의 버전입니다.

GitLab이 새로운 파이프라인을 생성하면 구성 요소의 구성이 검색되어 파이프라인 구성에 추가됩니다.

자체 관리형 인스턴스에서 GitLab.com 구성 요소를 사용하려면 구성 요소 프로젝트를 미러해야 합니다.

구성 요소 버전

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

  • 커밋 SHA(예: e3262fdd0914fa823210cdb79a8c421e2cef79d8). 커밋 SHA를 사용하여 CI/CD 카탈로그에 공개되지 않은 특정 버전으로 구성 요소를 고정합니다.
  • 태그(예: 1.0.0). 동일한 이름으로 태그와 커밋 SHA가 있는 경우 커밋 SHA가 우선합니다.
  • 브랜치 이름(예: main). 동일한 이름으로 브랜치와 태그가 있는 경우 태그가 브랜치보다 우선합니다.
  • ~latest는 항상 CI/CD 카탈로그에 공개된 최신 시맨틱 버전을 가리키는 특별한 버전입니다. 항상 최신 버전을 사용하려면 ~latest를 사용하며, 이는 파괴적인 변경 사항을 포함할 수 있습니다.

구성 요소에서 지원하는 모든 버전을 사용할 수 있지만, CI/CD 카탈로그에 공개된 버전을 사용하는 것이 좋습니다.

시맨틱 버전 사용

구성 요소의 태그 작성 및 새 버전을 릴리스할 때는 시맨틱 버전을 사용해야 합니다. 시맨틱 버전은 변경 사항이 주요 변경, 마이너 변경, 패치 또는 다른 유형의 변경임을 알리기 위한 표준입니다.

예를들어:

  • 1.0.0
  • 2.1.3
  • 1.0.0-alpha
  • 3.0.0-rc1

CI/CD 카탈로그

Tier: Free, Premium, Ultimate Offering: GitLab.com, Self-managed, GitLab Dedicated Status: Beta

CI/CD 카탈로그는 공개된 CI/CD 구성 요소가 포함된 프로젝트 목록으로, CI/CD 워크플로우를 확장하는데 사용할 수 있습니다.

누구나 구성 요소 프로젝트를 생성하고 CI/CD 카탈로그에 추가하거나 기존 프로젝트에 기여하여 사용 가능한 구성 요소를 개선할 수 있습니다.

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

CI/CD 카탈로그 보기

CI/CD 카탈로그에 액세스하여 사용 가능한 공개된 구성 요소를 확인하려면 다음을 수행합니다:

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

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

참고: CI/CD 카탈로그에서는 공개 및 내부 프로젝트만 찾을 수 있습니다.

구성 요소 프로젝트 공개

CI/CD 카탈로그에 구성 요소 프로젝트를 공개하려면 다음을 수행해야 합니다:

  1. 프로젝트를 카탈로그 프로젝트로 설정합니다.
  2. 새 릴리스를 공개합니다.

구성 요소 프로젝트를 카탈로그 프로젝트로 설정

구성 요소 프로젝트의 공개된 버전을 CI/CD 카탈로그에서 찾을 수 있도록 하려면 프로젝트를 카탈로그 프로젝트로 설정해야 합니다.

전제 조건: - 프로젝트에서 소유자 역할이어야 합니다.

프로젝트를 카탈로그 프로젝트로 설정하려면 다음을 수행합니다:

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

프로젝트는 새 릴리스를 공개한 후에 카탈로그에서 찾을 수 있게 됩니다.

새 릴리스 공개

CI/CD 구성 요소는 사용되어도 CI/CD 카탈로그에 나열되지 않을 수 있습니다. 그러나 구성 요소의 릴리스를 카탈로그에 게시하면 다른 사용자들이 해당 구성 요소를 발견할 수 있습니다.

필수 사항:

  • 프로젝트는 다음을 준수해야 합니다:
    • 카탈로그 프로젝트로 설정되어 있어야 합니다.
    • 프로젝트 설명이 정의되어 있어야 합니다.
    • 릴리스할 태그의 커밋 SHA를 가진 루트 디렉터리의 README.md 파일이 있어야 합니다.
    • 릴리스할 태그의 커밋 SHA를 가진 templates/ 디렉터리에 최소한 하나의 CI/CD 구성 요소가 있어야 합니다.

구성 요소의 새 버전을 카탈로그에 게시하려면:

  1. 프로젝트의 .gitlab-ci.yml 파일에 release 키워드를 사용하여 새 릴리스를 작성하는 작업을 추가합니다. 새 태그가 생성될 때 릴리스 작업을 실행하도록 태그 파이프라인을 구성해야 합니다. 예를 들면 다음과 같습니다: 

    create-release:
  stage: deploy
  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_COMMIT_TAG의 $CI_PROJECT_PATH 구성 요소 릴리스"

  2. 릴리스를 위해 새 태그를 생성합니다. 이는 릴리스를 만드는 책임을 지는 작업을 포함하는 태그 파이프라인을 트리거해야 합니다.

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

구성 요소 프로젝트 비게시

카탈로그에서 구성 요소 프로젝트를 제거하려면 프로젝트 설정에서 CI/CD 카탈로그 리소스 토글을 끕니다.

경고: 이 작업은 카탈로그에 게시된 구성 요소 프로젝트와 해당 버전에 대한 메타데이터를 삭제합니다. 프로젝트와 해당 저장소는 계속해서 존재하지만 카탈로그에는 표시되지 않습니다.

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

모범 사례

이 섹션에서는 고품질의 구성 요소 프로젝트를 만드는 몇 가지 모범 사례를 설명합니다.

종속성 관리

한 구성 요소가 다른 구성 요소를 사용하는 것은 가능하지만, 종속성을 신중하게 선택해야 합니다. 종속성을 관리하기 위해 다음을 준수해야 합니다:

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

명확한 README.md 작성

각 구성 요소 프로젝트에는 명확하고 포괄적인 설명서가 있어야 합니다. 좋은 README.md 파일을 작성하기 위해:

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

구성 요소에 더 많은 지침이 필요한 경우 메인 README.md 파일에서 구성 요소 디렉터리에 있는 마크다운 파일에 추가 문서를 추가하고 그것을 링크해야 합니다. 예를 들면: 

README.md    # 특정 docs.md에 대한 링크가 있는 파일
templates/
├── component-1/
│   ├── template.yml
│   └── docs.md
└── component-2/
    ├── template.yml
    └── docs.md

구성 요소의 README.md 예제는 GitLab CI/CD와 함께 AWS에 배포하기를 참조하세요.

구성 요소 테스트

개발 워크플로우의 일부로 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`의 `component job`이 추가되었는지 확인합니다.
# 이 예제 작업은 포함된 구성 요소가 예상대로 작동하는지도 테스트할 수 있습니다.
# 구성 요소에서 생성된 데이터를 검사하거나 GitLab API 엔드포인트 또는 제3자 도구를 사용할 수 있습니다.
ensure-job-added:
  stage: test
  image: badouralix/curl-jq
  # "my-component" 내의 작업 이름으로 바꿔주세요.
  script:
    - |
      route="${CI_API_V4_URL}/projects/$CI_PROJECT_ID/pipelines/$CI_PIPELINE_ID/jobs"
      count=`curl --silent --header "JOB-TOKEN: $CI_JOB_TOKEN" $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
  rules:
    - if: $CI_COMMIT_TAG =~ /\d+/
  script: echo "Creating release $CI_COMMIT_TAG"
  release:
    tag_name: $CI_COMMIT_TAG
    description: "$CI_PROJECT_PATH 구성 요소 저장소의 $CI_COMMIT_TAG 릴리스"

변경 사항을 커밋하고 푸시한 후, 파이프라인은 구성 요소를 테스트하고, 이전 작업이 통과되면 릴리스를 생성합니다.

샘플 파일을 활용하여 구성 요소 테스트

일부 경우에는 구성 요소가 상호 작용할 소스 파일이 필요할 수 있습니다. 예를 들어, Go 소스 코드를 빌드하는 구성 요소는 Go의 샘플이 필요할 것입니다. 또는, Docker 이미지를 빌드하는 구성 요소는 Dockerfile의 샘플이 필요할 것입니다.

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

구성 요소 테스트 예제에서 자세한 내용을 확인할 수 있습니다.

전역 키워드 사용 피하기

구성 요소에 전역 키워드를 사용하는 것을 피하세요. 구성 요소에서 이러한 키워드를 사용하면 메인 .gitlab-ci.yml에 직접 정의되었거나 다른 포함된 구성 요소에 정의된 작업을 포함한 모든 파이프라인에 영향을 미칩니다.

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

  • 구성 요소 구성에서 각 작업에 구성을 직접 추가하십시오. 구성 요소 구성에서 일부 중복이 발생할 수 있지만, 이는 없어야 할 문제입니다.
  • 구성 요소에서 extends 키워드를 사용하되, 구성이 병합될 때 이름 충돌 가능성을 줄이는 고유한 이름을 사용하십시오.

예를 들어, 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, deploy]

include:
  - component: $CI_SERVER_FQDN/myorg/ruby/test@1.0.0
    inputs:
      stage: verify

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

구성 요소에서 CI/CD 변수를 사용할 때 inputs 키워드를 대신 사용해야 하는지를 평가합니다. inputs가 더 나은 해결책일 때 사용자에게 사용자 정의 변수를 정의하도록 요청하는 것을 피하십시오.

inputs는 구성 요소의 명세에 명시적으로 정의되며 변수보다 더 나은 유효성을 갖습니다. 예를 들어, 구성 요소에 필요한 입력이 전달되지 않으면 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. 새로운 구성 요소의 구성을 개선하여:
  4. 구성 요소의 변경 사항을 테스트하기 위해 구성 요소 리포지토리의 .gitlab-ci.yml을 활용하세요.
  5. 구성 요소를 태그 지정하고 릴리스하세요.

Go CI/CD 템플릿을 CI/CD 구성 요소로 이주하는 실제 예제를 따라 더 자세히 알아보세요.

GitLab.com 구성 요소를 자체 호스팅 인스턴스에서 사용하기

GitLab.com의 구성 요소를 자체 호스팅 인스턴스에서 사용하려면 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.11에서 업데이트되었습니다. 이제 이는 카탈로그 자원의 최신 의미적 버전을 참조합니다. 이 문제를 해결하려면 새 릴리스를 게시하세요.