코드 품질

티어: Free, Premium, Ultimate 제공: GitLab.com, 자체 관리, 전용 GitLab

소스 코드의 품질과 복잡성을 분석하는 데 코드 품질을 사용합니다. 이를 통해 프로젝트의 코드를 간단하고 가독성 있게 유지하고 유지 보수하기 쉽도록 합니다. 코드 품질은 기타 리뷰 프로세스를 보완하고 대체하지 않아야 합니다.

코드 품질은 CI/CD 파이프라인에서 실행되며 코드 품질을 저하시킬 수 있는 변경 사항이 병합되지 않도록 돕습니다.

코드 품질은 오픈 소스 코드 클라우드 도구 및 선택한 플러그인을 사용하여 소스 코드를 분석합니다. 코드의 언어가 지원되는지 확인하려면 Code Climate 유지 관리를 위한 지원되는 언어 목록을 참조하세요. 코드 커버리지를 늘리려면 코드 클라우드 분석 플러그인이나 사용자 지정 도구를 사용할 수 있습니다.

티어별 기능

다양한 GitLab 티어에서 사용 가능한 다른 기능은 다음 표와 같습니다:

기능 무료에서 사용 가능 프리미엄에서 사용 가능 얼티메이트에서 사용 가능
스캐너 구성 가능 가능 가능
사용자 지정 스캐너 통합 가능 가능 가능
JSON 또는 HTML 리포트 아티팩트 생성 가능 가능 가능
병합 요청 위젯의 결과 확인 가능 가능 가능
파이프라인의 결과 확인 불가능 가능 가능
병합 요청 변경 내용 뷰의 결과 확인 불가능 불가능 가능
프로젝트 품질 뷰의 요약 불가능 불가능 가능

코드 품질 결과 보기

코드 품질 결과는 다음에서 표시됩니다:

  • 병합 요청 위젯
  • 병합 요청 변경 내용 뷰
  • 파이프라인의 결과 뷰
  • 프로젝트 품질 뷰

병합 요청 위젯

코드 품질 분석 결과는 대상 브랜치의 보고서가 비교할 수 있는 경우 병합 요청 위젯 영역에 표시됩니다. 병합 요청 위젯에는 변경 사항으로 인해 발생한 코드 품질 결과 및 해결 방안이 표시됩니다. 동일한 지문을 가진 여러 코드 품질 결과는 병합 요청 위젯에서 단일 항목으로 표시됩니다. 각 개별 결과는 파이프라인 세부 정보 뷰에서 전체 보고서에서 확인할 수 있습니다.

코드 품질 위젯

병합 요청 변경 내용 뷰

티어: 얼티메이트 제공: GitLab.com, 자체 관리, 전용 GitLab

코드 품질 결과는 병합 요청 변경 뷰에 표시됩니다. 코드 품질 문제가 포함된 행은 좌측 라인 번호 옆에 기호로 표시됩니다. 해당 기호를 선택하여 문제 목록을 보고, 문제를 선택하여 세부 정보를 볼 수 있습니다.

코드 품질 인라인 지시자

파이프라인의 결과 뷰

티어: 프리미엄, 얼티메이트 제공: GitLab.com, 자체 관리, 전용 GitLab

파이프라인에서 생성된 코드 품질 위반 목록을 파이프라인의 세부 페이지의 코드 품질 탭에 표시됩니다. 파이프라인 세부 정보 뷰는 실행된 브랜치에서 찾은 모든 코드 품질 결과를 표시합니다.

코드 품질 리포트

프로젝트 품질 뷰

티어: 얼티메이트 제공: GitLab.com, 자체 관리 상태: 베타

프로젝트 품질 뷰는 코드 품질 결과의 개요를 표시합니다. 이 뷰는 분석 > CI/CD 분석에서 찾을 수 있으며, 특정 프로젝트에 대해이 기능 플래그를 활성화해야 합니다project_quality_summary_page.

코드 품질 요약

코드 품질 활성화

전제 조건:

  • GitLab CI/CD 구성 (.gitlab-ci.yml)에 test 단계를 포함해야 합니다.
  • 인스턴스 러너를 사용하는 경우, Code Quality 작업은 Docker-in-Docker workflow에 대해 구성되어야 합니다. 이 워크플로를 사용하는 경우 보고서를 저장할 수 있도록 /builds 볼륨을 매핑해야 합니다.
  • 개인 러너를 사용하는 경우, 코드 품질 분석을보다 효율적으로 실행하는 데 권장되는 대체 구성을 사용해야 합니다.
  • 러너에는 생성된 코드 품질 파일을 저장할 충분한 디스크 공간이 있어야 합니다. 예를 들어, GitLab 프로젝트의 파일은 약 7GB입니다.

코드 품질을 활성화하려면 다음 중 하나를 수행하십시오:

  • Auto DevOps를 활성화하여 Auto Code Quality를 포함시킵니다.

  • Code Quality 템플릿을 .gitlab-ci.yml 파일에 포함하세요.

    예시: 

       include:
   - template: Jobs/Code-Quality.gitlab-ci.yml

    이제 코드 품질이 파이프라인에서 실행됩니다.

경고: 자체 관리 인스턴스에서 악의적인 행위자가 Code Quality 작업 정의를 침해하면 러너 호스트에서 권한 있는 Docker 명령을 실행할 수 있습니다. 적절한 액세스 제어 정책이 있으면 신뢰된 사용자만 액세스할 수 있도록하여이 공격 경로를 완화할 수 있습니다. 

### 개인 러너로 코드 품질 성능 향상

개인 러너를 사용하는 경우 코드 품질의 성능을 향상시키기 위해 이 구성을 사용해야 합니다.
다음과 같은 이유로 개선된 성능을 얻을 수 있습니다:

- Privileged 모드를 사용하지 않음
- Docker-in-Docker를 사용하지 않음
- Docker 이미지(모든 CodeClimate 이미지 포함)가 캐시되어 이후 작업에서 다시 가져오지 않음

이 대체 구성은 소켓 바인딩을 사용하여 러너의 Docker 데몬을 작업 환경과 공유합니다. 이 구성을 구현하기 전에 [제한 사항](../docker/using_docker_build.md#use-the-docker-executor-with-docker-socket-binding)을 고려하세요.

개인 러너 사용 방법:

1. 새 러너 등록:

   ```shell
   $ gitlab-runner register --executor "docker" \
     --docker-image="docker:latest" \
     --url "https://gitlab.com/" \
     --description "cq-sans-dind" \
     --docker-volumes "/cache"\
     --docker-volumes "/builds:/builds"\
     --docker-volumes "/var/run/docker.sock:/var/run/docker.sock" \
     --registration-token="<project_token>" \
     --non-interactive

  1. 선택사항이지만 권장사항: 작업 아티팩트가 주기적으로 러너 호스트에서 정리되도록 빌드 디렉터리를 /tmp/builds로 설정하세요. 이 단계를 건너뛴 경우 기본 빌드 디렉토리(/builds)를 직접 정리해야 합니다. 이를 위해 이전 단계의 gitlab-runner register에 다음 두 플래그를 추가할 수 있습니다. 

    --builds-dir "/tmp/builds"
--docker-volumes "/tmp/builds:/tmp/builds" # --docker-volumes "/builds:/builds" 대신 이를 사용하세요

    결과 구성: 

    [[runners]]
  name = "cq-sans-dind"
  url = "https://gitlab.com/"
  token = "<project_token>"
  executor = "docker"
  builds_dir = "/tmp/builds"
  [runners.docker]
    tls_verify = false
    image = "docker:latest"
    privileged = false
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache", "/var/run/docker.sock:/var/run/docker.sock", "/tmp/builds:/tmp/builds"]
    shm_size = 0
  [runners.cache]
    [runners.cache.s3]
    [runners.cache.gcs]

  2. 템플릿에 의해 생성된 code_quality 작업에 두 가지 오버라이드 적용: 

    include:
  - template: Jobs/Code-Quality.gitlab-ci.yml

code_quality:
  services:            # Docker-in-Docker 비활성화
  tags:
    - cq-sans-dind     # 새로운 전용 러너에서만 이 작업을 실행하도록 설정

이제 코드 품질이 표준 Docker 모드에서 실행됩니다.

개인 러너에서 루트리스(Code Quality rootless)로 코드 품질 실행

개인 러너를 사용하고 코드 품질 스캔을 루트리스 Docker 모드로 실행하려는 경우 몇 가지 특별한 변경이 필요합니다. 소켓 바인딩의 변경으로 다른 작업에서 문제가 발생할 수 있으므로 코드 품질 작업만 실행하는 전용 러너를 갖는 것이 필요할 수 있습니다.

루트리스 개인 러너 사용 방법:

  1. 새 러너 등록:

    /run/user/<gitlab-runner-user>/docker.sock를 gitlab-runner 사용자의 로컬 docker.sock 경로로 대체하세요. 

    $ gitlab-runner register --executor "docker" \
  --docker-image="docker:latest" \
  --url "https://gitlab.com/" \
  --description "cq-rootless" \
  --tag-list "cq-rootless" \
  --locked="false" \
  --access-level="not_protected" \
  --docker-volumes "/cache" \
  --docker-volumes "/tmp/builds:/tmp/builds" \
  --docker-volumes "/run/user/<gitlab-runner-user>/docker.sock:/run/user/<gitlab-runner-user>/docker.sock" \
  --token "<project_token>" \
  --non-interactive \
  --builds-dir "/tmp/builds" \
  --env "DOCKER_HOST=unix:///run/user/<gitlab-runner-user>/docker.sock" \
  --docker-host "unix:///run/user/<gitlab-runner-user>/docker.sock"

    결과 구성: 

    [[runners]]
  name = "cq-rootless"
  url = "https://gitlab.com/"
  token = "<project_token>"
  executor = "docker"
  builds_dir = "/tmp/builds"
  environment = ["DOCKER_HOST=unix:///run/user/<gitlab-runner-user>/docker.sock"]
  [runners.docker]
    tls_verify = false
    image = "docker:latest"
    privileged = false
    disable_entrypoint_overwrite = false
    oom_kill_disable = false
    disable_cache = false
    volumes = ["/cache", "/run/user/<gitlab-runner-user>/docker.sock:/run/user/<gitlab-runner-user>/docker.sock", "/tmp/builds:/tmp/builds"]
    shm_size = 0
    host = "unix:///run/user/<gitlab-runner-user>/docker.sock"
  [runners.cache]
    [runners.cache.s3]
    [runners.cache.gcs]

  2. 템플릿에 의해 생성된 code_quality 작업에 다음 오버라이드 적용: 

    code_quality:
  services:
  variables:
    DOCKER_SOCKET_PATH: /run/user/997/docker.sock
  tags:
    - cq-rootless

이제 코드 품질이 표준 Docker 모드와 루트리스 모드에서 실행됩니다.

루트리스 Podman을 사용하여 코드 품질을 실행하려는 경우 루트리스 Podman을 사용하여 Docker를 실행하는 경우 동일한 구성이 필요합니다. 시스템에서 올바른 podman.sock 경로로 /run/user/<gitlab-runner-user>/docker.sock를 대체하세요. 예를 들어, /run/user/<gitlab-runner-user>/podman/podman.sock으로 대체하세요.

코드 품질 비활성화

$CODE_QUALITY_DISABLED CI/CD 변수가 존재하면 code_quality 작업이 실행되지 않습니다. 변수를 정의하는 방법에 대한 자세한 내용은 GitLab CI/CD 변수를 참조하세요.

코드 품질을 비활성화하려면 다음 중 하나의 사용자 정의 CI/CD 변수를 만드세요: 


## 스캔 설정 사용자 정의

코드 품질 스캔 설정은 `.gitlab-ci.yml`에서 [CI/CD 변수](#available-cicd-variables)를 사용하여 변경할 수 있습니다.

코드 품질 작업을 구성하려면:

1. 템플릿 포함 후 코드 품질 작업과 동일한 이름의 작업을 선언합니다.
1. 작업의 stanza에 추가적인 키를 지정합니다.

예시: [HTML 형식으로 출력 다운로드](#output-in-only-html-format)을 참조하세요.

## 사용 가능한 CI/CD 변수

코드 품질은 다음을 정의하여 사용 가능한 CI/CD 변수로 사용자 정의할 수 있습니다:

| CI/CD 변수                      | 설명 |
|---------------------------------|------|
| `CODECLIMATE_DEBUG`             | [Code Climate 디버그 모드](https://github.com/codeclimate/codeclimate#environment-variables)를 활성화하려면 설정합니다. |
| `CODECLIMATE_DEV`               | `--dev` 모드를 활성화하여 CLI에 알려지지 않은 엔진을 실행할 수 있도록 설정합니다. |
| `CODECLIMATE_PREFIX`            | CodeClimate 엔진의 모든 `docker pull` 명령에 사용할 접두어를 설정합니다. [오프라인 스캔](https://github.com/codeclimate/codeclimate/pull/948)에 유용합니다. 자세한 내용은 [개인용 컨테이너 레지스트리 사용](#use-a-private-container-image-registry)를 참조하세요. |
| `CODECLIMATE_REGISTRY_USERNAME` | `CODECLIMATE_PREFIX`에서 구문 분석된 레지스트리 도메인의 사용자 이름을 지정합니다. |
| `CODECLIMATE_REGISTRY_PASSWORD` | `CODECLIMATE_PREFIX`에서 구문 분석된 레지스트리 도메인의 암호를 지정합니다. |
| `CODE_QUALITY_DISABLED`         | 코드 품질 작업을 실행하지 않도록 설정합니다. |
| `CODE_QUALITY_IMAGE`            | 완전히 접두어가 붙은 이미지 이름으로 설정합니다. 이미지는 작업 환경에서 액세스 가능해야 합니다. |
| `ENGINE_MEMORY_LIMIT_BYTES`     | 엔진의 메모리 제한을 설정합니다. 기본값: 1,024,000,000 바이트 |
| `REPORT_STDOUT`                 | 보통의 보고서 파일을 생성하는 대신 `STDOUT`에 보고서를 인쇄하도록 설정합니다. |
| `REPORT_FORMAT`                 | 생성된 보고서 파일의 형식을 제어하도록 설정합니다. `json` 또는 `html` 중 하나로 설정합니다. |
| `SOURCE_CODE`                   | 스캔할 소스 코드의 경로입니다. 복제된 소스가 저장된 디렉터리의 절대 경로여야 합니다. |
| `TIMEOUT_SECONDS`               | `codeclimate analyze` 명령의 엔진 컨테이너별 사용자 정의 타임아웃을 설정합니다. 기본값: 900초 (15분) |

## 출력

코드 품질은 발견된 문제의 세부 정보를 포함하는 보고서를 출력합니다. 이 보고서의 내용은 내부적으로 처리되어 UI에서 결과가 표시됩니다. 또한 보고서는 `code_quality` 작업의 작업 artifact로 출력되며 `gl-code-quality-report.json`라고 명명됩니다. 선택적으로 HTML 형식으로 보고서를 출력할 수도 있습니다. 예를 들어 HTML 형식 파일을 더 쉽게 검토하기 위해 GitLab Pages에 게시할 수 있습니다.

### JSON 및 HTML 형식으로 출력

코드 품질 보고서를 JSON 및 HTML 형식으로 출력하려면 추가 작업을 생성해야 합니다. 이를 위해 코드 품질이 각각 파일 형식에 대해 두 번 실행되어야 합니다.

HTML 형식으로 코드 품질 보고서를 출력하려면 `extends: code_quality`를 사용하여 템플릿에 다른 작업을 추가하세요:

```yaml
include:
  - template: Jobs/Code-Quality.gitlab-ci.yml

code_quality_html:
  extends: code_quality
  variables:
    REPORT_FORMAT: html
  artifacts:
    paths: [gl-code-quality-report.html]

JSON 및 HTML 파일은 모두 작업 artifact로 출력됩니다. HTML 파일은 artifacts.zip 작업 artifact에 포함됩니다.

오직 HTML 형식으로 출력

코드 품질 보고서를 오직 HTML 형식으로 다운로드하려면 REPORT_FORMAT를 기본 code_quality 작업의 정의를 재정의하도록 html로 설정하면 됩니다.

참고: JSON 형식 파일은 만들어지지 않으므로 코드 품질 결과가 병합 요청 위젯, 파이프라인 보고서 또는 변경 보기에 표시되지 않습니다. 

include:
  - template: Jobs/Code-Quality.gitlab-ci.yml

code_quality:
  variables:
    REPORT_FORMAT: html
  artifacts:
    paths: [gl-code-quality-report.html]

HTML 파일은 작업 artifact로 출력됩니다.

병합 요청 파이프라인에서 코드 품질 사용

기본 코드 품질 구성은 병합 요청 파이프라인에서 code_quality 작업을 실행하지 않습니다.

병합 요청 파이프라인에서 코드 품질을 실행하려면 코드 품질 rules 또는 workflow: rules를 덮어써서 현재 rules와 일치하도록 해야 합니다.

예를 들어: 

include:
  - template: Jobs/Code-Quality.gitlab-ci.yml

code_quality:
  rules:
    - if: $CODE_QUALITY_DISABLED
      when: never
    - if: $CI_PIPELINE_SOURCE == "merge_request_event" # 병합 요청 파이프라인에서 코드 품질 작업 실행
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH      # 기본 브랜치의 파이프라인에서 코드 품질 작업 실행 (다른 브랜치 파이프라인에서는 실행하지 않음)
    - if: $CI_COMMIT_TAG                               # 태그용 파이프라인에서 코드 품질 작업 실행

비공개 컨테이너 이미지 레지스트리 사용

비공개 컨테이너 이미지 레지스트리 사용은 이미지 다운로드에 소요되는 시간을 줄일 수 있고 외부 종속성도 줄일 수 있습니다. 각각의 엔진에 대한 docker pull 명령에 CodeClimate의 이후에 레지스트리 접두어를 전달할 수 있어야 하므로 설정해야 합니다.

다음 변수들이 모든 필요한 이미지 pull을 해결할 수 있습니다:

  • CODE_QUALITY_IMAGE: 작업 환경에서 액세스할 수 있는 장소에 있는 완전히 접두어가 붙은 이미지 이름입니다. 여기서 GitLab 컨테이너 레지스트리를 사용하여 고유한 복사본을 호스팅할 수 있습니다.
  • CODECLIMATE_PREFIX: 의도된 컨테이너 이미지 레지스트리의 도메인입니다. 이는 CodeClimate CLI에서 지원하는 구성 옵션입니다.
    • 마지막에 슬래시(/)를 포함해야 합니다.
    • https://와 같은 프로토콜 접두어를 포함해서는 안 됩니다.
  • CODECLIMATE_REGISTRY_USERNAME: CODECLIMATE_PREFIX에서 파싱된 레지스트리 도메인의 사용자 이름을 지정하는 선택적 변수입니다.
  • CODECLIMATE_REGISTRY_PASSWORD: CODECLIMATE_PREFIX에서 파싱된 레지스트리 도메인의 암호를 지정하는 선택적 변수입니다. 
include:
  - template: Jobs/Code-Quality.gitlab-ci.yml

code_quality:
  variables:
    CODE_QUALITY_IMAGE: "my-private-registry.local:12345/codequality:0.85.24"
    CODECLIMATE_PREFIX: "my-private-registry.local:12345/"

이 예시는 GitLab 코드 품질에 특화되어 있습니다. Docker-in-Docker 서비스에 레지스트리 미러를 구성하는 일반적인 지침에 대한 자세한 내용은 Docker-in-Docker 서비스를 위한 레지스트리 미러 사용을 참조하세요.

필요한 이미지

다음 이미지들이 기본 .codeclimate.yml에 필요합니다:

  • codeclimate/codeclimate-structure:latest
  • codeclimate/codeclimate-csslint:latest
  • codeclimate/codeclimate-coffeelint:latest
  • codeclimate/codeclimate-duplication:latest
  • codeclimate/codeclimate-eslint:latest
  • codeclimate/codeclimate-fixme:latest
  • codeclimate/codeclimate-rubocop:rubocop-0-92

사용자 정의 .codeclimate.yml 구성 파일을 사용하는 경우, 지정된 플러그인을 개인 컨테이너 레지스트리에 추가해아합니다.

인증된 DockerHub 사용

코드 품질 이미지의 대체 소스로 DockerHub을 사용할 수 있습니다.

필수 조건:

DockerHub을 사용하려면 .gitlab-ci.yml 파일에서 다음 변수들을 구성하세요:

  • CODECLIMATE_PREFIX
  • CODECLIMATE_REGISTRY_USERNAME
  • CODECLIMATE_REGISTRY_PASSWORD

예시: 

include:
  - template: Jobs/Code-Quality.gitlab-ci.yml

code_quality:
  variables:
    CODECLIMATE_PREFIX: "registry-1.docker.io/"
    CODECLIMATE_REGISTRY_USERNAME: $DOCKERHUB_USERNAME
    CODECLIMATE_REGISTRY_PASSWORD: $DOCKERHUB_PASSWORD

의존성 프록시 사용

의존성 프록시를 사용하여 종속성 다운로드 시간을 줄일 수 있습니다.

필수 조건:

의존성 프록시를 참조하려면 .gitlab-ci.yml 파일에서 다음 변수들을 구성하세요:

  • CODE_QUALITY_IMAGE
  • CODECLIMATE_PREFIX
  • CODECLIMATE_REGISTRY_USERNAME
  • CODECLIMATE_REGISTRY_PASSWORD

예시: 

include:
  - template: Jobs/Code-Quality.gitlab-ci.yml

code_quality:
  variables:
    ## `$CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX`에는 trailing slash를 추가해야 합니다.
    CODECLIMATE_PREFIX: $CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX/
    CODECLIMATE_REGISTRY_USERNAME: $CI_DEPENDENCY_PROXY_USER
    CODECLIMATE_REGISTRY_PASSWORD: $CI_DEPENDENCY_PROXY_PASSWORD

사용자 정의 도구 구현

GitLab에 사용자 정의 도구를 통합하여 코드 품질 보고서를 제공할 수 있습니다.

코드 품질 보고서 아티팩트 JSON 파일은 다음 속성을 포함하는 객체 배열이어야 합니다:

이름 설명
description 코드 품질 위반에 대한 설명
check_name 이 문제를 발생시킨 정적 분석 확인을 나타내는 고유한 이름
fingerprint 코드 품질 위반을 식별하기 위한 고유한 지문. 예를 들어 MD5 해시
severity 심각도 문자열(info, minor, major, critical, 또는 blocker 중 하나)
location.path 코드 품질 위반이 포함된 파일의 상대 경로
location.lines.begin 또는 location.positions.begin.line 코드 품질 위반이 발생한 라인

주의: 코드 클라이메이트 사양은 더 많은 속성을 지원하지만, GitLab은 이를 무시합니다. GitLab 파서는 파일의 시작 부분에 바이트 순서 표시를 허용하지 않습니다.

사용자 정의 코드 품질 도구를 구현하려면:

  1. .gitlab-ci.yml 파일에 코드 품질 보고서 아티팩트를 생성하는 작업을 정의하세요 (Code Quality 보고서 아티팩트).
  2. 도구를 구성하여 코드 클라이메이트 사양의 하위 집합으로 코드 품질 보고서 아티팩트를 JSON 파일로 생성하세요.

예시: 

[
  {
    "description": "'unused' is assigned a value but never used.",
    "check_name": "no-unused-vars",
    "fingerprint": "7815696ecbf1c96e6894b779456d330e",
    "severity": "minor",
    "location": {
      "path": "lib/index.js",
      "lines": {
        "begin": 42
      }
    }
  }
]

여러 도구 통합

코드 품질은 파이프라인의 모든 작업에서 가져온 결과를 하나의 gl-code-quality-report.json 파일로 결합합니다. 결과적으로 지원되는 Code-Quality.gitlab-ci.yml 템플릿과 함께 또는 그 자리에 여러 개별 도구를 파이프라인에서 사용할 수 있습니다.

다음은 ESLint 출력을 필요한 형식으로 반환하는 예시입니다: 

eslint:
  image: node:18-alpine
  script:
    - npm ci
    - npx eslint --format gitlab .
  artifacts:
    reports:
      codequality: gl-code-quality-report.json

분석 플러그인 사용

코드 품질 기능은 Code Climate 분석 플러그인을 사용하여 확장할 수 있습니다.

예를 들어 SonarJava 분석기를 사용하려면:

  1. 리포지토리 루트에 .codeclimate.yml이라는 파일을 추가하세요.

  2. 파일에 분석 플러그인을 활성화하는 코드를 추가하세요 : 

    version: "2"
plugins:
  sonar-java:
    enabled: true

이렇게 하면 프로젝트에 포함된 기본 .codeclimate.yml에 SonarJava가 plugins: 섹션에 추가됩니다.

plugins: 섹션의 변경사항은 기본 .codeclimate.yml의 exclude_patterns 섹션에 영향을 주지 않습니다. 자세한 내용은 파일 및 폴더의 제외에 대한 Code Climate 문서를 참조하세요.

Kubernetes 및 OpenShift에서 코드 품질 사용

코드 품질을 사용하려면 Docker-in-Docker(딘디)로 구성된 도커 컨테이너에 Docker를 설정해야 합니다. Kubernetes executor는 Docker-in-Docker를 지원합니다.

코드 품질 작업이 Kubernetes executor에서 실행되도록하려면:

  • 도커 데몬과의 통신에 TLS를 사용하는 경우 executor는 권한 부여된 모드에서 실행되어야 합니다. 또한 인증서 디렉토리를 볼륨 마운트로 지정해야 합니다.
  • 코드 품질 작업이 시작되기 전에 딘디 서비스가 완전히 시작되지 않을 수 있습니다. 이는 Kubernetes executor의 문제 해결에 문서화된 제한입니다. 이 문제를 해결하려면 before_script를 사용하여 도커 데몬이 완전히 부팅될 때까지 기다리세요. 예시는 아래 .gitlab-ci.yml 파일의 구성을 참조하세요.

Kubernetes

쿠버네티스에서 Code Quality를 실행하려면:

  • Docker in Docker 서비스를 config.toml 파일의 서비스 컨테이너로 추가해야 합니다.
  • 서비스 컨테이너의 Docker 데몬은 TCP 및 UNIX 소켓에서 모두 수신해야 합니다. Code Quality에서 두 소켓 모두 필요합니다.
  • Docker 소켓은 볼륨과 공유되어야 합니다.

도커 요구 사항으로 인해 서비스 컨테이너에는 특권 플래그가 활성화되어야 합니다. 

[runners.kubernetes]

[runners.kubernetes.service_container_security_context]
privileged = true
allow_privilege_escalation = true

[runners.kubernetes.volumes]

[[runners.kubernetes.volumes.empty_dir]]
mount_path = "/var/run/"
name = "docker-sock"

[[runners.kubernetes.services]]
alias = "dind"
command = [
    "--host=tcp://0.0.0.0:2375",
    "--host=unix://var/run/docker.sock",
    "--storage-driver=overlay2"
]
entrypoint = ["dockerd"]
name = "docker:20.10.12-dind"

참고: GiltLab Runner Helm Chart를 사용하는 경우, config 필드에서 위의 쿠버네티스 구성을 values.yaml 파일에 사용할 수 있습니다.

가장 전반적인 성능을 제공하는 overlay2 스토리지 드라이버를 사용하도록 DOCKER_HOST를 지정하세요.

  • Docker CLI가 통신하는 DOCKER_HOST를 지정하세요.
  • DOCKER_DRIVER 변수를 비워두세요.

before_script 섹션을 사용하여 Docker 데몬이 완전히 부팅될 때까지 기다릴 수 있습니다. GitLab Runner v16.9부터는 이를 단순히 HEALTHCHECK_TCP_PORT 변수를 설정함으로써 할 수도 있습니다. 

include:
  - template: Code-Quality.gitlab-ci.yml

code_quality:
  services: []
  variables:
    DOCKER_HOST: tcp://dind:2375
    DOCKER_DRIVER: ""
  before_script:
    - while ! docker info > /dev/null 2>&1; do sleep 1; done

OpenShift

OpenShift에서는 GitLab Runner Operator를 사용해야 합니다. 서비스 컨테이너의 Docker 데몬에 스토리지를 초기화할 수 있는 권한을 주려면 /var/lib 디렉토리를 볼륨 마운트해야 합니다.

참고: /var/lib 디렉토리를 볼륨 마운트할 수 없는 경우 --storage-driver를 대신에 vfs로 설정할 수 있습니다. vfs 값을 선택하는 경우 성능에 부정적인 영향을 미칠 수 있습니다.

Docker 데몬의 권한을 구성하려면 다음을 수행하세요.

  1. 아래 제공된 구성을 사용하여 config.toml이라는 파일을 작성하세요. 이 구성은 GitLab Runner에서 생성된 config.toml을 사용자화하는 데 사용됩니다. 
[[runners]]

[runners.kubernetes]

[runners.kubernetes.service_container_security_context]
privileged = true
allow_privilege_escalation = true

[runners.kubernetes.volumes]

[[runners.kubernetes.volumes.empty_dir]]
mount_path = "/var/run/"
name = "docker-sock"

[[runners.kubernetes.volumes.empty_dir]]
mount_path = "/var/lib/"
name = "docker-data"

[[runners.kubernetes.services]]
alias = "dind"
command = [
    "--host=tcp://0.0.0.0:2375",
    "--host=unix://var/run/docker.sock",
    "--storage-driver=overlay2"
]
entrypoint = ["dockerd"]
name = "docker:20.10.12-dind"

  1. 사용자화된 구성을 등록하세요.

  2. 선택 사항. 빌드 Pod에 privileged 서비스 어카운트를 추가하세요. 이는 OpenShift 클러스터 설정에 따라 다릅니다. 

    oc create sa dind-sa
oc adm policy add-scc-to-user anyuid -z dind-sa
oc adm policy add-scc-to-user -z dind-sa privileged

  3. 다른 config.toml 설정과 동일한 job 정의를 유지하세요. 

    include:
- template: Code-Quality.gitlab-ci.yml

code_quality:
services: []
variables:
  DOCKER_HOST: tcp://dind:2375
  DOCKER_DRIVER: ""
before_script:
  - while ! docker info > /dev/null 2>&1; do sleep 1; done

볼륨 및 Docker 스토리지

Docker는 모든 데이터를 /var/lib 볼륨에 저장하며, 이는 큰 용량의 볼륨으로 이어질 수 있습니다. 클러스터 전체에서 Docker-in-Docker 스토리지를 재사용하려는 경우 지속적인 볼륨(Persistent Volumes)를 대체로 사용할 수 있습니다.