히스토리

• GitLab 16.0에서 실험 기능으로 도입되었으며, 기능 플래그 ci_namespace_catalog_experimental를 사용합니다. 기본적으로 비활성화되어 있습니다.
• GitLab 16.2에서 GitLab.com 및 GitLab Self-Managed에서 활성화되었습니다.
• GitLab 16.3에서 기능 플래그 ci_namespace_catalog_experimental가 제거되었습니다.
• GitLab 16.6에서 베타로 이동되었습니다.
• GitLab 17.0에서 정식으로 제공되기 시작했습니다.

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

컴포넌트는 더 동적인 동작을 위해 입력 파라미터로 설정할 수 있습니다.

CI/CD 컴포넌트는 include 키워드로 추가하는 다른 종류의 설정과 유사하지만, 다음과 같은 몇 가지 장점이 있습니다.

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

직접 컴포넌트를 만드는 대신, CI/CD 카탈로그에서 필요한 기능을 갖춘 게시된 컴포넌트를 검색할 수도 있습니다.

소개와 실습 예제는 재사용 가능한 CI/CD 컴포넌트로 효율적인 DevSecOps 워크플로 구성하기를 참고합니다.

일반적인 질문과 추가 지원은 FAQ: GitLab CI/CD Catalog 블로그 게시물을 참고합니다.

컴포넌트 프로젝트#

히스토리

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

컴포넌트 프로젝트는 하나 이상의 컴포넌트를 호스팅하는 리포지터리를 가진 GitLab 프로젝트입니다. 프로젝트 내 모든 컴포넌트는 함께 버전 관리되며, 프로젝트당 최대 100개까지 지원합니다.

컴포넌트가 다른 컴포넌트와 다른 버전 관리가 필요한 경우, 해당 컴포넌트는 전용 컴포넌트 프로젝트로 옮겨야 합니다.

컴포넌트 프로젝트 생성#

컴포넌트 프로젝트를 생성하려면 다음을 수행해야 합니다.

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 마크다운 파일.
• 모든 컴포넌트 설정을 포함하는 최상위 templates/ 디렉터리. 이 디렉터리에서는 다음을 수행할 수 있습니다.
  • 각 컴포넌트마다 .yml로 끝나는 단일 파일을 사용합니다. 예: templates/secret-detection.yml.
  • 각 컴포넌트마다 template.yml 파일을 가진 하위 디렉터리를 생성합니다. 예: templates/secret-detection/template.yml. 컴포넌트를 사용하는 다른 프로젝트에서는 template.yml 파일만 사용됩니다. 이 디렉터리의 다른 파일은 컴포넌트와 함께 릴리스되지 않지만, 테스트나 컨테이너 이미지 빌드 등에 사용할 수 있습니다.

컴포넌트 파일명과 하위 디렉터리 이름에는 문자, 숫자, 밑줄(_), 하이픈(-), 마침표(.)를 사용할 수 있습니다. 예를 들어 templates/secret-detection.enterprise.yml과 templates/secret-detection.enterprise/template.yml는 유효한 컴포넌트 파일명입니다.

다음도 수행해야 합니다.

• 컴포넌트를 테스트하고 새 버전을 릴리스하도록 프로젝트의 .gitlab-ci.yml을 설정합니다.
• 컴포넌트 사용을 다루는 원하는 라이선스로 LICENSE.md 파일을 추가합니다. 예를 들어 MIT 또는 Apache 2.0 오픈 소스 라이선스가 있습니다.

예를 들면 다음과 같습니다.

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

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

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

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

  이 예제에서:

  • my-component 컴포넌트의 설정은 단일 파일에 정의되어 있습니다.
  • my-other-component 컴포넌트의 설정은 디렉터리에 여러 파일을 포함합니다. 다른 프로젝트에서 컴포넌트를 사용할 때는 template.yml 파일만 사용할 수 있습니다.

컴포넌트 사용#

사전 요구 사항:

현재 그룹 또는 프로젝트를 포함하는 상위 그룹의 멤버인 경우:

• 프로젝트의 상위 그룹의 표시 수준(visibility level)이 설정한 최소 권한을 가지고 있어야 합니다. 예를 들어 상위 프로젝트가 Private로 설정된 경우 Reporter, Developer, Maintainer 또는 Owner 권한이 있어야 합니다.

프로젝트의 CI/CD 설정에 컴포넌트를 추가하려면 include: component 키워드를 사용합니다. 컴포넌트 참조는 <fully-qualified-domain-name>/<project-path>/<component-name>@<specific-version> 형식으로 작성하며, 예를 들면 다음과 같습니다.

include:
  - component: $CI_SERVER_FQDN/my-org/security-components/secret-detection@1.0.0
    inputs:
      stage: build

이 예제에서:

• $CI_SERVER_FQDN은 GitLab 호스트와 일치하는 정규화된 도메인 이름(FQDN)을 위한 사전 정의된 변수입니다. 프로젝트와 같은 GitLab 인스턴스에 있는 컴포넌트만 참조할 수 있습니다.
• my-org/security-components는 컴포넌트를 포함하는 프로젝트의 전체 경로입니다.
• secret-detection은 단일 파일 templates/secret-detection.yml 또는 template.yml을 포함하는 디렉터리 templates/secret-detection/로 정의된 컴포넌트 이름입니다.
• 1.0.0은 컴포넌트의 버전입니다.

파이프라인 설정과 컴포넌트 설정은 독립적으로 처리되지 않습니다. 파이프라인이 시작되면 포함된 컴포넌트 설정이 파이프라인 설정에 병합됩니다. 파이프라인과 컴포넌트가 동일한 이름의 설정을 포함하는 경우, 예상치 못한 방식으로 상호작용할 수 있습니다.

예를 들어 이름이 같은 두 job은 하나의 job으로 병합됩니다. 마찬가지로, 파이프라인의 job과 같은 이름의 설정에 extends를 사용하는 컴포넌트는 잘못된 설정을 확장할 수 있습니다. 컴포넌트의 설정을 재정의할 의도가 아니라면, 파이프라인과 컴포넌트가 동일한 이름의 설정을 공유하지 않도록 해야 합니다.

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

컴포넌트 버전#

우선순위가 높은 순서대로, 컴포넌트 버전은 다음이 될 수 있습니다.

• 커밋 SHA, 예: e3262fdd0914fa823210cdb79a8c421e2cef79d8.
• 태그, 예: 1.0.0. 같은 이름의 태그와 커밋 SHA가 모두 존재하는 경우, 커밋 SHA가 태그보다 우선합니다. CI/CD 카탈로그에 릴리스되는 컴포넌트는 시맨틱 버전으로 태그를 지정해야 합니다.
• 브랜치 이름, 예: main. 같은 이름의 브랜치와 태그가 모두 존재하는 경우, 태그가 브랜치보다 우선합니다.
• ~latest 또는 부분 시맨틱 버전. CI/CD 카탈로그에 게시된 지정한 패턴에서 최신 버전을 선택합니다. 항상 절대적인 최신 버전을 사용하려는 경우에만 ~latest를 사용합니다. 이는 호환성을 깨는 변경 사항을 포함할 수 있습니다. ~latest는 프로덕션에 적합하지 않은 것으로 간주되는 사전 릴리스, 예: 1.0.1-rc를 포함하지 않습니다.

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

부분 시맨틱 버전#

CI/CD 카탈로그 컴포넌트를 참조할 때 부분 시맨틱 버전 번호나 ~latest를 사용하여 지정한 사양과 일치하는 최신 게시 버전을 선택합니다. 이 형식은 게시된 CI/CD 카탈로그 컴포넌트에서만 작동하며, 일반 프로젝트 컴포넌트에서는 작동하지 않습니다.

이 방식은 컴포넌트의 사용자와 작성자 모두에게 상당한 이점을 제공합니다.

• 사용자에게는 부분 버전을 사용하는 것이 메이저 릴리스로 인한 호환성 문제 없이 마이너 또는 패치 업데이트를 자동으로 받을 수 있는 좋은 방법입니다. 이를 통해 파이프라인이 안정성을 유지하면서 최신 버그 수정과 보안 패치로 최신 상태를 유지할 수 있습니다.
• 컴포넌트 작성자에게는 부분 버전 지원을 통해 기존 파이프라인을 즉시 깨뜨릴 위험 없이 메이저 버전을 릴리스할 수 있습니다. 부분 버전을 지정한 사용자는 계속해서 호환되는 최신 마이너 또는 패치 버전을 사용하게 되어, 자신의 속도에 맞춰 파이프라인을 업데이트할 시간을 가질 수 있습니다.

사용법:

• 1.2: 최신 1.2.* 버전 선택
• 1: 최신 1.*.* 버전 선택
• ~latest: 최신 릴리스된 버전 선택

예를 들어 컴포넌트에 다음 버전이 있다고 가정합니다: 1.0.0, 1.1.0, 1.1.1, 1.2.0, 2.0.0, 2.0.1, 2.1.0

컴포넌트를 참조할 때:

• 1은 1.2.0을 선택합니다
• 1.1은 1.1.1을 선택합니다
• ~latest는 2.1.0을 선택합니다

부분 버전 선택을 사용할 때는 사전 릴리스 버전을 가져오지 않습니다. 사전 릴리스 버전을 가져오려면 전체 버전을 지정합니다. 예: 1.0.1-rc.

컴포넌트에서 컴포넌트 컨텍스트 사용#

히스토리

• GitLab 18.6에서 ci_component_context_interpolation이라는 이름의 기능 플래그와 함께 베타로 도입되었습니다. 기본적으로 활성화되어 있습니다.
• GitLab 18.7에서 정식으로 제공됩니다. 기능 플래그 ci_component_context_interpolation가 제거되었습니다.

컴포넌트는 컴포넌트 컨텍스트 CI/CD 표현식으로 자기 자신에 대한 메타데이터에 접근할 수 있습니다. 컴포넌트 템플릿에서 이 표현식을 사용하여 버전, 커밋 SHA 및 기타 메타데이터를 동적으로 참조합니다.

컴포넌트에서 컴포넌트 컨텍스트를 사용하려면 다음을 수행해야 합니다.

1. spec:component 헤더에서 컴포넌트에 필요한 컴포넌트 컨텍스트 필드를 선언합니다. spec:component는 name, sha, version, reference 필드를 지원합니다.
2. 컴포넌트 템플릿(spec 섹션 외부)에서 CI/CD 표현식 $[[ component.field-name ]]을 사용하여 컨텍스트 필드를 참조합니다.

예를 들어 같은 버전으로 빌드된 Docker 이미지를 참조하는 컴포넌트는 다음과 같습니다.

spec:
  component: [name, version, reference]
  inputs:
    stage:
      default: build
---

build-image:
  stage: $[[ inputs.stage ]]
  image: registry.example.com/$[[ component.name ]]:$[[ component.version ]]
  script:
    - echo "Building with component version $[[ component.version ]]"
    - echo "Component reference: $[[ component.reference ]]"

컴포넌트 컨텍스트를 사용하여 버전 관리된 리소스를 참조할 수도 있습니다.

컴포넌트 spec 섹션#

컴포넌트 템플릿의 spec 섹션은 컴포넌트의 설정과 입력을 정의합니다. spec 섹션에서 다음 키워드를 사용할 수 있습니다.

• description: CI/CD 카탈로그에 표시되는 컴포넌트에 대한 간단한 설명을 제공합니다.
• inputs: 사용자가 컴포넌트 설정을 커스터마이즈할 수 있도록 입력 파라미터를 정의합니다.
• component: 인터폴레이션에 사용할 수 있는 컴포넌트 컨텍스트 필드(name, sha, version, reference 등)를 선언합니다.

컴포넌트 작성#

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

의존성 관리#

컴포넌트가 다른 컴포넌트를 차례로 사용하는 것이 가능하지만, 의존성을 신중하게 선택해야 합니다. 의존성을 관리하려면 다음을 수행합니다.

• 의존성을 최소한으로 유지합니다. 일반적으로 약간의 중복이 의존성을 갖는 것보다 낫습니다.
• 가능하면 로컬 의존성에 의존합니다. 예를 들어 include:local을 사용하는 것은 여러 파일에서 동일한 Git SHA를 사용하도록 보장하는 좋은 방법입니다.
• 다른 프로젝트의 컴포넌트에 의존할 때는 ~latest 나 Git 참조와 같은 이동 대상 버전 대신 카탈로그의 릴리스로 버전을 고정합니다. 릴리스나 Git SHA를 사용하면 항상 동일한 리비전을 가져오도록 보장되며, 컴포넌트 사용자가 일관된 동작을 얻을 수 있습니다.
• 최신 릴리스로 고정하여 의존성을 정기적으로 업데이트합니다. 그런 다음 업데이트된 의존성으로 컴포넌트의 새 릴리스를 게시합니다.
• 의존성의 권한을 평가하고, 필요한 권한이 가장 적은 의존성을 사용합니다. 예를 들어 이미지를 빌드해야 하는 경우, 권한이 있는 Docker 데몬을 가진 러너가 필요하지 않도록 Docker 대신 Buildah 사용을 고려합니다.

명확한 README.md 작성#

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

• 컴포넌트가 제공하는 기능에 대한 요약으로 시작합니다.
• 프로젝트에 여러 컴포넌트가 포함된 경우, 사용자가 특정 컴포넌트의 세부 정보로 빠르게 이동할 수 있도록 목차를 사용합니다.
• 각 컴포넌트마다 ### Component A와 같은 하위 섹션이 있는 ## Components 섹션을 추가합니다.
• 각 컴포넌트 섹션에서:
  • 컴포넌트가 수행하는 작업을 설명합니다.
  • 사용 방법을 보여주는 YAML 예제를 최소 하나 이상 추가합니다.
  • 컴포넌트가 사용하는 변수나 시크릿을 문서화하려면 spec:inputs:description을 사용합니다.
  • README에 입력 문서를 중복 작성하지 않습니다. 입력은 컴포넌트 페이지에 자동으로 표시됩니다. 대신 게시된 컴포넌트로 링크합니다.
• 기여를 환영하는 경우 ## Contribute 섹션을 추가합니다.

컴포넌트에 더 많은 지침이 필요한 경우, 컴포넌트 디렉터리에 있는 마크다운 파일에 추가 문서를 작성하고 기본 README.md 파일에서 링크합니다. 예를 들면 다음과 같습니다.

README.md    # with links to the specific docs.md
templates/
├── component-1/
│   ├── template.yml
│   └── docs.md
└── component-2/
    ├── template.yml
    └── docs.md

예제는 AWS 컴포넌트 README를 참고합니다.

컴포넌트 테스트#

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

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

예를 들면 다음과 같습니다.

include:
  # include the component located in the current project from the current SHA
  - component: $CI_SERVER_FQDN/$CI_PROJECT_PATH/my-component@$CI_COMMIT_SHA
    inputs:
      stage: build

stages: [build, test, release]

# Check if `component job of my-component` is added.
# This example job could also test that the included component works as expected.
# You can inspect data generated by the component, use GitLab API endpoints, or third-party tools.
ensure-job-added:
  stage: test
  image: badouralix/curl-jq
  # Replace "component job of my-component" with the job name in your 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

# If the pipeline is for a new tag with a semantic version, and all previous jobs succeed,
# create the release.
create-release:
  stage: release
  image: registry.gitlab.com/gitlab-org/cli:latest
  script: echo "Creating release $CI_COMMIT_TAG"
  rules:
    - if: $CI_COMMIT_TAG
  release:
    tag_name: $CI_COMMIT_TAG
    description: "Release $CI_COMMIT_TAG of components repository $CI_PROJECT_PATH"

변경 사항을 커밋하고 푸시한 후, 파이프라인이 컴포넌트를 테스트하고 이전 job 이 통과하면 릴리스를 생성합니다.

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

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

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

자세한 내용은 컴포넌트 테스트 예제를 참고합니다.

인스턴스 또는 프로젝트별 값을 하드코딩하지 않기#

컴포넌트에서 다른 컴포넌트를 사용할 때는 인스턴스의 정규화된 도메인 이름(예: gitlab.com) 대신 $CI_SERVER_FQDN을 사용합니다.

컴포넌트에서 GitLab API에 접근할 때는 인스턴스의 전체 URL과 경로(예: https://gitlab.com/api/v4) 대신 $CI_API_V4_URL을 사용합니다.

이러한 사전 정의된 변수는 다른 인스턴스에서 사용될 때도 컴포넌트가 작동하도록 보장합니다. 예를 들어 GitLab Self-Managed 인스턴스에서 GitLab.com 컴포넌트를 사용할 수 있습니다.

API 리소스가 항상 공개되어 있다고 가정하지 않기#

컴포넌트와 테스트 파이프라인이 GitLab Self-Managed에서도 작동하는지 확인합니다. GitLab.com의 공개 프로젝트 중 일부 API 리소스는 인증되지 않은 요청으로 접근할 수 있습니다. 그러나 GitLab Self-Managed 인스턴스에서는 컴포넌트 프로젝트가 비공개 또는 내부 프로젝트로 미러링될 수 있습니다.

GitLab Self-Managed 인스턴스에서 요청을 인증할 수 있도록 입력이나 변수를 통해 액세스 토큰을 선택적으로 제공할 수 있어야 한다는 점이 중요합니다.

전역 키워드 사용 피하기#

컴포넌트에서 전역 키워드 사용을 피합니다. 컴포넌트에서 이러한 키워드를 사용하면 기본 .gitlab-ci.yml에 직접 정의된 job 이나 다른 포함된 컴포넌트의 job을 포함하여 파이프라인의 모든 job에 영향을 미칩니다.

전역 키워드의 대안으로:

• 컴포넌트 설정에 약간의 중복이 생기더라도, 각 job에 설정을 직접 추가합니다.
• 컴포넌트에서 extends 키워드를 사용하되, 컴포넌트가 설정에 병합될 때 이름 충돌 위험을 줄이는 고유한 이름을 사용합니다.

예를 들어 default 전역 키워드 사용은 피합니다.

# Not recommended
default:
  image: ruby:3.0

rspec-1:
  script: bundle exec rspec dir1/

rspec-2:
  script: bundle exec rspec dir2/

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

• 각 job에 설정을 명시적으로 추가합니다.

  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 입니다. 컴포넌트 job의 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
  

입력으로 job 이름 정의하기#

stage 키워드의 값과 마찬가지로 CI/CD 컴포넌트에서 job 이름을 하드코딩하지 않아야 합니다. 컴포넌트 사용자가 job 이름을 커스터마이즈할 수 있으면 자신의 파이프라인에 있는 기존 이름과의 충돌을 방지할 수 있습니다. 사용자는 서로 다른 이름을 사용해 컴포넌트를 여러 번 포함하면서 다른 입력 옵션을 적용할 수도 있습니다.

컴포넌트 사용자가 특정 job 이름이나 job 이름의 접두사를 정의할 수 있도록 inputs를 사용합니다. 예를 들면 다음과 같습니다.

spec:
  inputs:
    job-prefix:
      description: "Define a prefix for the job name"
    job-name:
      description: "Alternatively, define the job's name"
    job-stage:
      default: test
---

"$[[ inputs.job-prefix ]]-scan-website":
  stage: $[[ inputs.job-stage ]]
  script:
    - scan-website-1

"$[[ inputs.job-name ]]":
  stage: $[[ inputs.job-stage ]]
  script:
    - scan-website-2

커스텀 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 변수로 저장하도록 사용자에게 요청합니다.

CI/CD 카탈로그#

히스토리

• GitLab 16.1에서 실험 기능으로 도입되었습니다.
• GitLab 16.7에서 베타로 전환되었습니다.
• GitLab 17.0에서 일반 공급(GA)으로 전환되었습니다.

CI/CD 카탈로그는 CI/CD 워크플로를 확장하는 데 사용할 수 있는 게시된 CI/CD 컴포넌트를 보유한 프로젝트 목록입니다.

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

클릭으로 살펴보는 데모는 CI/CD 카탈로그 베타 제품 투어를 참고합니다.

CI/CD 카탈로그 보기#

CI/CD 카탈로그에 접근해 사용 가능한 게시된 컴포넌트를 확인하려면 다음과 같이 합니다.

1. 상단 바에서 Search or go to를 선택합니다.
2. Explore를 선택합니다.
3. CI/CD Catalog를 선택합니다.

또는 이미 프로젝트의 파이프라인 에디터에 있다면 CI/CD Catalog를 선택할 수 있습니다.

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

• Private 인 경우 소스 컴포넌트 프로젝트에서 Guest, Planner, Reporter, Developer, Maintainer, Owner 권한이 부여된 사용자에게만 표시됩니다. 컴포넌트를 사용하려면 Reporter, Developer, Maintainer, Owner 권한이 있어야 합니다.
• Internal 인 경우 GitLab 인스턴스에 로그인한 사용자에게만 표시됩니다.
• Public 인 경우 GitLab 인스턴스에 접근 권한이 있는 모든 사용자에게 표시됩니다.

목록에 있는 각 CI/CD 카탈로그 프로젝트에는 사용 횟수가 표시됩니다. 이 수치는 지난 30일 동안 파이프라인에서 카탈로그 프로젝트의 컴포넌트를 하나라도 사용한 고유 프로젝트의 총 개수를 나타냅니다.

CI/CD 카탈로그 프로젝트 분석 보기#

히스토리

• GitLab 18.9에서 도입되었습니다.

CI/CD 카탈로그 리소스를 관리하는 경우 사용 현황 분석을 확인해 프로젝트 전반에서 컴포넌트가 어떻게 채택되고 있는지 파악할 수 있습니다.

사전 요구 사항:

• 하나 이상의 카탈로그 리소스 프로젝트에 대해 Maintainer 또는 Owner 권한이 있어야 합니다.

카탈로그 리소스 분석을 보려면 다음과 같이 합니다.

1. 상단 바에서 Search or go to > Explore를 선택합니다.
2. CI/CD Catalog를 선택합니다.
3. Analytics 탭을 선택합니다.

분석 화면에는 Maintainer 또는 Owner 권한을 가진 카탈로그 리소스가 표시됩니다. 이 화면에서는 다음을 확인할 수 있습니다.

• Projects: 카탈로그 리소스 이름과 최신 릴리스 버전입니다.
• Usage statistics: 지난 30일 동안 파이프라인에서 이 카탈로그 리소스의 컴포넌트를 사용한 고유 프로젝트 수입니다.
• Components: 카탈로그 리소스의 최신 버전에서 사용 가능한 컴포넌트 목록입니다.

예를 들면 다음과 같습니다.

이 정보를 다음과 같이 활용할 수 있습니다.

• 가장 널리 채택된 카탈로그 리소스를 파악합니다.
• 시간에 따른 컴포넌트의 사용 추이를 추적합니다.
• 어떤 프로젝트가 카탈로그 리소스를 사용하고 있는지 파악합니다.
• 컴포넌트 유지 관리 및 폐기에 대해 근거 있는 결정을 내립니다.

컴포넌트 사용 현황 상세 보기#

히스토리

• GitLab 19.0에서 도입되었습니다.

CI/CD 카탈로그 컴포넌트 프로젝트를 관리하는 경우 상세한 컴포넌트 사용 현황 정보를 확인해 어떤 프로젝트가 컴포넌트를 사용하고 어떤 버전을 사용하는지 파악할 수 있습니다. 이를 통해 업그레이드를 계획하고, 폐기 사항을 전달하고, 오래된 버전을 사용하는 프로젝트를 파악할 수 있습니다.

상세 페이지에는 각 컴포넌트 이름 옆에 사용 횟수도 표시됩니다. 이 수치는 버전별로 집계되며 지난 30일 동안 해당 컴포넌트 버전을 사용한 고유 프로젝트 수를 나타냅니다.

사전 요구 사항:

• 카탈로그 리소스 프로젝트에 대해 Maintainer 또는 Owner 권한이 있어야 합니다.

컴포넌트 사용 현황 상세를 보려면 다음과 같이 합니다.

1. 상단 바에서 Search or go to > Explore를 선택합니다.
2. CI/CD Catalog를 선택합니다.
3. 카탈로그에서 컴포넌트 프로젝트를 선택합니다.
4. 상세 페이지에서 Usage 탭을 선택합니다.

이 탭에는 지난 30일 동안 파이프라인에서 이 프로젝트의 컴포넌트를 하나라도 포함한 프로젝트가 나열됩니다. 목록에는 사용자가 볼 수 있는 권한이 있는 프로젝트만 포함됩니다.

상세 정보에는 다음이 포함됩니다.

• Project path: 프로젝트로 연결되는 링크가 있는 프로젝트의 전체 경로입니다.
• Status: 프로젝트가 컴포넌트의 최신 버전을 사용한 경우 Up to date로 표시됩니다. 그렇지 않으면 Outdated로 표시됩니다.
• Components used: 프로젝트가 사용하는 컴포넌트의 이름과 버전입니다.

사용자에게 표시되지 않는 프로젝트는 링크 없이 Private project로 표시됩니다.

이 정보를 다음과 같이 활용할 수 있습니다.

• 오래된 컴포넌트 버전을 사용 중이어서 업그레이드가 필요한 프로젝트를 파악합니다.
• 새 버전을 사용할 수 있거나 컴포넌트를 폐기할 때 프로젝트 관리자에게 알립니다.
• 조직 전체에서 특정 컴포넌트 버전의 채택 현황을 파악합니다.

컴포넌트 프로젝트 게시#

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

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

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

컴포넌트 프로젝트의 게시된 버전을 CI/CD 카탈로그에 표시하려면 프로젝트를 카탈로그 프로젝트로 설정해야 합니다.

사전 요구 사항:

• 프로젝트에 대해 Owner 권한이 있어야 합니다.

프로젝트를 카탈로그 프로젝트로 설정하려면 다음과 같이 합니다.

1. 상단 바에서 Search or go to를 선택하고 프로젝트를 찾습니다.
2. 왼쪽 사이드바에서 Settings > General을 선택합니다.
3. Visibility, project features, permissions를 확장합니다.
4. CI/CD Catalog project 토글을 켭니다.

새 릴리스를 게시해야만 프로젝트가 카탈로그에서 검색 가능해집니다.

이 설정을 자동화로 활성화하려면 mutationcatalogresourcescreate GraphQL 엔드포인트를 사용할 수 있습니다. Issue 463043에서 이를 REST API에도 노출하도록 제안하고 있습니다.

새 릴리스 게시#

CI/CD 컴포넌트는 CI/CD 카탈로그에 등록되지 않아도 사용할 수 있습니다. 다만 컴포넌트의 릴리스를 카탈로그에 게시하면 다른 사용자가 이를 발견할 수 있게 됩니다.

사전 요구 사항:

• 프로젝트에 대해 Maintainer 또는 Owner 권한이 있어야 합니다.
• 프로젝트는 다음을 충족해야 합니다.
  • 카탈로그 프로젝트로 설정되어 있어야 합니다.
  • 프로젝트 설명이 정의되어 있어야 합니다.
  • 릴리스할 태그의 커밋 SHA 기준으로 루트 디렉터리에 README.md 파일이 있어야 합니다.
  • 릴리스할 태그의 커밋 SHA 기준으로 templates/ 디렉터리에 CI/CD 컴포넌트가 하나 이상 있어야 합니다.
• 릴리스를 생성할 때는 Releases API가 아니라 CI/CD job에서 release 키워드를 사용해야 합니다.

새 버전의 컴포넌트를 카탈로그에 게시하려면 다음과 같이 합니다.

1. 태그가 생성될 때 release 키워드를 사용해 새 릴리스를 생성하는 job을 프로젝트의 .gitlab-ci.yml 파일에 추가합니다. 릴리스 job을 실행하기 전에 컴포넌트를 테스트하도록 태그 파이프라인을 설정해야 합니다. 예를 들면 다음과 같습니다.

   create-release:
     stage: release
     image: registry.gitlab.com/gitlab-org/cli:latest
     script: echo "Creating release $CI_COMMIT_TAG"
     rules:
       - if: $CI_COMMIT_TAG
     release:
       tag_name: $CI_COMMIT_TAG
       description: "Release $CI_COMMIT_TAG of components in $CI_PROJECT_PATH"
   

2. 릴리스를 위한 새 태그를 생성합니다. 이 태그는 릴리스 생성을 담당하는 job 이 포함된 태그 파이프라인을 트리거해야 합니다. 태그는 시맨틱 버저닝을 사용해야 합니다.

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

시맨틱 버저닝#

컴포넌트를 태깅하여 카탈로그에 새 버전을 릴리스할 때는 시맨틱 버저닝을 사용해야 합니다. 시맨틱 버저닝은 변경 사항이 메이저, 마이너, 패치 또는 다른 종류의 변경인지 전달하기 위한 표준입니다.

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

컴포넌트 프로젝트 게시 취소#

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

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

검증된 컴포넌트 제작자#

히스토리

• GitLab 16.11에서 GitLab.com 대상으로 도입
• GitLab 18.1에서 GitLab Self-Managed 및 GitLab Dedicated 대상으로 도입

일부 CI/CD 컴포넌트에는 검증됨 아이콘이 표시됩니다. 이 아이콘은 해당 컴포넌트가 GitLab이나 인스턴스 관리자에게 검증된 사용자에 의해 만들어지고 유지 관리된다는 것을 나타냅니다.

• GitLab 유지 관리(GitLab-maintained) ([tanuki-verified]): GitLab 이 만들고 유지 관리하는 GitLab.com 컴포넌트입니다.

• GitLab 파트너(GitLab Partner) ([partner-verified]): GitLab 이 검증한 파트너가 독립적으로 만들고 유지 관리하는 GitLab.com 컴포넌트입니다.

  GitLab 파트너는 GitLab Partner Alliance 담당자에게 연락해 GitLab.com 상의 자신의 네임스페이스를 GitLab 검증됨으로 표시할 수 있습니다. 그러면 해당 네임스페이스에 있는 모든 CI/CD 컴포넌트는 GitLab 파트너 컴포넌트로 배지가 표시됩니다. Partner Alliance 담당자는 검증된 파트너를 대신해 내부 요청 이슈(GitLab 팀원 전용)를 생성합니다.

  [!warning] GitLab 파트너가 만든 컴포넌트는 어떠한 종류의 보증도 없이 있는 그대로(as-is) 제공됩니다. 최종 사용자가 GitLab 파트너가 만든 컴포넌트를 사용하는 것은 본인의 책임이며 GitLab은 최종 사용자의 컴포넌트 사용과 관련해 어떠한 배상 의무나 유형의 책임도 지지 않습니다. 이러한 콘텐츠의 사용 및 이와 관련된 모든 책임은 해당 콘텐츠의 게시자와 최종 사용자 사이의 문제입니다.

• 검증된 제작자(Verified creator) ([check-sm]): 관리자에게 검증된 사용자가 만들고 유지 관리하는 컴포넌트입니다.

컴포넌트를 검증된 제작자가 유지 관리하는 것으로 설정#

히스토리

• GitLab 18.1에서 GitLab Self-Managed 및 GitLab Dedicated 대상으로 도입

GitLab 관리자는 CI/CD 컴포넌트를 검증된 제작자가 만들고 유지 관리하는 것으로 설정할 수 있습니다.

1. 관리자 계정으로 인스턴스에서 GraphiQL을 엽니다. 예를 들어 https://gitlab.example.com/-/graphql-explorer에서 엽니다.

2. 검증할 컴포넌트의 루트 네임스페이스로 root-level-group을 바꾸어 다음 쿼리를 실행합니다.

   mutation {
     verifiedNamespaceCreate(input: { namespacePath: "root-level-group",
       verificationLevel: VERIFIED_CREATOR_SELF_MANAGED
       }) {
       errors
     }
   }
   

쿼리가 완료되면 루트 네임스페이스에 있는 프로젝트의 모든 컴포넌트가 검증됩니다. CI/CD 카탈로그에서 컴포넌트 이름 옆에 Verified creator 배지가 표시됩니다.

컴포넌트에서 배지를 제거하려면 verificationLevel을 UNVERIFIED로 바꾸어 쿼리를 다시 실행합니다.

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 Self-Managed에서 GitLab.com 컴포넌트 사용#

새로 설치한 GitLab 인스턴스의 CI/CD 카탈로그는 게시된 CI/CD 컴포넌트가 없는 상태로 시작됩니다. 인스턴스의 카탈로그를 채우려면 다음을 수행할 수 있습니다.

• 자체 컴포넌트를 게시합니다.
• GitLab Self-Managed 인스턴스에서 GitLab.com의 컴포넌트를 미러링합니다.

GitLab Self-Managed 인스턴스에서 GitLab.com 컴포넌트를 미러링하려면 다음과 같이 합니다.

1. gitlab.com에 대해 아웃바운드 네트워크 요청이 허용되어 있는지 확인합니다.
2. 컴포넌트 프로젝트를 호스팅할 그룹을 생성합니다(권장 그룹명: components).
3. 새 그룹에 컴포넌트 프로젝트의 미러를 생성합니다.
4. 리포지터리를 미러링해도 설명은 복사되지 않으므로 컴포넌트 프로젝트 미러에 대한 프로젝트 설명을 작성합니다.
5. 셀프 호스팅한 컴포넌트 프로젝트를 카탈로그 리소스로 설정합니다.
6. 태그(보통 최신 태그)에 대해 파이프라인을 실행하여 셀프 호스팅한 컴포넌트 프로젝트에 새 릴리스를 게시합니다.

CI/CD 컴포넌트 보안 모범 사례#

컴포넌트 사용자를 위한 권장 사항#

누구나 카탈로그에 컴포넌트를 게시할 수 있으므로 프로젝트에서 사용하기 전에 컴포넌트를 신중하게 검토해야 합니다. GitLab CI/CD 컴포넌트 사용은 전적으로 본인 책임이며 GitLab은 서드파티 컴포넌트의 보안을 보장할 수 없습니다.

서드파티 CI/CD 컴포넌트를 사용할 때는 다음 보안 모범 사례를 고려합니다.

• 컴포넌트 소스 코드를 감사하고 검토합니다: 악성 콘텐츠가 없는지 확인하기 위해 코드를 꼼꼼히 검토합니다.
• 자격 증명 및 토큰에 대한 접근을 최소화합니다:
  • 자격 증명이나 토큰이 예상하고 승인한 작업을 수행하는 데만 사용되는지 확인하기 위해 컴포넌트의 소스 코드를 감사합니다.
  • 최소한으로 범위가 지정된 액세스 토큰을 사용합니다.
  • 수명이 긴 액세스 토큰이나 자격 증명 사용을 피합니다.
  • CI/CD 컴포넌트가 사용하는 자격 증명과 토큰의 사용 내역을 감사합니다.
• 고정된 버전을 사용합니다: 파이프라인에서 사용하는 컴포넌트의 무결성을 보장하려면 CI/CD 컴포넌트를 특정 커밋 SHA(권장)나 릴리스 버전 태그에 고정합니다. 릴리스 태그는 컴포넌트 관리자를 신뢰하는 경우에만 사용합니다. latest 사용은 피합니다.
• 시크릿을 안전하게 저장합니다: CI/CD 설정 파일에 시크릿을 저장하지 않습니다. 외부 시크릿 관리 솔루션을 사용할 수 있다면 프로젝트 설정에 시크릿과 자격 증명을 저장하는 것을 피합니다.
• 일회성의 격리된 러너 환경을 사용합니다: 가능하면 컴포넌트 job을 임시로 격리된 환경에서 실행합니다. 셀프 매니지드 러너의 보안 위험을 숙지합니다.
• 캐시와 아티팩트를 안전하게 처리합니다: 반드시 필요한 경우가 아니라면 파이프라인의 다른 job에서 나온 캐시나 아티팩트를 CI/CD 컴포넌트 job에 전달하지 않습니다.
• CI_JOB_TOKEN 접근을 제한합니다: CI/CD 컴포넌트를 사용하는 프로젝트에 대해 CI/CD job 토큰(CI_JOB_TOKEN)의 프로젝트 접근 및 권한을 제한합니다.
• CI/CD 컴포넌트 변경 사항을 검토합니다: 컴포넌트에 대해 업데이트된 커밋 SHA 나 릴리스 태그로 변경하기 전에 CI/CD 컴포넌트 설정의 모든 변경 사항을 신중하게 검토합니다.
• 커스텀 컨테이너 이미지를 감사합니다: CI/CD 컴포넌트가 사용하는 커스텀 컨테이너 이미지에 악성 콘텐츠가 없는지 신중하게 검토합니다.

컴포넌트 관리자를 위한 권장 사항#

안전하고 신뢰할 수 있는 CI/CD 컴포넌트를 유지하고 사용자에게 제공하는 파이프라인 구성의 무결성을 보장하려면 다음 모범 사례를 따릅니다.

• 2단계 인증(2FA) 사용: 모든 CI/CD 컴포넌트 프로젝트 관리자와 소유자가 2FA를 활성화하도록 하거나, 그룹의 모든 사용자에게 2FA를 강제합니다.
• 보호된 브랜치 사용:
  • 컴포넌트 프로젝트 릴리스에는 보호된 브랜치를 사용합니다.
  • 기본 브랜치를 보호하고, 와일드카드 규칙을 사용해 모든 릴리스 브랜치를 보호합니다.
  • 보호된 브랜치에 대한 변경 사항은 모두 머지 리퀘스트로 제출하도록 요구합니다. 보호된 브랜치의 Allowed to push and merge 옵션을 No one으로 설정합니다.
  • 보호된 브랜치로의 강제 푸시를 차단합니다.
• 모든 커밋 서명: 컴포넌트 프로젝트에 대해 모든 커밋을 서명합니다.
• latest 사용 지양: README.md에 @latest를 사용하는 예시를 포함하지 않습니다.
• 다른 job의 캐시·아티팩트 의존 제한: CI/CD 컴포넌트에서 다른 job의 캐시와 아티팩트는 반드시 필요한 경우에만 사용합니다
• CI/CD 컴포넌트 의존성 업데이트: 의존성 업데이트를 정기적으로 확인하고 적용합니다.
• 변경 사항 신중히 검토:
  • 기본 브랜치나 릴리스 브랜치에 머지하기 전에 CI/CD 컴포넌트 파이프라인 구성에 대한 모든 변경 사항을 신중하게 검토합니다.
  • CI/CD 컴포넌트 카탈로그 프로젝트에 대한 사용자 대상 변경 사항 전체에 머지 리퀘스트 승인을 사용합니다.

문제 해결#

content not found 메시지#

카탈로그 프로젝트에서 호스팅하는 컴포넌트를 참조할 때 ~latest 또는 부분 시맨틱 버전 한정자를 사용하면 이 오류가 표시될 수 있습니다.

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

~latest 한정자는 카탈로그 리소스의 최신 시맨틱 버전을 가리킵니다. 이 문제를 해결하려면 새 릴리스를 생성합니다.

오류: Build component error: Spec must be a valid json schema#

컴포넌트 형식이 올바르지 않으면 릴리스를 생성할 때 다음과 유사한 오류가 발생할 수 있습니다: Build component error: Spec must be a valid json schema

이 오류는 빈 spec:inputs 섹션 때문에 발생할 수 있습니다. 구성에서 입력을 사용하지 않는다면 spec 섹션을 대신 비워둘 수 있습니다. 예를 들면 다음과 같습니다.

spec:
---

my-component:
  script: echo