이 기능은 GitLab 17.3에서 deprecated되었으며 20.0에서 제거될 예정입니다. 대신 파이프라인 실행 정책 유형을 사용하세요. 이 변경은 호환성이 깨지는 변경(breaking change)입니다. 자세한 내용은 마이그레이션 가이드를 참조하세요.

그룹 Owner는 다른 프로젝트와 별도의 프로젝트에서 컴플라이언스 파이프라인을 구성할 수 있습니다. 기본적으로 컴플라이언스 파이프라인 구성(예: .compliance-gitlab-ci.yml)은 라벨이 지정된 프로젝트의 파이프라인 구성(예: .gitlab-ci.yml) 대신 실행됩니다.

단, 컴플라이언스 파이프라인 구성은 라벨이 지정된 프로젝트의 .gitlab-ci.yml 파일을 참조할 수 있어 다음이 가능합니다:

• 컴플라이언스 파이프라인이 라벨이 지정된 프로젝트 파이프라인의 job도 실행할 수 있습니다. 이를 통해 파이프라인 구성을 중앙에서 제어할 수 있습니다.

• 컴플라이언스 파이프라인에서 정의된 job과 변수는 라벨이 지정된 프로젝트의 .gitlab-ci.yml 파일에 있는 변수로 변경할 수 없습니다.

알려진 이슈로 인해, 프로젝트가 다운스트림에서 설정을 재정의하지 않도록 프로젝트 파이프라인을 컴플라이언스 파이프라인 구성의 맨 위에 먼저 포함해야 합니다.

자세한 내용은 다음을 참조하세요:

• 라벨이 지정된 프로젝트 파이프라인 구성에서 job을 실행하는 컴플라이언스 파이프라인 구성에 대한 도움말은 구성 예시를 참조하세요.

• 컴플라이언스 파이프라인 만들기 튜토리얼을 참조하세요.

파이프라인 실행 정책 마이그레이션#

파이프라인 실행 정책은 스캔 및 파이프라인 적용을 통합하고 단순화하는 것을 목표로 합니다. 컴플라이언스 파이프라인은 GitLab 17.3에서 deprecated되었으며 GitLab 19.0에서 제거될 예정입니다.

파이프라인 실행 정책은 파이프라인 실행 정책에 연결된 별도의 YAML 파일 (예: pipeline-execution.yml)에 제공된 구성으로 프로젝트의 .gitlab-ci.yml 파일을 확장합니다.

기본적으로 새 컴플라이언스 프레임워크를 만들 때 컴플라이언스 파이프라인 대신 파이프라인 실행 정책 유형을 사용하도록 안내됩니다.

기존 컴플라이언스 파이프라인은 마이그레이션해야 합니다. 고객은 가능한 한 빨리 컴플라이언스 파이프라인에서 새로운 파이프라인 실행 정책 유형으로 마이그레이션해야 합니다.

기존 컴플라이언스 프레임워크 마이그레이션#

기존 컴플라이언스 프레임워크를 파이프라인 실행 정책 유형을 사용하도록 마이그레이션하려면:

• 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.

• 왼쪽 사이드바에서 Secure > Compliance center를 선택합니다.

• 기존 컴플라이언스 프레임워크를 편집합니다.

• 표시되는 배너에서 Migrate pipeline to a policy를 선택하여 보안 정책에 새 정책을 만듭니다.

• 컴플라이언스 프레임워크를 다시 편집하여 컴플라이언스 파이프라인을 제거합니다.

자세한 내용은 보안 정책 프로젝트를 참조하세요.

마이그레이션 중 Pipeline execution policy error: Job names must be unique 오류가 발생하면 관련 문제 해결 정보를 참조하세요.

라벨이 지정된 프로젝트에 대한 영향#

사용자는 컴플라이언스 파이프라인이 구성되어 있다는 것을 알 방법이 없으므로, 자신의 파이프라인이 전혀 실행되지 않거나 자신이 정의하지 않은 job이 포함되어 있는 이유에 대해 혼란스러울 수 있습니다.

라벨이 지정된 프로젝트에서 파이프라인을 작성할 때 컴플라이언스 파이프라인이 구성되어 있다는 표시가 없습니다. 프로젝트 수준에서 유일한 표시는 컴플라이언스 프레임워크 라벨 자체이지만, 라벨은 프레임워크에 컴플라이언스 파이프라인이 구성되어 있는지 여부를 나타내지 않습니다.

따라서 불확실성과 혼란을 줄이기 위해 컴플라이언스 파이프라인 구성에 대해 프로젝트 사용자와 소통하세요.

복수의 컴플라이언스 프레임워크#

컴플라이언스 파이프라인이 구성된 단일 프로젝트에 여러 컴플라이언스 프레임워크를 적용할 수 있습니다. 이 경우 프로젝트에 처음 적용된 컴플라이언스 프레임워크의 컴플라이언스 파이프라인만 프로젝트 파이프라인에 포함됩니다.

프로젝트에 올바른 컴플라이언스 파이프라인이 포함되도록 하려면:

• 프로젝트에서 모든 컴플라이언스 프레임워크를 제거합니다.

• 올바른 컴플라이언스 파이프라인이 있는 컴플라이언스 프레임워크를 프로젝트에 적용합니다.

• 프로젝트에 추가 컴플라이언스 프레임워크를 적용합니다.

컴플라이언스 파이프라인 구성#

히스토리

• GitLab 15.11에서 도입됨, 컴플라이언스 프레임워크가 컴플라이언스 센터로 이동됨.

컴플라이언스 파이프라인을 구성하려면:

• 상단 바에서 Search or go to를 선택하고 그룹을 찾습니다.

• 왼쪽 사이드바에서 Secure > Compliance center를 선택합니다.

• Frameworks 섹션을 선택합니다.

• New framework 섹션을 선택하고, 컴플라이언스 프레임워크 구성 경로를 포함한 컴플라이언스 프레임워크 정보를 추가합니다. path/file.y[a]ml@group-name/project-name 형식을 사용하세요. 예를 들어:

.compliance-ci.yml@gitlab-org/gitlab.

• .compliance-ci.yaml@gitlab-org/gitlab.

이 구성은 컴플라이언스 프레임워크 라벨이 적용된 프로젝트에 상속됩니다. 컴플라이언스 프레임워크 라벨이 적용된 프로젝트에서는 라벨이 지정된 프로젝트 자체의 파이프라인 구성 대신 컴플라이언스 파이프라인 구성이 실행됩니다.

라벨이 지정된 프로젝트에서 파이프라인을 실행하는 사용자는 컴플라이언스 프로젝트에 대해 최소한 Reporter 권한이 있어야 합니다.

스캔 실행을 강제하는 데 사용할 경우, 이 기능은 스캔 실행 정책과 일부 중복됩니다. 이 두 기능에 대한 사용자 경험은 아직 통합되지 않았습니다.

중요 고려 사항#

동일한 프로젝트에서 기존 컴플라이언스 파이프라인을 마이그레이션하기 전까지 파이프라인 실행 정책을 활성화하지 마세요. 두 가지가 모두 구성된 경우, 컴플라이언스 파이프라인은 표준 프로젝트 파이프라인을 대체하지만 파이프라인 실행 정책은 원래 프로젝트 파이프라인을 기반으로 적용됩니다. 이로 인해 파이프라인 실행 정책 전략과 CI/CD 구성에 따라 달라지는 예측 불가능한 동작이 발생하며, job 중복, 파이프라인 실패, 또는 중요한 보안 및 컴플라이언스 검사 누락이 발생할 수 있습니다. 컴플라이언스 파이프라인은 deprecated 상태입니다. 가능한 한 빨리 기존 컴플라이언스 파이프라인을 마이그레이션하고, 모든 새 구현에는 파이프라인 실행 정책을 사용하세요.

구성 예시#

다음 예시 .compliance-gitlab-ci.yml은 라벨이 지정된 프로젝트 파이프라인 구성도 실행되도록 include 키워드를 포함합니다.

include:  # Execute individual project's configuration (if project contains .gitlab-ci.yml)
  - project: '$CI_PROJECT_PATH'
    file: '$CI_CONFIG_PATH'
    ref: '$CI_COMMIT_SHA' # Must be defined or MR pipelines always use the use default branch
    rules:
      - if: $CI_PROJECT_PATH != "my-group/project-1" # Must run on projects other than the one hosting this configuration.

# Allows compliance team to control the ordering and interweaving of stages/jobs.
# Stages without jobs defined will remain hidden.
stages:
  - pre-compliance
  - build
  - test
  - pre-deploy-compliance
  - deploy
  - post-compliance

variables:  # Can be overridden by setting a job-specific variable in project's local .gitlab-ci.yml
  FOO: sast

sast:  # None of these attributes can be overridden by a project's local .gitlab-ci.yml
  variables:
    FOO: sast
  image: ruby:2.6
  stage: pre-compliance
  rules:
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS && $CI_PIPELINE_SOURCE == "push"
      when: never
    - when: always  # or when: on_success
  allow_failure: false
  before_script:
    - "# No before scripts."
  script:
    - echo "running $FOO"
  after_script:
    - "# No after scripts."

sanity check:
  image: ruby:2.6
  stage: pre-deploy-compliance
  rules:
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS && $CI_PIPELINE_SOURCE == "push"
      when: never
    - when: always  # or when: on_success
  allow_failure: false
  before_script:
    - "# No before scripts."
  script:
    - echo "running $FOO"
  after_script:
    - "# No after scripts."

audit trail:
  image: ruby:2.7
  stage: post-compliance
  rules:
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS && $CI_PIPELINE_SOURCE == "push"
      when: never
    - when: always  # or when: on_success
  allow_failure: false
  before_script:
    - "# No before scripts."
  script:
    - echo "running $FOO"
  after_script:
    - "# No after scripts."

include 정의의 rules 구성은 컴플라이언스 파이프라인이 호스트 프로젝트 자체에서 실행되어야 하는 경우 순환 포함을 방지합니다. 컴플라이언스 파이프라인이 라벨이 지정된 프로젝트에서만 실행된다면 이 설정을 생략할 수 있습니다.

외부에서 호스팅된 커스텀 파이프라인 구성과 컴플라이언스 파이프라인#

이전 예시는 모든 프로젝트가 동일한 프로젝트에 파이프라인 구성을 호스팅한다고 가정합니다. 외부에서 호스팅된 구성을 사용하는 프로젝트가 있으면 예시 구성이 작동하지 않습니다. 자세한 내용은 이슈 393960을 참조하세요.

외부에서 호스팅된 구성을 사용하는 프로젝트의 경우 다음 해결 방법을 시도해 볼 수 있습니다:

• 예시 컴플라이언스 파이프라인 구성의 include 섹션을 조정해야 합니다. 예를 들어, include:rules를 사용하여:

include:
  # If the custom path variables are defined, include the project's external config file.
  - project: '$PROTECTED_PIPELINE_CI_PROJECT_PATH'
    file: '$PROTECTED_PIPELINE_CI_CONFIG_PATH'
    ref: '$PROTECTED_PIPELINE_CI_REF'
    rules:
      - if: $PROTECTED_PIPELINE_CI_PROJECT_PATH && $PROTECTED_PIPELINE_CI_CONFIG_PATH && $PROTECTED_PIPELINE_CI_REF
  # If any custom path variable is not defined, include the project's internal config file as normal.
  - project: '$CI_PROJECT_PATH'
    file: '$CI_CONFIG_PATH'
    ref: '$CI_COMMIT_SHA'
    rules:
      - if: $PROTECTED_PIPELINE_CI_PROJECT_PATH == null || $PROTECTED_PIPELINE_CI_CONFIG_PATH == null || $PROTECTED_PIPELINE_CI_REF == null

• 외부 파이프라인 구성을 사용하는 프로젝트에 CI/CD 변수를 추가해야 합니다. 이 예시에서:

PROTECTED_PIPELINE_CI_PROJECT_PATH: 구성 파일을 호스팅하는 프로젝트 경로, 예: group/subgroup/project.

• PROTECTED_PIPELINE_CI_CONFIG_PATH: 프로젝트 내 구성 파일 경로, 예: path/to/.gitlab-ci.yml.

• PROTECTED_PIPELINE_CI_REF: 구성 파일을 가져올 때 사용할 ref, 예: main.

프로젝트 포크에서 생성된 머지 리퀘스트의 컴플라이언스 파이프라인#

머지 리퀘스트가 포크에서 생성된 경우, 병합할 브랜치는 일반적으로 포크에만 존재합니다. 컴플라이언스 파이프라인이 있는 프로젝트에 대해 이러한 머지 리퀘스트를 생성하면 이전 스니펫이 Project <project-name> reference <branch-name> does not exist! 오류 메시지와 함께 실패합니다. 이 오류는 타깃 프로젝트의 컨텍스트에서 $CI_COMMIT_REF_NAME이 존재하지 않는 브랜치 이름으로 평가되기 때문에 발생합니다.

올바른 컨텍스트를 얻으려면 $CI_PROJECT_PATH 대신 $CI_MERGE_REQUEST_SOURCE_PROJECT_PATH를 사용하세요. 이 변수는 머지 리퀘스트 파이프라인에서만 사용할 수 있습니다.

예를 들어, 프로젝트 포크에서 생성된 머지 리퀘스트 파이프라인과 브랜치 파이프라인을 모두 지원하는 구성을 위해서는 rules:if와 함께 두 include 지시문을 결합해야 합니다:

include:  # Execute individual project's configuration (if project contains .gitlab-ci.yml)
  - project: '$CI_MERGE_REQUEST_SOURCE_PROJECT_PATH'
    file: '$CI_CONFIG_PATH'
    ref: '$CI_COMMIT_REF_NAME'
    rules:
      - if: $CI_PIPELINE_SOURCE == 'merge_request_event'
  - project: '$CI_PROJECT_PATH'
    file: '$CI_CONFIG_PATH'
    ref: '$CI_COMMIT_REF_NAME'
    rules:
      - if: $CI_PIPELINE_SOURCE != 'merge_request_event'

구성 파일이 없는 프로젝트의 컴플라이언스 파이프라인#

구성 예시는 모든 프로젝트에 파이프라인 구성 파일(기본적으로 .gitlab-ci.yml)이 있다고 가정합니다. 그러나 구성 파일이 없는 프로젝트 (따라서 기본적으로 파이프라인이 없는 프로젝트)에서는 include:project에 지정된 파일이 필수이므로 컴플라이언스 파이프라인이 실패합니다.

타깃 프로젝트에 구성 파일이 있는 경우에만 포함하려면 rules:exists:project를 사용하세요:

include:  # Execute individual project's configuration
  - project: '$CI_PROJECT_PATH'
    file: '$CI_CONFIG_PATH'
    ref: '$CI_COMMIT_SHA'
    rules:
      - exists:
          paths:
            - '$CI_CONFIG_PATH'
          project: '$CI_PROJECT_PATH'
          ref: '$CI_COMMIT_SHA'

이 예시에서는 주어진 ref에 대해 exists:project: $CI_PROJECT_PATH'의 프로젝트에 구성 파일이 존재하는 경우에만 포함됩니다.

exists:project가 컴플라이언스 파이프라인 구성에 지정되지 않으면 include가 정의된 프로젝트에서 파일을 검색합니다. 컴플라이언스 파이프라인에서 이전 예시의 include는 파이프라인을 실행하는 프로젝트가 아닌 컴플라이언스 파이프라인 구성 파일을 호스팅하는 프로젝트에 정의됩니다.

컴플라이언스 job이 항상 실행되도록 보장#

컴플라이언스 파이프라인은 GitLab CI/CD를 사용하여 원하는 모든 종류의 컴플라이언스 job을 정의할 수 있는 뛰어난 유연성을 제공합니다. 목표에 따라 이러한 job은 다음과 같이 구성할 수 있습니다:

• 사용자가 수정 가능.

• 수정 불가능.

일반적으로 컴플라이언스 job의 값이:

• 설정된 경우, 프로젝트 수준 구성으로 변경하거나 재정의할 수 없습니다.

• 설정되지 않은 경우, 프로젝트 수준 구성에서 설정할 수 있습니다.

어느 쪽이든 사용 사례에 따라 원하거나 원하지 않을 수 있습니다.

다음은 이러한 job이 항상 정의한 대로 정확히 실행되도록 하고 다운스트림의 프로젝트 수준 파이프라인 구성이 변경하지 못하도록 하기 위한 몇 가지 모범 사례입니다:

• 각 컴플라이언스 job에 rules:when:always 블록을 추가합니다. 이렇게 하면 수정이 불가능하고 항상 실행됩니다.

• job이 참조하는 모든 변수를 명시적으로 설정합니다. 이렇게 하면:

프로젝트 수준 파이프라인 구성이 변수를 설정하여 동작을 변경하지 않도록 합니다. 예를 들어, 구성 예시의 before_script 및 after_script 구성을 참조하세요.

• job 로직을 구동하는 모든 job을 포함합니다.

• job을 실행할 컨테이너 이미지를 명시적으로 설정합니다. 이렇게 하면 스크립트 단계가 올바른 환경에서 실행됩니다.

• 관련 GitLab 사전 정의 job 키워드를 명시적으로 설정합니다. 이렇게 하면 job이 의도한 설정을 사용하며 프로젝트 수준 파이프라인에 의해 재정의되지 않습니다.

문제 해결#

컴플라이언스 job이 타깃 리포지터리에 의해 덮어쓰여짐#

컴플라이언스 파이프라인 구성에서 extends 구문을 사용하면 타깃 리포지터리 job에 의해 컴플라이언스 job이 덮어쓰여집니다. 예를 들어, 다음과 같은 .compliance-gitlab-ci.yml 구성이 있을 수 있습니다:

"compliance job":
  extends:
    - .compliance_template
  stage: build

.compliance_template:
  script:
    - echo "take compliance action"

또한 다음과 같은 .gitlab-ci.yml 구성이 있을 수 있습니다:

"compliance job":
  stage: test
  script:
    - echo "overwriting compliance action"

이 구성으로 인해 타깃 리포지터리 파이프라인이 컴플라이언스 파이프라인을 덮어쓰며 다음 메시지가 출력됩니다: overwriting compliance action.

컴플라이언스 job이 덮어쓰여지지 않도록 하려면 컴플라이언스 파이프라인 구성에서 extends 키워드를 사용하지 마세요. 예를 들어, 다음과 같은 .compliance-gitlab-ci.yml 구성을 사용할 수 있습니다:

"compliance job":
  stage: build
  script:
    - echo "take compliance action"

또한 다음과 같은 .gitlab-ci.yml 구성이 있을 수 있습니다:

"compliance job":
  stage: test
  script:
    - echo "overwriting compliance action"

이 구성은 컴플라이언스 파이프라인을 덮어쓰지 않으며 다음 메시지가 출력됩니다: take compliance action.

사전 입력된 변수가 표시되지 않음#

알려진 이슈로 인해, GitLab 15.3 이상의 컴플라이언스 파이프라인은 파이프라인을 수동으로 시작할 때 사전 입력된 변수가 표시되지 않을 수 있습니다.

이 문제를 해결하려면 개별 프로젝트 구성을 실행하는 include: 구문에서 ref: '$CI_COMMIT_REF_NAME' 대신 ref: '$CI_COMMIT_SHA'를 사용하세요.

구성 예시는 이 변경 사항으로 업데이트되었습니다:

include:
  - project: '$CI_PROJECT_PATH'
    file: '$CI_CONFIG_PATH'
    ref: '$CI_COMMIT_SHA'

오류: Job 이름은 고유해야 합니다#

컴플라이언스 파이프라인을 구성하기 위해 구성 예시는 include.project를 사용하여 개별 프로젝트 구성을 포함하도록 권장합니다.

이 구성은 프로젝트 파이프라인을 실행할 때 오류를 발생시킬 수 있습니다: Pipeline execution policy error: Job names must be unique. 이 오류는 파이프라인 실행 정책이 프로젝트의 .gitlab-ci.yml을 포함하고 파이프라인에 이미 선언된 job에 삽입하려고 할 때 발생합니다.

이 오류를 해결하려면 파이프라인 실행 정책에 연결된 별도의 YAML 파일에서 include.project를 제거하세요.