CI/CD 컴포넌트

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

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

컴포넌트는 더 동적인 동작을 위해 입력 매개변수로 구성될 수 있습니다.

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와 같이 각 컴포넌트를 위한 하나의 파일로.
    • 서로 관련된 여러 파일을 번들로 결합하는 컴포넌트에 대한 template.yml 파일을 포함하는 하위 디렉터리로. 예를 들면 templates/secret-detection/template.yml.
note
각 컴포넌트는 자체의 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 또는 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 카탈로그 찾아보기를 선택할 수 있습니다.

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

컴포넌트 프로젝트 발행

CI/CD 카탈로그에 컴포넌트 프로젝트를 발행하려면 다음이 필요합니다:

  1. 프로젝트를 카탈로그 프로젝트로 설정합니다.
  2. 새로운 버전을 발행합니다.

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

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

전제 조건:

  • 프로젝트에서 소유자 역할을 가져야 합니다.

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

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

프로젝트는 새로운 버전을 발행한 후에 카탈로그에서 발견할 수 있게 됩니다.

새 버전 발행

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_PROJECT_PATH의 컴포넌트 $CI_COMMIT_TAG 발행"

  2. 발행되는 버전을 위한 새 태그를 생성합니다. 이는 발행 작업을 담당하는 작업을 포함하는 태그 파이프라인을 트리거해야 합니다.

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

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

프로젝트 설정에서 CI/CD 카탈로그 리소스를 끄면 카탈로그에서 컴포넌트 프로젝트가 제거됩니다.

caution
이 작업은 카탈로그에서 발행된 컴포넌트 프로젝트 및 해당 버전의 메타데이터를 파괴합니다. 프로젝트와 리포지터리는 그대로 남아 있지만 카탈로그에서는 보이지 않습니다.

다시 카탈로그에 컴포넌트 프로젝트를 발행하려면 새로운 버전을 발행해야 합니다.

모범 사례

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

의존성 관리

컴포넌트가 다른 컴포넌트를 사용할 수 있지만, 의존성을 신중하게 선택해야 합니다. 의존성을 관리하기 위해 다음을 해야 합니다:

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

명확한 README.md 작성

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

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

컴포넌트가 더 많은 지침이 필요한 경우, 컴포넌트 디렉터리에서 Markdown 파일을 추가로 문서화하고 메인 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에 배포하는 컴포넌트의 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]

# `component job of my-component`이 추가되었는지 확인합니다.
# 이 예시 작업은 포함된 컴포넌트가 예상대로 작동하는지도 테스트할 수 있습니다.
# 컴포넌트에서 생성된 데이터를 검사하거나, GitLab API 엔드포인트, 제3자 도구를 사용할 수 있습니다.
ensure-job-added:
  stage: test
  image: badouralix/curl-jq
  # "component job of 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: "Release $CI_COMMIT_TAG of components repository $CI_PROJECT_PATH"

변경 사항을 커밋하고 푸시한 후, 파이프라인은 컴포넌트를 테스트한 다음 이전 작업이 통과되면 릴리스를 만듭니다.

샘플 파일을 사용하여 컴포넌트 테스트

일부 경우에는 컴포넌트가 상호 작용할 소스 파일이 필요합니다. 예를 들어, 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, deploy]
  
include:
  - component: $CI_SERVER_FQDN/myorg/ruby/test@1.0.0
    inputs:
      stage: verify

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

컴포넌트에서 CI/CD 변수를 사용할 때, 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. 원본 템플릿 YAML 파일의 내용을 새로운 컴포넌트 YAML 파일로 복사합니다.
  4. 새 컴포넌트의 구성을 리팩터링하여:
  5. 컴포넌트의 리포지터리에 있는 .gitlab-ci.yml을 활용하여 컴포넌트에 대한 변경 사항을 테스트합니다.
  6. 컴포넌트를 태그하고 릴리스합니다.

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에서 업데이트되었습니다. 이제 이 동작은 카탈로그 리소스의 최신 시맨틱 버전을 참조합니다. 이 문제를 해결하려면 새로운 릴리스를 생성하십시오.