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です。
コード品質を有効にするには、次のいずれかを実行します:
Auto DevOpsを有効にします。これにはAutoコード品質が含まれます。
コード品質テンプレートを
.gitlab-ci.ymlファイルに含めます。例:
include: - template: Jobs/Code-Quality.gitlab-ci.ymlコード品質がパイプラインで実行されるようになりました。
セルフマネージドの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アナライザーを使用するには、次の手順に従います:
.codeclimate.ymlという名前のファイルをリポジトリのルートに追加します。.codeclimate.ymlファイルに、リポジトリのルートに対するプラグインのイネーブルメントコードを追加します:version: "2" plugins: sonar-java: enabled: true
これにより、プロジェクトに含まれるデフォルト.codeclimate.ymlのplugins:セクションにSonarJavaが追加されます。
plugins:セクションへの変更は、デフォルト.codeclimate.ymlのexclude_patternsセクションには影響しません。詳細については、Code Climateのファイルとフォルダーの除外に関するドキュメントを参照してください。
スキャンジョブ設定をカスタマイズする
GitLab CI/CD YAMLでCI/CD変数を設定することで、code_qualityスキャンジョブの動作を変更できます。
コード品質ジョブを設定するには、次の手順に従います:
- テンプレートの組み込み後、コード品質ジョブと同じ名前でジョブを宣言します。
- ジョブのスタンザで追加のキーを指定します。
例については、HTML形式での出力のダウンロードを参照してください。
利用可能なCI/CD変数
使用可能なCI/CD変数を定義することで、コード品質をカスタマイズできます:
| CI/CD変数 | 説明 |
|---|---|
CODECLIMATE_DEBUG | Code Climateデバッグモードを有効にするように設定します。 |
CODECLIMATE_DEV | CLIに認識されていないエンジンを実行できるようにする--devモードを有効にするように設定します。 |
CODECLIMATE_PREFIX | CodeClimateエンジンのすべてのdocker pullコマンドで使用するプレフィックスを設定します。オフラインスキャンに役立ちます。詳細については、プライベートコンテナイメージレジストリの使用を参照してください。 |
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ジョブのジョブアーティファクトとしても出力され、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_FORMATをhtmlに設定して、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 tagsCodeClimateイメージのダウンロード方法を変更する
CodeClimateエンジンは、それぞれのプラグインを実行するために、コンテナイメージをダウンロードします。デフォルトでは、イメージはDocker Hubからダウンロードされます。イメージソースを変更して、パフォーマンスを向上させたり、Docker Hubのレート制限を回避したり、プライベートレジストリを使用したりできます。
依存プロキシを使用してイメージをダウンロードする
依存プロキシを使用すると、依存関係をダウンロードするのにかかる時間を短縮できます。
前提要件:
- プロジェクトのグループで依存プロキシが有効になっています。
依存プロキシを参照するには、.gitlab-ci.ymlファイルで次の変数を設定します:
CODE_QUALITY_IMAGECODECLIMATE_PREFIXCODECLIMATE_REGISTRY_USERNAMECODECLIMATE_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をコード品質イメージの代替ソースとして使用できます。
前提要件:
- ユーザー名とパスワードを、プロジェクトの保護されたCI/CD変数として追加します。
DockerHubを使用するには、.gitlab-ci.ymlファイルで次の変数を設定します:
CODECLIMATE_PREFIXCODECLIMATE_REGISTRY_USERNAMECODECLIMATE_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:latestcodeclimate/codeclimate-csslint:latestcodeclimate/codeclimate-coffeelint:latestcodeclimate/codeclimate-duplication:latestcodeclimate/codeclimate-eslint:latestcodeclimate/codeclimate-fixme:latestcodeclimate/codeclimate-rubocop:rubocop-0-92
カスタム.codeclimate.yml設定ファイルを使用している場合は、指定されたプラグインをプライベートコンテナレジストリに追加する必要があります。
Runnerの設定を変更する
CodeClimateは、分析ステップごとに個別のコンテナを実行します。CodeClimateベースのスキャンを実行できるように、またはより高速に実行できるように、Runnerの設定を調整する必要がある場合があります。
プライベートRunnerの使用
プライベートRunnerがある場合は、コード品質のパフォーマンスを向上させるために、この設定を使用する必要があります:
- 特権モードは使用されていません。
- Docker-in-Dockerは使用されていません。
- すべてのCodeClimateイメージを含むDockerイメージはキャッシュされ、後続のジョブのために再フェッチされません。
この代替設定では、ソケットバインディングを使用して、RunnerのDockerデーモンをジョブ環境と共有します。この設定を実装する前に、その制限事項を検討してください。
プライベートRunnerを使用するには、次の手順に従います:
新しい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-interactiveOptional, 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]テンプレートによって作成された
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を使用するには、次の手順に従います:
新しい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]テンプレートによって作成された
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; doneOpenShift
OpenShiftの場合は、GitLab Runner Operatorを使用する必要があります。サービスコンテナ内のDockerデーモンにストレージを初期化する権限を与えるには、/var/libディレクトリをボリュームマウントとしてマウントする必要があります。
/var/libディレクトリをボリュームマウントとしてマウントできない場合は、--storage-driverを代わりにvfsに設定できます。vfs値を選択した場合、performanceに悪影響を与える可能性があります。
Dockerデーモンの権限を設定するには、次のようにします:
- この設定テンプレートで
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"オプション。ビルドポッドに
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[runners.kubernetes]セクションで権限を設定します。ジョブの定義は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ストレージをクラスター全体で再利用するには、代替手段として永続ボリュームを使用できます。