- ティアごとの機能
- コード品質結果の表示
- コード品質の有効化
- Code Qualityの無効化
- スキャン設定のカスタマイズ
- 出力
- マージリクエストパイプラインでCode Qualityを使う
- 非公開コンテナ・イメージ・レジストリの使用
- 認証付きDockerHubの使用
- 依存プロキシを使う
- カスタムツールの実装
- 複数のツールのインテグレーション
- 解析プラグインの使用
-
トラブルシューティング
- コードが見つからず、パイプラインが常にデフォルト設定で実行されます。
- デフォルトの設定を変更しても効果はありません。
- マージリクエストで Code Quality レポートが表示されません。
- コード品質レポートは1つしか表示されませんが、より多くのレポートが定義されています。
- RuboCop エラー
- カスタムツールを使用している場合、マージリクエストに Code Quality が表示されません。
- エラー:
Could not analyze code quality
- Kubernetes CI ExecutorでCode Qualityを使用する場合
-
エラー:
x509: certificate signed by unknown authority
コードの品質
13.2でGitLab Freeに移動しました。
Code Qualityを使ってソースコードの品質と複雑さを分析しましょう。これは、プロジェクトのコードをシンプルで読みやすく、メンテナーしやすく保つのに役立ちます。コードクオリティは、他のレビュープロセスを補うものであって、取って代わるものではありません。
Code Qualityでは、オープンソースのCode Climateツールと選択したプラグインを使用してソースコードを分析します。コードの言語がカバーされているかどうかを確認するには、Code Climateのメンテナー対応言語リストを参照してください。コードカバレッジを拡張するには、Code Climate分析プラグインまたはカスタムツールを使用します。
CI/CD パイプラインでコード品質レポーターを実行し、変更をデフォルトブランチにコミットする_前に_、変更がコードの品質を低下させないことを確認します。
ティアごとの機能
以下の表に示すように、GitLabの階層によって利用できる機能が異なります:
機能 | 無料 | プレミアム | アルティメット |
---|---|---|---|
スキャナの設定 | {チェックサークル} | {チェックサークル} | {チェックサークル} |
カスタムスキャナのインテグレーション | {チェックサークル} | {チェックサークル} | {チェックサークル} |
マージリクエストウィジェットの所見を参照 | {チェックサークル} | {チェックサークル} | {チェックサークル} |
JSON または HTML レポートのアーティファクトの生成 | {チェックサークル} | {チェックサークル} | {チェックサークル} |
CI パイプラインでレポーターを参照 | {点線円} | {チェックサークル} | {チェックサークル} |
マージリクエストの差分ビューで調査結果を参照 | {点線円} | {点線円} | {チェックサークル} |
コード品質結果の表示
コードクオリティの結果は
- マージリクエストウィジェット
- マージリクエスト変更ビュー
- パイプライン詳細ビュー
- プロジェクト品質ビュー
マージリクエストウィジェット
13.2でGitLab Freeに移動しました。
コード品質の分析結果は、比較のためにターゲットブランチからのレポートが利用可能な場合、マージリクエストウィジェットエリアに表示されます。マージリクエストウィジェットには、マージリクエストで行われた変更によってもたらされた Code Quality の発見と解決策が表示されます。
マージリクエスト変更ビュー
Code Quality の結果は、マージリクエストのChangesビューに表示されます。コードクオリティのイシューを含む行には、ガターの横にインジケータが表示されます。マーカーにカーソルを合わせると、イシューの詳細が表示されます。
パイプライン詳細ビュー
パイプラインによって生成されたコード品質違反の完全なリストは、パイプラインの詳細ページのコード品質タブに表示されます。パイプラインの詳細ビューには、パイプラインが実行されたブランチで検出されたすべての Code Quality 所見が表示されます。
プロジェクト品質ビュー
プロジェクト品質ビューは、コード品質の調査結果の概要を表示します。このビューは、Analyze > CI/CD analyticsの下にあり、project_quality_summary_page
機能フラグがこの特定のプロジェクトで有効になっている必要があります。
コード品質の有効化
前提条件:
- GitLab CI/CD 設定 (
.gitlab-ci.yml
) にtest
ステージが含まれている必要があります。 - 共有Runnerを使用している場合、Code QualityジョブはDocker-in-Dockerワークフロー用に設定する必要があります。
- 非公開ランナーを使用している場合は、Code Quality分析をより効率的に実行するために推奨される別の設定を使用する必要があります。
- Runnerには、生成されたCode Qualityファイルを保存するのに十分なディスク容量が必要です。例えば、GitLabプロジェクトではファイルは約7GBです。
Code Qualityを有効にするには
-
Auto DevOpsを有効にする(Auto Code Qualityを含む)。
-
.gitlab-ci.yml
ファイルに Code Quality テンプレートを含めます。使用例:
include: - template: Code-Quality.gitlab-ci.yml
Code Qualityはパイプラインで実行されるようになりました。
非公開ランナーによるCode Qualityパフォーマンスの向上
非公開Runnerを使用している場合は、Code Qualityのパフォーマンスを向上させるためにこの設定を使用する必要があります:
- 特権モードは使用されません。
- Docker-in-Dockerは使用しません。
- すべてのCodeClimateイメージを含むDockerイメージはキャッシュされ、以降のジョブで再フェッチされることはありません。
この代替設定では、ソケットバインディングを使用してRunnerのDockerデーモンをジョブ環境と共有します。この設定を実装する前に、その制限を考慮してください。
非公開Runnerを使用するには:
-
新しいランナーを登録してください:
$ gitlab-runner register --executor "docker" \ --docker-image="docker:latest" \ --url "https://gitlab.com/" \ --description "cq-sans-dind" \ --tag-list "cq-sans-dind" \ --locked="false" \ --access-level="not_protected" \ --docker-volumes "/cache"\ --docker-volumes "/builds:/builds"\ --docker-volumes "/var/run/docker.sock:/var/run/docker.sock" \ --registration-token="<project_token>" \ --non-interactive
-
オプションですが、お勧めします:ジョブのアーティファクトがランナーホストから定期的にパージされるように、ビルドディレク トリを
/tmp/builds
に設定します。このステップをスキップすると、デフォルトのビルド・ディレク トリ(/builds
)を自分でクリーンアップする必要があります。前のステップでgitlab-runner register
に次の2つのフラグを追加することでこれを行うことができます。--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: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]
-
テンプレートによって作成された
code_quality
ジョブに 2 つのオーバーライドを適用します:include: - template: 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
Code Qualityが標準のDockerモードで実行されるようになりました。
Code Qualityの無効化
$CODE_QUALITY_DISABLED
CI/CD 変数が存在する場合、code_quality
ジョブは実行されません。変数の定義方法については、GitLab CI/CD変数を参照してください。
Code Quality を無効にするには、CODE_QUALITY_DISABLED
という名前のカスタム CI/CD 変数を作成します:
スキャン設定のカスタマイズ
Code Qualityのスキャン設定は、.gitlab-ci.yml
のCI/CD変数を使って変更できます。
Code Qualityジョブを設定するには:
- テンプレートをインクルードした後、Code Qualityジョブと同じ名前のジョブを宣言します。
- ジョブのスタンザで追加のキーを指定します。
例については、JSON形式での出力のダウンロードを参照してください。
利用可能な CI/CD 変数
GitLab 13.4以降では、Code Quality環境変数を上書きするオプションが追加されました。
利用可能なCI/CD変数を定義することで、Code Qualityをカスタマイズすることができます:
CI/CD 変数 | 説明 |
---|---|
SOURCE_CODE | スキャンするソースコードへのパス。 |
TIMEOUT_SECONDS |
codeclimate analyze コマンドのエンジン コンテナごとのカスタム タイムアウト。デフォルトは 900 秒(15 分)です。 |
CODECLIMATE_DEBUG | Code Climate デバッグ・モードを有効にします。 |
CODECLIMATE_DEV |
--dev モードを有効に設定します。これにより、CLI で認識されていないエンジンを実行できます。 |
REPORT_STDOUT | 通常のレポート・ファイルを生成する代わりに、レポートをSTDOUT に印刷するように設定します。 |
REPORT_FORMAT | 生成されるレポート・ファイルの形式を制御するために設定します。json\|html のいずれか。 |
ENGINE_MEMORY_LIMIT_BYTES | エンジンのメモリ制限を設定します。デフォルトは1,024,000,000バイトです。 |
CODE_QUALITY_DISABLED | Code Qualityジョブの実行を防ぎます。 |
CODECLIMATE_PREFIX | CodeClimate エンジンのすべてのdocker pull コマンドで使用する接頭辞を設定します。オフラインスキャンに便利です。 |
出力
Code Quality はgl-code-quality-report.json
という名前のファイルを作成します。このファイルの内容は内部で処理され、結果はUIに表示されます。生の結果を見るには、Code Qualityジョブを設定してこのファイルのダウンロードを許可します。フォーマットのオプションは、JSONフォーマット、HTMLフォーマット、またはその両方です。より人間が読みやすい形式でレポートを表示するには、HTML形式を使用します。例えば、HTML形式のファイルをGitLab Pagesで公開すれば、レビューがより簡単になります。
JSON形式の出力をダウンロード
コード品質レポートをJSON形式でダウンロードできるようにするには、code_quality
ジョブのアーティファクトとしてgl-code-quality-report.json
ファイルを宣言します:
include:
- template: Code-Quality.gitlab-ci.yml
code_quality:
artifacts:
paths: [gl-code-quality-report.json]
完全なJSONファイルはcode_quality
ジョブのダウンロード可能なアーティファクトとして利用できます。
JSONとHTML形式の出力をダウンロード
GitLab 13.6で導入されたHTMLレポートフォーマット。
JSON形式とHTML形式の両方でCode Qualityレポートをダウンロードできるようにするには、extends: code_quality
を使用してテンプレートに別のジョブを追加します:
include:
- template: Code-Quality.gitlab-ci.yml
code_quality_html:
extends: code_quality
variables:
REPORT_FORMAT: html
artifacts:
paths: [gl-code-quality-report.html]
JSONファイルとHTMLファイルの両方がcode_quality
ジョブのダウンロード可能なアーティファクトとして利用できます。
HTML形式のみの出力をダウンロード
Code QualityレポートをHTML形式の_ファイルのみで_ダウンロードするには、既存のジョブでREPORT_FORMAT
をhtml
に設定します。
include:
- template: Code-Quality.gitlab-ci.yml
code_quality:
variables:
REPORT_FORMAT: html
artifacts:
paths: [gl-code-quality-report.html]
HTML ファイルはcode_quality
ジョブのダウンロード可能なアーティファクトとして利用できます。
マージリクエストパイプラインでCode Qualityを使う
デフォルトの Code Quality 設定では、code_quality
ジョブをマージリクエストパイプライン上で実行することはできません。
コード品質をマージリクエストパイプライン上で実行できるようにするには、コード品質rules
またはworkflow: rules
を上書きして、現在のrules
と一致するようにしてください。
使用例:
include:
- template: 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
非公開コンテナ・イメージ・レジストリの使用
GitLab 13.7 で導入されました。
非公開コンテナイメージレジストリを使用することで、イメージのダウンロードにかかる時間を短縮し、外部依存を減らすことができます。コンテナ実行のアーキテクチャはネストしているため、レジストリ接頭辞は、CodeClimate の後続のdocker pull
コマンドで個々のエンジンに受け渡されるように特別に設定する必要があります。
以下の変数で、 必要なすべての画像プルにアドレス指定できます:
-
CODE_QUALITY_IMAGE
:ジョブ環境からアクセス可能な場所であればどこでも構いません。GitLab コンテナレジストリを使って、あなた自身のコピーをホストすることができます。 -
CODECLIMATE_PREFIX
:目的のコンテナイメージレジストリのドメイン。これはCodeClimate CLIでサポートされている設定オプションです。必須です:- 末尾にスラッシュ (
/
) を含めます。 -
https://
のようなプロトコルの接頭辞は含めないでください。
- 末尾にスラッシュ (
-
CODECLIMATE_REGISTRY_USERNAME
:CODECLIMATE_PREFIX
から解析されたレジストリドメインのユーザー名を指定するオプション変数。 -
CODECLIMATE_REGISTRY_PASSWORD
:CODECLIMATE_PREFIX
から解析されたレジストリドメインのパスワードを指定するオプション変数。
include:
- template: 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 Code Quality専用です。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
設定ファイルを使用している場合は、非公開コンテナのレジストリに指定のプラグインを追加する必要があります。
認証付きDockerHubの使用
Code Qualityイメージの代替ソースとしてDockerHubを使用することができます。
前提条件:
- プロジェクトにユーザー名とパスワードを保護されたCI/CD変数として追加します。
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: 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
カスタムツールの実装
カスタムツールをGitLabにインテグレーションして、Code Qualityレポートを提供することができます。
Code Quality レポートのアーティファクト JSON ファイルには、以下のプロパティを持つオブジェクトの配列を含める必要があります:
名前 | 説明 |
---|---|
description | コード品質違反の説明。 |
check_name | このイシューを発生させた静的解析チェックを表す一意の名前。 |
fingerprint | コード品質違反を特定するための一意のフィンガープリント。たとえば MD5 ハッシュなどです。 |
severity | 重大度文字列(info 、minor 、major 、critical 、blocker のいずれか)。 |
location.path | コード品質違反を含むファイルへの相対パス。 |
location.lines.begin またはlocation.positions.begin.line
| コード品質違反が発生した行。 |
カスタムCode Qualityツールを実装するには:
-
.gitlab-ci.yml
ファイルに、コード品質レポートのアーティファクトを生成するジョブを定義します。 - Code Quality レポートのアーティファクトを、Code Climate 仕様のサブセットを実装する 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
}
}
}
]
複数のツールのインテグレーション
Code Qualityは、パイプライン内のすべてのジョブの結果を1つの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
解析プラグインの使用
コードクオリティの機能は、コードクライメート分析プラグインを使用して拡張できます。
例えば、SonarJava アナライザーを使用する場合:
- リポジトリのルートに
.codeclimate.yml
という名前のファイルを追加します。 -
.codeclimate.yml
にプラグインの有効化コードをリポジトリのルートに追加します:
version: "2"
plugins:
sonar-java:
enabled: true
これにより、プロジェクトに含まれるデフォルト.codeclimate.yml
のplugins:
セクションに SonarJava が追加されます。
plugins:
セクションへの変更は、デフォルトの.codeclimate.yml
のexclude_patterns
セクションには影響しません。詳細については、ファイルとフォルダの除外に関するCode Climate のドキュメントを参照してください。
トラブルシューティング
コードが見つからず、パイプラインが常にデフォルト設定で実行されます。
Docker-in-Dockerのソケットバインディング設定で非公開Runnerを使用している可能性があります。非公開ランナーでCode Qualityのパフォーマンスを向上させる “に記載されているように、ワーカーで実行するCode Qualityチェックを設定する必要があります。
デフォルトの設定を変更しても効果はありません。
よくあるイシューは、Code Quality
(GitLab specific)とCode Climate
(Engine used by GitLab)という用語が非常に似ているということです。デフォルトの設定を変更するには、** .codequality.yml
ファイルではなく、.codeclimate.yml
ファイルを **追加する必要があります。間違ったファイル名を使用した場合、デフォルトの.codeclimate.yml
が使用されます。
マージリクエストで Code Quality レポートが表示されません。
これは複数の理由が考えられます:
-
.gitlab-ci.yml
に Code Quality ジョブを追加したばかりです。レポートにはまだ比較対象がないため、情報が表示されません。将来のマージリクエストに比較対象がある場合にのみ表示されます。 - パイプラインがターゲットブランチでコード品質ジョブを実行するように設定されていません。ターゲットブランチからレポートが生成されない場合、マージリクエストブランチのレポートには比較するものがありません。この状況では、
Base pipeline codequality artifact not found
というエラーが発生します。 -
artifacts:expire_in
CI/CD の設定により、コード品質のアーティファクトの有効期限が希望よりも早く切れることがあります。 - ウィジェットはターゲットブランチへの最新コミットのパイプラインを使用します。コードクオリティジョブを実行しないデフォルトブランチへのコミットが行われた場合、マージリクエストウィジェットに比較用のベースレポートがないことがあります。
-
REPORT_STDOUT
環境変数 を使用している場合、レポートファイルは生成されず、マージリクエストには何も表示されません。
コード品質レポートは1つしか表示されませんが、より多くのレポートが定義されています。
Code Qualityは複数のレポートを自動的に結合します。
GitLab 15.6以前では、Code Qualityは(ジョブIDが最も大きい)最新に作成されたジョブのアーティファクトのみを使用していました。それ以前のジョブの Code Quality アーティファクトは無視されました。
RuboCop エラー
Ruby プロジェクトで Code Quality ジョブを利用する際、RuboCop の実行に問題が発生することがあります。例えば、Ruby のバージョンが新しい場合、または古い場合、次のようなエラーが発生することがあります:
/usr/local/bundle/gems/rubocop-0.52.1/lib/rubocop/config.rb:510:in `check_target_ruby':
Unknown Ruby version 2.7 found in `.ruby-version`. (RuboCop::ValidationError)
Supported versions: 2.1, 2.2, 2.3, 2.4, 2.5
これは、チェックエンジンで使用される RuboCop のデフォルトバージョンが、使用中の Ruby バージョンをサポートしていないことが原因です。
プロジェクトで使用している Ruby のバージョンをサポートするカスタムバージョンの RuboCop を使用するには、プロジェクトリポジトリに作成した.codeclimate.yml
ファイル で設定を上書きします。
たとえば、RuboCop リリース0.67 を使用するように指定します:
version: "2"
plugins:
rubocop:
enabled: true
channel: rubocop-0-67
カスタムツールを使用している場合、マージリクエストに Code Quality が表示されません。
カスタムツールを使用しているときにマージリクエストに Code Quality の変更が表示されない場合は、行プロパティがinteger
.
エラー:Could not analyze code quality
エラーが出るかもしれません:
error: (CC::CLI::Analyze::EngineFailure) engine pmd ran for 900 seconds and was killed
Could not analyze code quality for the repository at /code
Code Climateプラグインのいずれかを有効にしていて、Code Quality CI/CDジョブがこのエラーメッセージで失敗する場合は、ジョブがデフォルトのタイムアウト900秒より長くかかっている可能性があります:
この問題を回避するには、.gitlab.-ci.yml
ファイルでTIMEOUT_SECONDS
を高い値に設定します。
使用例:
code_quality:
variables:
TIMEOUT_SECONDS: 3600
Kubernetes CI ExecutorでCode Qualityを使用する場合
Code Qualityを動作させるにはDocker in Dockerの設定が必要です。Kubernetesのexecutorはすでにこれをサポートしています。
Code QualityのジョブがKubernetes Executor上で実行できるようにするには、次のようにします:
- Dockerデーモンとの通信にTLSを使用している場合、Executorは特権モードで実行されている必要があります。さらに、証明書ディレクトリをボリュームマウントとして指定する必要があります。
- Code Qualityジョブの開始前にDinDサービスが完全に起動しない可能性があります。これは、Kubernetes executor for GitLab Runnerトラブルシューティングセクションに記載されている制限です。
エラー:x509: certificate signed by unknown authority
Dockerレジストリにホストされているイメージで、自己署名証明書など信頼できないTLS証明書を使用しているものにCODE_QUALITY_IMAGE
:
$ docker pull --quiet "$CODE_QUALITY_IMAGE"
Error response from daemon: Get https://gitlab.example.com/v2/: x509: certificate signed by unknown authority
これを解決するには、/etc/docker/certs.d
ディレクトリの内部に証明書を置くことで、Dockerデーモンが証明書を信頼するように設定します。
このDockerデーモンはGitLab Code Qualityテンプレートの後続のCode Quality Dockerコンテナに公開され、証明書の設定を適用したい他のコンテナにも公開されるべきです。
Docker
GitLab Runnerの設定にアクセスできる場合は、ディレクトリをボリュームマウントとして追加します。
gitlab.example.com
をレジストリの実際のドメインに置き換えてください。
使用例:
[[runners]]
...
executor = "docker"
[runners.docker]
...
privileged = true
volumes = ["/cache", "/etc/gitlab-runner/certs/gitlab.example.com.crt:/etc/docker/certs.d/gitlab.example.com/ca.crt:ro"]
Kubernetes
GitLab Runnerの設定とKubernetesクラスターにアクセスできる場合は、ConfigMapをマウントすることができます。
gitlab.example.com
をレジストリの実際のドメインに置き換えてください。
-
証明書を含む ConfigMap を作成します:
kubectl create configmap registry-crt --namespace gitlab-runner --from-file /etc/gitlab-runner/certs/gitlab.example.com.crt
-
GitLab Runner
config.toml
を更新して ConfigMap を指定します:[[runners]] ... executor = "kubernetes" [runners.kubernetes] image = "alpine:3.12" privileged = true [[runners.kubernetes.volumes.config_map]] name = "registry-crt" mount_path = "/etc/docker/certs.d/gitlab.example.com/ca.crt" sub_path = "gitlab.example.com.crt"