正式なドキュメントは英語版であり、この日本語訳はAI支援翻訳により作成された参考用のものです。日本語訳の一部の内容は人間によるレビューがまだ行われていないため、翻訳のタイミングにより英語版との間に差異が生じることがあります。最新かつ正確な情報については、英語版をご参照ください。

CodeClimateベースのコード品質スキャンを設定する(非推奨)

  • プラン: Free、Premium、Ultimate
  • 提供形態: GitLab.com、GitLab Self-Managed、GitLab Dedicated

この機能は、GitLab 17.3で非推奨となり、19.0で削除される予定です。代わりに、サポートされているツールの結果を直接統合してください。これは破壊的な変更です。

Code Qualityには、組み込みのCI/CDテンプレートCode-Quality.gitlab-ci.yamlも含まれています。このテンプレートは、オープンソースのCodeClimateスキャンエンジンに基づいてスキャンを実行します。

CodeClimateエンジンは以下を実行します:

CodeClimateベースのスキャンを有効にする

前提要件:

  • GitLab CI/CD設定(.gitlab-ci.yml)には、testステージを含める必要があります。
  • インスタンスRunnerを使用している場合、コード品質ジョブは、Docker-in-Dockerワークフロー用に構成する必要があります。このワークフローを使用する場合、/buildsボリュームをレポートの保存を許可するようにマップする必要があります。
  • プライベートRunnerを使用している場合は、コード品質分析をより効率的に実行するために推奨される代替設定を使用する必要があります。
  • Runnerには、生成されたコード品質ファイルを格納するのに十分なディスク容量が必要です。たとえば、GitLabプロジェクトでは、ファイルのサイズは約7 GBです。

コード品質を有効にするには、次のいずれかを実行します:

セルフマネージドのGitLabでは、悪意のあるアクターがコード品質ジョブ定義を侵害した場合、Runnerホストで特権Dockerコマンドを実行する可能性があります。適切なアクセス制御ポリシーを持つことで、信頼できるアクターのみにアクセス制御を許可することにより、この脅威ベクターを軽減できます。

CodeClimateベースのスキャンを無効にする

code_qualityジョブは、$CODE_QUALITY_DISABLED CI/CD変数が存在する場合、実行されません。変数の定義方法の詳細については、GitLab CI/CD変数を参照してください。

コード品質を無効にするには、次のいずれかのCODE_QUALITY_DISABLEDという名前のカスタムCI/CD変数を作成します:

CodeClimate分析プラグインを構成する

デフォルトでは、code_qualityジョブは、CodeClimateが以下を実行するように構成します:

より多くの言語をスキャンするには、より多くのプラグインを有効にできます。また、code_qualityジョブがデフォルトで有効にするプラグインを無効にすることもできます。

たとえば、SonarJavaアナライザーを使用するには、次の手順に従います:

  1. .codeclimate.ymlという名前のファイルをリポジトリのルートに追加します。

  2. .codeclimate.ymlファイルに、リポジトリのルートに対するプラグインのイネーブルメントコードを追加します:

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

これにより、プロジェクトに含まれるデフォルト.codeclimate.ymlplugins:セクションにSonarJavaが追加されます。

plugins:セクションへの変更は、デフォルト.codeclimate.ymlexclude_patternsセクションには影響しません。詳細については、Code Climateのファイルとフォルダーの除外に関するドキュメントを参照してください。

スキャンジョブ設定をカスタマイズする

GitLab CI/CD YAMLでCI/CD変数を設定することで、code_qualityスキャンジョブの動作を変更できます。

コード品質ジョブを設定するには、次の手順に従います:

  1. テンプレートの組み込み後、コード品質ジョブと同じ名前でジョブを宣言します。
  2. ジョブのスタンザで追加のキーを指定します。

例については、HTML形式での出力のダウンロードを参照してください。

利用可能なCI/CD変数

使用可能なCI/CD変数を定義することで、コード品質をカスタマイズできます:

CI/CD変数説明
CODECLIMATE_DEBUGCode Climateデバッグモードを有効にするように設定します。
CODECLIMATE_DEVCLIに認識されていないエンジンを実行できるようにする--devモードを有効にするように設定します。
CODECLIMATE_PREFIXCodeClimateエンジンのすべてのdocker pullコマンドで使用するプレフィックスを設定します。オフラインスキャンに役立ちます。詳細については、プライベートコンテナイメージレジストリの使用を参照してください。
CODECLIMATE_REGISTRY_USERNAMECODECLIMATE_PREFIXから解析中されたレジストリドメインのユーザー名を指定するように設定します。
CODECLIMATE_REGISTRY_PASSWORDCODECLIMATE_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_SECONDScodeclimate analyzeコマンドのエンジンコンテナごとのカスタムタイムアウト。デフォルトは、: 900秒(15分)

出力

コード品質は、見つかったイシューの詳細を含むレポートを出力します。このレポートの内容は内部で処理され、UIに結果が表示されます。レポートは、code_qualityジョブのジョブアーティファクトとしても出力され、gl-code-quality-report.jsonという名前が付けられます。オプションで、HTML形式でレポートを出力できます。たとえば、GitLab PagesでHTML形式のファイルを公開して、さらに簡単にレビューできます。

JSONおよびHTML形式での出力

JSONおよびHTML形式でコード品質レポートを出力するには、追加のジョブを作成します。これには、コード品質を2回実行する必要があります(ファイル形式ごとに1回)。

HTML形式でコード品質レポートを出力するには、extends: code_qualityを使用して、別のジョブをテンプレートに追加します:

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ファイルの両方がジョブアーティファクトとして出力されます。HTMLファイルはartifacts.zipジョブアーティファクトに含まれています。

HTML形式のみでの出力

HTML形式でのみコード品質レポートをダウンロードするには、REPORT_FORMAThtmlに設定して、code_qualityジョブのデフォルト定義を上書きします。

これにより、JSON形式のファイルは作成されないため、マージリクエストウィジェット、パイプラインレポート、または変更ビューにコード品質の結果は表示されません。

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

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

HTMLファイルは、ジョブアーティファクトとして出力されます。

マージリクエストパイプラインでのコード品質の使用

デフォルトのコード品質設定では、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" # Run code quality job in merge request pipelines
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH      # Run code quality job in pipelines on the default branch (but not in other branch pipelines)
    - if: $CI_COMMIT_TAG                               # Run code quality job in pipelines for tags

CodeClimateイメージのダウンロード方法を変更する

CodeClimateエンジンは、それぞれのプラグインを実行するために、コンテナイメージをダウンロードします。デフォルトでは、イメージはDocker Hubからダウンロードされます。イメージソースを変更して、パフォーマンスを向上させたり、Docker Hubのレート制限を回避したり、プライベートレジストリを使用したりできます。

依存プロキシを使用してイメージをダウンロードする

依存プロキシを使用すると、依存関係をダウンロードするのにかかる時間を短縮できます。

前提要件:

依存プロキシを参照するには、.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:
    ## You must add a trailing slash to `$CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX`.
    CODECLIMATE_PREFIX: $CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIX/
    CODECLIMATE_REGISTRY_USERNAME: $CI_DEPENDENCY_PROXY_USER
    CODECLIMATE_REGISTRY_PASSWORD: $CI_DEPENDENCY_PROXY_PASSWORD

認証でのDocker Hubの使用

Docker Hubをコード品質イメージの代替ソースとして使用できます。

前提要件:

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

プライベートコンテナイメージレジストリの使用

プライベートコンテナイメージレジストリを使用すると、イメージのダウンロードにかかる時間を短縮できるだけでなく、外部依存関係を減らすこともできます。コンテナ実行のネストされたメソッドのため、CodeClimateの後続のdocker 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コード品質に固有のものです。レジストリミラーを使用したDinDの設定方法に関する一般的な手順については、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設定ファイルを使用している場合は、指定されたプラグインをプライベートコンテナレジストリに追加する必要があります。

Runnerの設定を変更する

CodeClimateは、分析ステップごとに個別のコンテナを実行します。CodeClimateベースのスキャンを実行できるように、またはより高速に実行できるように、Runnerの設定を調整する必要がある場合があります。

プライベートRunnerの使用

プライベートRunnerがある場合は、コード品質のパフォーマンスを向上させるために、この設定を使用する必要があります:

  • 特権モードは使用されていません。
  • Docker-in-Dockerは使用されていません。
  • すべてのCodeClimateイメージを含むDockerイメージはキャッシュされ、後続のジョブのために再フェッチされません。

この代替設定では、ソケットバインディングを使用して、RunnerのDockerデーモンをジョブ環境と共有します。この設定を実装する前に、その制限事項を検討してください。

プライベートRunnerを使用するには、次の手順に従います:

  1. 新しいRunnerを登録:

    $ gitlab-runner register --executor "docker" \
      --docker-image="docker:cli" \
      --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
  2. Optional, but recommended(推奨): ジョブアーティファクトがRunnerホストから定期的にパージされるように、ビルドディレクトリを/tmp/buildsに設定します。このステップをスキップする場合は、デフォルトのビルドディレクトリ(/builds)を自分でクリーンアップする必要があります。これを行うには、前のステップで次の2つのフラグをgitlab-runner registerに追加します。

    --builds-dir "/tmp/builds"
    --docker-volumes "/tmp/builds:/tmp/builds" # Use this instead of --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:cli"
        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]
  3. テンプレートによって作成されたcode_qualityジョブに2つのオーバーライドを適用します:

    include:
      - template: Jobs/Code-Quality.gitlab-ci.yml
    
    code_quality:
      services:            # Shut off Docker-in-Docker
      tags:
        - cq-sans-dind     # Set this job to only run on our new specialized runner

コード品質が標準のDockerモードで実行されるようになりました。

プライベートRunnerでのCodeClimateルートレス実行

プライベートRunnerを使用していて、ルートレスDockerモードでコード品質スキャンを実行する場合は、コード品質が適切に実行されるように、特別な変更が必要です。ソケットバインディングの変更が他のジョブで問題を引き起こす可能性があるため、コード品質ジョブのみを実行するように専用のRunnerが必要になる場合があります。

ルートレスのプライベートRunnerを使用するには、次の手順に従います:

  1. 新しいRunnerを登録:

    /run/user/<gitlab-runner-user>/docker.sockを、gitlab-runnerユーザーのローカルdocker.sockへのパスに置き換えます。

    $ gitlab-runner register --executor "docker" \
      --docker-image="docker:cli" \
      --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:cli"
        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を使用してDockerを実行する場合も、同じ設定が必要です。システムで正しいpodman.sockのパスに/run/user/<gitlab-runner-user>/docker.sockを置き換えるようにしてください(例:/run/user/<gitlab-runner-user>/podman/podman.sock)。

KubernetesまたはOpenShiftRunnerの設定

コード品質を使用するには、Dockerコンテナ(Docker-in-Docker)でDockerをセットアップする必要があります。Kubernetes executorはDocker-in-Dockerをサポートしています。

Kubernetes executorでコード品質ジョブを実行できるようにするには、次の手順に従います:

  • Dockerデーモンとの通信にTLSを使用している場合、executorは特権モードで実行されている必要があります。さらに、証明書ディレクトリはボリュームマップとして指定する必要があります。
  • DinDサービスがコード品質ジョブの開始前に完全に起動しない可能性があります。これは、Kubernetes executorのトラブルシューティングでドキュメント化されている制限事項です。このイシューを解決するには、before_scriptを使用して、Dockerデーモンが完全に起動するまで待ちます。例については、次のセクションで説明する.gitlab-ci.ymlファイルの設定を参照してください。

Kubernetes

Kubernetesでコード品質を実行するには、次の手順に従います:

  • Docker in Dockerサービスは、config.tomlファイルでサービスコンテナとして追加する必要があります。
  • サービスコンテナ内のDockerデーモンは、コード品質で両方のソケットが必要なため、TCPソケットとUNIXソケットでリッスンする必要があります。
  • Dockerソケットは、ボリュームと共有する必要があります。

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"

GitLab Runner Helmチャートを使用している場合は、values.yamlファイルのconfigフィールドで、以前のKubernetes設定を使用できます。x

パフォーマンス全体が最適なoverlay2ストレージドライバーを使用するには、次の手順に従います:

  • 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値を選択した場合、performanceに悪影響を与える可能性があります。

Dockerデーモンの権限を設定するには、次のようにします:

  1. この設定テンプレートでconfig.tomlファイルを作成し、Runnerの設定をカスタマイズします:
[[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. カスタム設定をRunnerに設定します

  2. オプション。ビルドポッドに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. [runners.kubernetes]セクションで権限を設定します。

  4. ジョブの定義はKubernetesの場合と同じままです:

    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ストレージをクラスター全体で再利用するには、代替手段として永続ボリュームを使用できます。