CI/CD 컴포넌트

CI/CD 컴포넌트 (CI/CD components)

CI/CD 컴포넌트는 재사용 가능한 단일 파이프라인 구성 단위예요. 컴포넌트로 더 큰 파이프라인의 작은 부분을 만들 수도 있고, 완전한 파이프라인 구성을 조합할 수도 있습니다. 컴포넌트는 입력 매개변수(inputs)로 구성해 더 동적인 동작을 만들 수 있어요.

출처: 문서

본문

CI/CD 컴포넌트는 include 키워드로 추가하는 다른 구성 종류와 비슷하지만, 몇 가지 장점이 있어요.

컴포넌트를 CI/CD Catalog에 등록할 수 있습니다.
컴포넌트를 릴리스하고 특정 버전과 함께 사용할 수 있어요.
같은 프로젝트에 여러 컴포넌트를 정의하고 함께 버전을 관리할 수 있습니다.

자체 컴포넌트를 만들지 않아도, 필요한 기능을 가진 게시된 컴포넌트를 CI/CD Catalog에서 검색할 수 있어요.

컴포넌트 프로젝트 (Component project)

프로젝트당 컴포넌트 최대 개수는 GitLab 18.5에서 30개에서 100개로 변경됐어요.

컴포넌트 프로젝트는 하나 이상의 컴포넌트를 호스팅하는 저장소가 있는 GitLab 프로젝트예요. 프로젝트의 모든 컴포넌트는 함께 버전이 관리되고, 프로젝트당 최대 100개까지 컴포넌트를 둘 수 있습니다. 다른 컴포넌트와 다른 버전 관리를 필요로 하는 컴포넌트라면 전용 컴포넌트 프로젝트로 옮겨야 해요.

컴포넌트 프로젝트 만들기 (Create a component project)

컴포넌트 프로젝트를 만들려면:

README.md 파일이 있는 새 프로젝트를 만듭니다.
- 설명에 컴포넌트를 명확히 소개하세요.
- 선택 사항. 프로젝트를 만든 뒤 프로젝트 아바타를 추가할 수 있어요. CI/CD 카탈로그에 게시된 컴포넌트는 컴포넌트 프로젝트 요약을 표시할 때 설명과 아바타를 모두 사용합니다.
필수 디렉터리 구조에 따라 각 컴포넌트의 YAML 구성 파일을 추가합니다. 예를 들면 이렇습니다.

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

컴포넌트를 즉시 사용할 수 있지만, CI/CD 카탈로그에 게시하는 것도 고려해 보세요.

디렉터리 구조 (Directory structure)

저장소에는 다음이 포함되어야 합니다.

저장소의 모든 컴포넌트에 대한 세부 사항을 문서화한 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은 유효한 컴포넌트 파일 이름입니다.

[!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-component.yml
│   └── my-other-component/
│       ├── template.yml
│       ├── Dockerfile
│       └── test.sh
├── LICENSE.md
├── README.md
└── .gitlab-ci.yml

이 예시에서:

my-component 컴포넌트의 구성은 단일 파일에 정의돼요.
my-other-component 컴포넌트의 구성은 디렉터리에 여러 파일로 들어 있어요. 컴포넌트를 사용하는 다른 프로젝트는 template.yml 파일만 쓸 수 있습니다.

컴포넌트 사용 (Use a component)

사전 요구사항: 현재 그룹이나 프로젝트를 포함하는 부모 그룹의 멤버라면:

프로젝트의 부모 그룹 가시성 수준이 설정한 최소 역할이어야 해요. 예를 들어 부모 프로젝트가 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/[email protected]
    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은 컴포넌트의 버전.

파이프라인 구성과 컴포넌트 구성을 별도로 처리하지는 않아요. 파이프라인이 시작되면 include된 모든 컴포넌트 구성이 파이프라인 구성으로 병합됩니다. 파이프라인과 컴포넌트가 같은 이름의 구성을 모두 가진다면 예상치 못한 방식으로 상호작용할 수 있어요. 예를 들어 같은 이름의 job 두 개는 단일 job으로 병합됩니다. 비슷하게 컴포넌트가 파이프라인의 job과 같은 이름으로 extends를 쓰면 잘못된 구성을 확장할 수 있어요. 컴포넌트 구성을 덮어쓰려는 경우가 아니라면, 파이프라인과 컴포넌트가 같은 이름의 구성을 공유하지 않게 하세요.

GitLab Self-Managed 인스턴스에서 GitLab.com 컴포넌트를 쓰려면 컴포넌트 프로젝트를 미러링해야 해요.

[!WARNING] 컴포넌트가 동작하려면 토큰, 비밀번호 또는 기타 민감한 데이터를 사용해야 한다면, 그 데이터가 기대하고 승인한 작업에만 사용되는지 확인하기 위해 컴포넌트의 소스 코드를 감사하세요. 또한 작업을 완료하는 데 필요한 최소한의 권한, 접근, 스코프를 가진 토큰과 시크릿을 사용해야 합니다.

컴포넌트 버전 (Component versions)

우선순위가 높은 순서대로 컴포넌트 버전은 다음과 같을 수 있어요.

커밋 SHA. 예: e3262fdd0914fa823210cdb79a8c421e2cef79d8.
태그. 예: 1.0.0. 같은 이름의 태그와 커밋 SHA가 존재하면 커밋 SHA가 태그보다 우선합니다. CI/CD 카탈로그에 릴리스된 컴포넌트는 시맨틱 버전으로 태그되어야 해요.
브랜치 이름. 예: main. 같은 이름의 브랜치와 태그가 존재하면 태그가 브랜치보다 우선해요.
~latest 또는 부분 시맨틱 버전. CI/CD 카탈로그에 게시된 지정 패턴에서 최신 버전을 선택합니다. ~latest는 항상 절대 최신 버전을 쓰고 싶을 때만 사용하세요. 여기에는 브레이킹 체인지가 포함될 수 있어요. ~latest는 프리릴리스를 포함하지 않습니다. 예를 들어 1.0.1-rc는 프로덕션 준비가 완료된 것으로 간주되지 않아요.

컴포넌트가 지원하는 어떤 버전이든 쓸 수 있지만, CI/CD 카탈로그에 게시된 버전을 사용하는 것을 권장합니다. 커밋 SHA나 브랜치 이름으로 참조한 버전은 카탈로그에 게시되지 않았을 수 있지만 테스트에 쓸 수 있어요.

부분 시맨틱 버전 (Partial semantic versions)

CI/CD 카탈로그 컴포넌트를 참조할 때는 부분 시맨틱 버전 번호나 ~latest를 사용해서 지정 내용과 일치하는 최신 게시 버전을 선택할 수 있어요. 이 형식은 카탈로그에 게시된 컴포넌트에서만 동작하고, 일반 프로젝트 컴포넌트에서는 동작하지 않습니다. 이 접근 방식은 소비자와 작성자 모두에게 큰 이점을 줘요.

사용자 입장에서 부분 버전을 쓰면 메이저 릴리스의 브레이킹 체인지 위험 없이 마이너·패치 업데이트를 자동으로 받을 수 있어요. 파이프라인이 최신 버그 수정과 보안 패치를 유지하면서 안정성도 유지하게 됩니다.
컴포넌트 작성자 입장에서 부분 버전 지원은 기존 파이프라인을 즉시 깨뜨릴 위험 없이 메이저 버전을 릴리스할 수 있게 해줘요. 부분 버전을 지정한 사용자는 계속 호환되는 최신 마이너·패치 버전을 사용해, 자기 페이스대로 파이프라인을 업데이트할 시간을 갖습니다.

사용:

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처럼 전체 버전을 지정하세요.

컴포넌트에서 컴포넌트 컨텍스트 사용 (Use component context in components)

GitLab 18.6에서 ci_component_context_interpolation이라는 기능 플래그와 함께 beta로 도입. 기본으로 활성화.
GitLab 18.7에서 일반 공개. 기능 플래그 ci_component_context_interpolation 제거.

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

spec:component 헤더에서 컴포넌트가 필요한 컴포넌트 컨텍스트 필드를 선언합니다. spec:component는 name, sha, version, reference 필드를 지원해요.
컴포넌트 템플릿(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` 섹션 (Component `spec` section)

컴포넌트 템플릿의 spec 섹션은 컴포넌트의 구성과 inputs를 정의해요. spec 섹션에서 쓸 수 있는 키워드는 이렇습니다.

description: CI/CD 카탈로그에 표시되는 컴포넌트에 대한 짧은 설명 제공.
inputs: 사용자가 컴포넌트 구성을 커스터마이즈할 입력 매개변수를 정의.
component: 보간에 사용할 컴포넌트 컨텍스트 필드(name, sha, version, reference)를 선언.

[!NOTE] 컴포넌트에서 spec:include는 쓸 수 없어요. 컴포넌트는 자체적으로 완결되어야 하고 외부 파일에 의존하면 안 됩니다. inputs는 별도 파일에서 가져오지 말고 컴포넌트에 직접 정의하세요.

컴포넌트 작성 (Write a component)

이 섹션은 고품질 컴포넌트 프로젝트를 만드는 몇 가지 모범 사례를 설명해요.

의존성 관리 (Manage dependencies)

컴포넌트가 차례로 다른 컴포넌트를 쓰는 것이 가능하지만, 의존성을 신중히 선택해야 해요. 의존성을 관리하려면:

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

명확한 `README.md` 작성 (Write a clear `README.md`)

각 컴포넌트 프로젝트는 명확하고 포괄적인 문서를 가져야 해요. 좋은 README.md를 쓰려면:

컴포넌트가 제공하는 기능 요약으로 시작하세요.
프로젝트에 여러 컴포넌트가 있다면 목차(table of contents)로 사용자가 특정 컴포넌트의 세부 사항으로 빠르게 이동하도록 도와주세요.
각 컴포넌트에 대해 ### Component A 같은 서브섹션이 있는 ## Components 섹션을 추가하세요.
각 컴포넌트 섹션에서:
- 컴포넌트가 무엇을 하는지 설명.
- 사용 방법을 보여주는 YAML 예시를 최소 하나 이상 추가.
- spec:inputs:description로 컴포넌트가 사용하는 변수나 시크릿을 문서화.
- README에서 입력 문서를 중복하지 마세요. inputs는 컴포넌트 페이지에 자동으로 표시됩니다. 대신 게시된 컴포넌트로 링크하세요.
기여를 환영한다면 ## 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를 참고하세요.

컴포넌트 테스트 (Test the component)

개발 워크플로우의 일부로 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들이 통과하면 릴리스를 만듭니다.

[!NOTE] 프로젝트가 프라이빗이라면 인증이 필요해요.

샘플 파일로 컴포넌트 테스트 (Test a component against sample files)

어떤 경우에는 컴포넌트가 상호작용할 소스 파일을 필요로 합니다. 예를 들어 Go 소스를 빌드하는 컴포넌트는 테스트할 Go 샘플이 필요할 가능성이 높고, Docker 이미지를 빌드하는 컴포넌트는 테스트할 샘플 Dockerfile이 필요해요. 이런 샘플 파일을 컴포넌트 프로젝트에 직접 포함해서 컴포넌트 테스트에 사용할 수 있어요. 자세한 내용은 컴포넌트 테스트 예시를 참고하세요.

인스턴스·프로젝트별 값 하드코딩 피하기 (Avoid hard-coding instance or project-specific values)

컴포넌트에서 다른 컴포넌트를 사용할 때는 인스턴스의 FQDN(예: gitlab.com) 대신 $CI_SERVER_FQDN을 쓰세요. 컴포넌트에서 GitLab API에 접근할 때는 인스턴스의 전체 URL·경로(예: https://gitlab.com/api/v4) 대신 $CI_API_V4_URL을 사용하세요. 이 사전 정의 변수들은 컴포넌트가 다른 인스턴스에서도 동작하도록 보장해요. 예를 들어 GitLab Self-Managed 인스턴스에서 GitLab.com 컴포넌트를 사용할 수 있습니다.

API 리소스가 항상 공개라고 가정하지 않기 (Do not assume API resources are always public)

컴포넌트와 그 테스트 파이프라인이 GitLab Self-Managed에서도 동작하는지 확인하세요. GitLab.com의 공개 프로젝트 일부 API 리소스는 인증 없이 접근할 수 있어요. 하지만 GitLab Self-Managed 인스턴스에서는 컴포넌트 프로젝트가 프라이빗이나 인터널 프로젝트로 미러링될 수 있습니다. GitLab Self-Managed 인스턴스에서 요청 인증을 위해 inputs나 변수로 액세스 토큰을 선택적으로 제공할 수 있게 하는 것이 중요해요.

전역 키워드 사용 피하기 (Avoid using global keywords)

컴포넌트에서 전역 키워드 사용을 피하세요. 컴포넌트에서 이 키워드를 쓰면 메인 .gitlab-ci.yml에 직접 정의된 job이나 다른 include된 컴포넌트의 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/

하드코딩된 값을 inputs로 바꾸기 (Replace hardcoded values with inputs)

CI/CD 컴포넌트에서 하드코딩된 값 사용을 피하세요. 하드코딩된 값은 컴포넌트 사용자가 컴포넌트의 내부 세부 사항을 검토하고 컴포넌트와 동작하도록 파이프라인을 적응시켜야 할 수 있어요. 문제가 되는 하드코딩 값이 많은 키워드는 stage예요. 컴포넌트 job의 스테이지가 하드코딩되어 있다면 컴포넌트를 쓰는 모든 파이프라인이 정확히 같은 스테이지를 정의하거나 구성을 덮어써야 합니다. 선호하는 방법은 동적 컴포넌트 구성을 위해 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/[email protected]
    inputs:
      stage: verify

job 이름을 inputs로 정의하기 (Define job names with inputs)

stage 키워드의 값과 비슷하게 CI/CD 컴포넌트에서 job 이름도 하드코딩하지 않는 게 좋아요. 컴포넌트 사용자가 job 이름을 커스터마이즈할 수 있으면 파이프라인의 기존 이름과 충돌을 막을 수 있어요. 사용자는 다른 이름을 써서 같은 컴포넌트를 다른 입력 옵션으로 여러 번 include할 수도 있습니다. inputs를 사용해 컴포넌트 사용자가 특정 job 이름이나 job 이름의 접두사를 정의하도록 하세요. 예를 들면 이렇습니다.

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 변수를 inputs로 바꾸기 (Replace custom CI/CD variables with inputs)

컴포넌트에서 CI/CD 변수를 쓸 때는 inputs 키워드를 대신 써야 할지 평가하세요. inputs가 더 나은 해결책일 때 사용자가 컴포넌트를 구성하도록 사용자 지정 변수를 정의하라고 요구하는 걸 피하세요. inputs는 컴포넌트의 spec 섹션에 명시적으로 정의되고 변수보다 더 나은 검증을 가져요. 예를 들어 필수 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/[email protected]
    inputs:
      scanner-output: yaml

다른 경우에는 CI/CD 변수가 여전히 더 나을 수 있어요. 예를 들어:

사전 정의 변수를 사용해서 컴포넌트가 사용자의 프로젝트에 맞게 자동으로 구성되도록 하기.
사용자에게 프로젝트 설정에서 민감한 값을 마스킹·보호된 CI/CD 변수로 저장하도록 요청하기.

CI/CD Catalog

CI/CD Catalog는 CI/CD 워크플로우를 확장하는 데 쓸 수 있는 게시된 CI/CD 컴포넌트가 있는 프로젝트 목록이에요. 누구나 컴포넌트 프로젝트를 만들고 CI/CD 카탈로그에 추가하거나, 기존 프로젝트에 기여해서 가용한 컴포넌트를 개선할 수 있습니다.

CI/CD 카탈로그 보기 (View the CI/CD Catalog)

CI/CD 카탈로그에 접근해서 사용 가능한 게시된 컴포넌트를 보려면:

상단 바에서 Search or go to를 선택합니다.
Explore를 선택합니다.
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 카탈로그 프로젝트는 사용 횟수(usage count)를 표시해요. 이 수는 지난 30일 동안 카탈로그 프로젝트의 어떤 컴포넌트를 파이프라인에서 사용한 고유 프로젝트의 총 수를 나타냅니다.

CI/CD 카탈로그 프로젝트 분석 보기 (View CI/CD Catalog project analytics)

GitLab 18.9에서 도입.

CI/CD 카탈로그 리소스를 유지 관리한다면 사용 분석을 봐서 컴포넌트가 프로젝트 전반에서 어떻게 채택되고 있는지 이해할 수 있어요.

사전 요구사항:

하나 이상의 카탈로그 리소스 프로젝트에 대해 Maintainer 또는 Owner 역할이 있어야 해요.

카탈로그 리소스 분석을 보려면:

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

Analytics 보기는 Maintainer 또는 Owner 역할을 가진 카탈로그 리소스를 표시해요. 이 보기에는:

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

이 정보로:

어떤 카탈로그 리소스가 가장 널리 채택됐는지 식별.
컴포넌트의 시간에 따른 사용 추세 추적.
어떤 프로젝트가 카탈로그 리소스를 쓰는지 이해.
컴포넌트 유지 보수와 폐기에 대한 정보에 입각한 결정.

컴포넌트 사용 세부 사항 보기 (View component usage details)

GitLab 19.0에서 도입.

CI/CD 카탈로그 컴포넌트 프로젝트를 유지 관리한다면 상세 컴포넌트 사용 정보를 봐서 어떤 프로젝트가 컴포넌트를 쓰고 어떤 버전을 쓰는지 이해할 수 있어요. 이는 업그레이드 계획, 폐기 공지, 최신 버전이 아닌 버전을 쓰는 프로젝트 식별에 도움이 됩니다. 상세 페이지는 각 컴포넌트 이름 옆에 사용 횟수도 표시해요. 이 수는 버전별이며 지난 30일 동안 해당 컴포넌트 버전을 사용한 고유 프로젝트 수를 보여줍니다.

사전 요구사항:

카탈로그 리소스 프로젝트에 대해 Maintainer 또는 Owner 역할이 있어야 해요.

컴포넌트 사용 세부 사항을 보려면:

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

이 탭은 지난 30일 동안 이 프로젝트의 어떤 컴포넌트를 파이프라인에 include한 프로젝트를 나열해요. 목록에는 여러분이 볼 권한이 있는 프로젝트만 포함됩니다. 세부 사항은:

Project path: 프로젝트의 전체 경로와 프로젝트 링크.
Status: 프로젝트가 컴포넌트 최신 버전을 쓰면 Up to date로 표시되고, 그렇지 않으면 Outdated입니다.
Components used: 프로젝트가 사용한 컴포넌트의 이름과 버전.

여러분에게 보이지 않는 프로젝트는 링크 없는 Private project로 표시됩니다. 이 정보로:

최신 버전이 아닌 컴포넌트 버전을 쓰고 업그레이드가 필요한 프로젝트 식별.
새 버전이 나왔거나 컴포넌트를 폐기할 때 프로젝트 관리자에게 알림.
조직 전체에서 특정 컴포넌트 버전의 채택 이해.

컴포넌트 프로젝트 게시 (Publish a component project)

컴포넌트 프로젝트를 CI/CD 카탈로그에 게시하려면:

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

컴포넌트 프로젝트를 카탈로그 프로젝트로 설정 (Set a component project as a catalog project)

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

사전 요구사항:

프로젝트에 대한 Owner 역할이 있어야 해요.

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

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

프로젝트는 새 릴리스를 게시한 뒤에만 카탈로그에서 찾을 수 있어요. 이 설정을 자동화하려면 mutationcatalogresourcescreate GraphQL 엔드포인트를 쓸 수 있습니다. 이슈 463043에서 REST API로도 노출하는 것을 제안하고 있어요.

새 릴리스 게시 (Publish a new release)

CI/CD 컴포넌트는 CI/CD 카탈로그에 등록되지 않아도 사용할 수 있어요. 하지만 카탈로그에 컴포넌트의 릴리스를 게시하면 다른 사용자에게 검색 가능해집니다.

사전 요구사항:

프로젝트에 대해 Maintainer 또는 Owner 역할이 있어야 해요.
프로젝트는:
- 카탈로그 프로젝트로 설정되어야 하고.
- 프로젝트 설명이 정의되어야 하고.
- 릴리스되는 태그의 커밋 SHA에 대한 루트 디렉터리 README.md 파일이 있어야 하고.
- 릴리스되는 태그의 커밋 SHA에 대한 templates/ 디렉터리에 CI/CD 컴포넌트가 최소 하나 있어야 해요.
릴리스를 만들려면 Releases API가 아니라 CI/CD job의 release 키워드를 사용해야 해요.

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

태그가 생성될 때 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"

릴리스용 새 태그를 만듭니다. 이 태그는 릴리스를 만드는 job이 포함된 태그 파이프라인을 트리거해야 해요. 태그는 시맨틱 버전을 사용해야 합니다.

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

시맨틱 버전 (Semantic versioning)

컴포넌트의 새 버전을 태깅하고 릴리스할 때는 시맨틱 버전을 사용해야 해요. 시맨틱 버전은 변경이 메이저, 마이너, 패치 또는 다른 종류의 변경인지 전달하는 표준입니다. 예를 들어 1.0.0, 2.3.4, 1.0.0-alpha는 모두 유효한 시맨틱 버전이에요.

컴포넌트 프로젝트 게시 취소 (Unpublish a component project)

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

[!WARNING] 이 동작은 카탈로그에 게시된 컴포넌트 프로젝트와 그 버전에 대한 메타데이터를 파괴해요. 프로젝트와 그 저장소는 여전히 존재하지만 카탈로그에는 보이지 않습니다.

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

검증된 컴포넌트 작성자 (Verified component creators)

GitLab 16.11에서 GitLab.com에 도입.
GitLab 18.1에서 GitLab Self-Managed와 GitLab Dedicated에 도입.

일부 CI/CD 컴포넌트는 검증 아이콘을 표시해요. 이 아이콘은 컴포넌트가 GitLab 또는 인스턴스 관리자가 검증한 사용자가 만들고 유지 관리한다는 것을 나타냅니다.

GitLab-maintained: GitLab이 만들고 유지 관리하는 GitLab.com 컴포넌트.
GitLab Partner: GitLab이 검증한 파트너가 독립적으로 만들고 유지 관리하는 GitLab.com 컴포넌트. GitLab 파트너는 GitLab Partner Alliance 멤버에게 연락해서 GitLab.com의 네임스페이스를 GitLab-검증으로 표시할 수 있어요. 그러면 네임스페이스에 있는 모든 CI/CD 컴포넌트가 GitLab Partner 컴포넌트로 배지됩니다. Partner Alliance 멤버는 검증된 파트너를 대신해 내부 요청 이슈(GitLab 팀 멤버 전용)를 만듭니다.

GitLab Partner가 만든 컴포넌트는 있는 그대로(as-is) 제공되며 어떤 종류의 보증도 없어요. 최종 사용자가 GitLab Partner가 만든 컴포넌트를 쓰는 것은 본인 책임이며, 컴포넌트 사용에 대해 GitLab은 배상 의무도 그 어떤 유형의 책임도 지지 않습니다. 최종 사용자의 콘텐츠 사용과 그에 따른 책임은 콘텐츠 발행자와 최종 사용자 사이의 문제입니다.

Verified creator: 관리자가 검증한 사용자가 만들고 유지 관리하는 컴포넌트.

컴포넌트를 검증된 작성자 유지 관리로 설정 (Set a component as maintained by a verified creator)

GitLab 18.1에서 GitLab Self-Managed와 GitLab Dedicated에 도입.

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

관리자 계정으로 인스턴스에서 GraphiQL을 엽니다. 예: https://gitlab.example.com/-/graphql-explorer.
root-level-group을 검증할 컴포넌트의 루트 네임스페이스로 바꿔 이 쿼리를 실행합니다.

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

쿼리가 완료되면 루트 네임스페이스의 프로젝트에 있는 모든 컴포넌트가 검증됩니다. Verified creator 배지가 CI/CD 카탈로그의 컴포넌트 이름 옆에 표시됩니다. 컴포넌트에서 배지를 제거하려면 verificationLevel을 UNVERIFIED로 두고 쿼리를 반복하세요.

CI/CD 템플릿을 컴포넌트로 변환 (Convert a CI/CD template to a component)

include: 문법으로 프로젝트에서 쓰는 기존 CI/CD 템플릿은 어떤 것이든 CI/CD 컴포넌트로 변환할 수 있어요.

컴포넌트를 기존 컴포넌트 프로젝트의 일부로 다른 컴포넌트와 그룹핑할지, 새 컴포넌트 프로젝트를 만들지 결정합니다.
디렉터리 구조에 따라 컴포넌트 프로젝트에 YAML 파일을 만듭니다.
원래 템플릿 YAML 파일의 내용을 새 컴포넌트 YAML 파일로 복사합니다.
새 컴포넌트의 구성을 리팩터링해서:
- 컴포넌트 작성 가이드를 따릅니다.
- 예를 들어 MR 파이프라인을 활성화하거나 더 효율적으로 만드는 등 구성을 개선합니다.
컴포넌트 저장소의 .gitlab-ci.yml을 활용해 컴포넌트의 변경을 테스트합니다.
태그를 달고 컴포넌트를 릴리스합니다.

Go CI/CD 템플릿을 CI/CD 컴포넌트로 마이그레이션의 실제 예시를 따라가며 더 배울 수 있어요.

GitLab Self-Managed에서 GitLab.com 컴포넌트 사용 (Use a GitLab.com component on GitLab Self-Managed)

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

새로 설치한 GitLab 인스턴스의 CI/CD 카탈로그는 게시된 CI/CD 컴포넌트가 없는 상태로 시작해요. 인스턴스의 카탈로그를 채우려면:

자체 컴포넌트를 게시하거나.
GitLab Self-Managed 인스턴스에 GitLab.com 컴포넌트를 미러링.

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

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

CI/CD 컴포넌트 보안 모범 사례 (CI/CD component security best practices)

컴포넌트 사용자에게 (For component users)

누구나 카탈로그에 컴포넌트를 게시할 수 있으므로, 프로젝트에 사용하기 전에 컴포넌트를 주의 깊게 검토하세요. GitLab CI/CD 컴포넌트의 사용은 본인 책임이며, GitLab은 서드파티 컴포넌트의 보안을 보장할 수 없습니다. 서드파티 CI/CD 컴포넌트를 사용할 때 다음 보안 모범 사례를 고려하세요.

컴포넌트 소스 코드 감사·검토: 악성 콘텐츠가 없는지 코드를 주의 깊게 검토.
자격 증명·토큰 접근 최소화:
- 자격 증명이나 토큰이 기대하고 승인한 작업에만 사용되는지 컴포넌트 소스 코드를 감사.
- 최소 스코프의 액세스 토큰 사용.
- 장기 액세스 토큰이나 자격 증명 사용 회피.
- CI/CD 컴포넌트가 사용하는 자격 증명·토큰 사용을 감사.
고정 버전 사용: 파이프라인에서 사용하는 컴포넌트의 무결성을 보장하려면 컴포넌트를 특정 커밋 SHA(권장) 또는 릴리스 버전 태그에 고정. 컴포넌트 유지 관리자를 신뢰하는 경우에만 릴리스 태그를 사용하고, latest 사용은 피하세요.
시크릿 안전하게 보관: CI/CD 구성 파일에 시크릿을 저장하지 마세요. 외부 시크릿 관리 솔루션을 쓸 수 있다면 프로젝트 설정에 시크릿·자격 증명을 저장하지 말아야 해요.
일시적·격리된 러너 환경 사용: 가능하면 임시·격리된 환경에서 컴포넌트 job을 실행하세요. 자체 관리 러너의 보안 위험을 인지하세요.
캐시·artifact 안전하게 처리: 절대적으로 필요하지 않다면 파이프라인의 다른 job에서 CI/CD 컴포넌트 job으로 캐시나 artifact를 전달하지 마세요.
CI_JOB_TOKEN 접근 제한: CI/CD 컴포넌트를 사용하는 프로젝트에 대해 CI/CD job token(CI_JOB_TOKEN) 프로젝트 접근·권한을 제한하세요.
CI/CD 컴포넌트 변경 검토: 컴포넌트의 업데이트된 커밋 SHA나 릴리스 태그로 변경하기 전에 CI/CD 컴포넌트 구성의 모든 변경을 주의 깊게 검토.
사용자 지정 컨테이너 이미지 감사: CI/CD 컴포넌트가 사용하는 사용자 지정 컨테이너 이미지에 악성 콘텐츠가 없는지 주의 깊게 검토.

컴포넌트 유지 관리자에게 (For component maintainers)

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

2단계 인증(2FA) 사용: 모든 CI/CD 컴포넌트 프로젝트 유지 관리자·소유자가 2FA를 활성화하거나, 그룹의 모든 사용자에게 2FA를 적용하세요.
보호된 브랜치 사용:
- 컴포넌트 프로젝트 릴리스에 보호된 브랜치를 사용.
- 기본 브랜치를 보호하고, 와일드카드 규칙으로 모든 릴리스 브랜치를 보호.
- 모든 사람이 보호된 브랜치의 변경에 MR을 제출하도록 요구. 보호된 브랜치의 Allowed to push and merge 옵션을 No one으로 설정.
- 보호된 브랜치에 대한 강제 푸시(force push) 차단.
모든 커밋 서명: 컴포넌트 프로젝트에 대한 모든 커밋을 서명하세요.
latest 사용 권장하지 않기: README.md에서 @latest를 쓰는 예시를 포함하지 마세요.
다른 job의 캐시·artifact 의존성 제한: 절대적으로 필요할 때만 CI/CD 컴포넌트에서 다른 job의 캐시와 artifact를 사용하세요.
CI/CD 컴포넌트 의존성 업데이트: 의존성 업데이트를 정기적으로 확인하고 적용.
변경 신중히 검토:
- 기본 또는 릴리스 브랜치에 병합하기 전에 CI/CD 컴포넌트 파이프라인 구성의 모든 변경을 주의 깊게 검토.
- 사용자에게 보이는 CI/CD 컴포넌트 카탈로그 프로젝트의 모든 변경에 MR 승인 사용.

트러블슈팅 (Troubleshooting)

`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 섹션으로 인해 발생할 수 있어요. 구성이 inputs를 사용하지 않는다면 spec 섹션을 대신 비워 둘 수 있습니다. 예를 들면 이렇습니다.

spec:
---

my-component:
  script: echo

더 알아보기

컴포넌트는 재사용 가능한 파이프라인 구성 단위로, inputs를 통한 동적 구성과 카탈로그를 통한 버전 관리가 핵심이에요. 컴포넌트를 만들 때는 전역 키워드를 피하고 하드코딩된 값을 inputs로 바꾸는 등 모범 사례를 따르세요. 사용자 입장에서는 신뢰할 수 있는 깊이 알지 못하는 컴포넌트의 소스 코드를 감사하고 버전을 고정해서 쓰는 게 안전합니다.

CI/CD 컴포넌트

CI/CD 컴포넌트 (CI/CD components)

본문

컴포넌트 프로젝트 (Component project)

컴포넌트 프로젝트 만들기 (Create a component project)

디렉터리 구조 (Directory structure)

컴포넌트 사용 (Use a component)

컴포넌트 버전 (Component versions)

부분 시맨틱 버전 (Partial semantic versions)

컴포넌트에서 컴포넌트 컨텍스트 사용 (Use component context in components)

컴포넌트 spec 섹션 (Component spec section)

컴포넌트 작성 (Write a component)

의존성 관리 (Manage dependencies)

명확한 README.md 작성 (Write a clear README.md)

컴포넌트 테스트 (Test the component)

샘플 파일로 컴포넌트 테스트 (Test a component against sample files)

인스턴스·프로젝트별 값 하드코딩 피하기 (Avoid hard-coding instance or project-specific values)

API 리소스가 항상 공개라고 가정하지 않기 (Do not assume API resources are always public)

전역 키워드 사용 피하기 (Avoid using global keywords)

하드코딩된 값을 inputs로 바꾸기 (Replace hardcoded values with inputs)

job 이름을 inputs로 정의하기 (Define job names with inputs)

사용자 지정 CI/CD 변수를 inputs로 바꾸기 (Replace custom CI/CD variables with inputs)

CI/CD Catalog

CI/CD 카탈로그 보기 (View the CI/CD Catalog)

CI/CD 카탈로그 프로젝트 분석 보기 (View CI/CD Catalog project analytics)

컴포넌트 사용 세부 사항 보기 (View component usage details)

컴포넌트 프로젝트 게시 (Publish a component project)

컴포넌트 프로젝트를 카탈로그 프로젝트로 설정 (Set a component project as a catalog project)

새 릴리스 게시 (Publish a new release)

시맨틱 버전 (Semantic versioning)

컴포넌트 프로젝트 게시 취소 (Unpublish a component project)

검증된 컴포넌트 작성자 (Verified component creators)

컴포넌트를 검증된 작성자 유지 관리로 설정 (Set a component as maintained by a verified creator)

CI/CD 템플릿을 컴포넌트로 변환 (Convert a CI/CD template to a component)

GitLab Self-Managed에서 GitLab.com 컴포넌트 사용 (Use a GitLab.com component on GitLab Self-Managed)

CI/CD 컴포넌트 보안 모범 사례 (CI/CD component security best practices)

컴포넌트 사용자에게 (For component users)

컴포넌트 유지 관리자에게 (For component maintainers)

트러블슈팅 (Troubleshooting)

content not found 메시지

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

더 알아보기

컴포넌트 `spec` 섹션 (Component `spec` section)

명확한 `README.md` 작성 (Write a clear `README.md`)

`content not found` 메시지

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