バージョンごとの非推奨化と削除

GitLab Runner Docker Machine Executorは非推奨

GitLab Runner Docker Machine Executorは非推奨となり、GitLab 20.0でサポート対象機能として製品から完全に削除されます（2027年5月）。Docker Machineの代替となる、Amazon Web Services（AWS）EC2、Google Compute Engine（GCE）、Microsoft Azure仮想マシン（VM）用のGitLab開発プラグインを備えたGitLab Runner Autoscalerが一般提供されています。この発表に伴い、GitLab Runnerチームは、GitLabが管理するDocker Machineフォークに対するコミュニティからのコントリビュートを受け付けなくなり、新たに特定されたバグを解決することもなくなります。

GraphQL APIのGitLab Runnerプラットフォームとセットアップ手順

GitLab Runnerプラットフォームとインストール手順を取得するためのrunnerPlatformsおよびrunnerSetupクエリは非推奨となり、GraphQL APIから削除されます。インストール手順については、GitLab Runnerドキュメントを使用してください。

Runner OperatorのGitLab Runner登録トークン

OpenShiftおよびKubernetes Vanilla Operatorを使用してKubernetesにRunnerをインストールするrunner-registration-tokenパラメータは非推奨となっています。代わりに、認証トークンがRunnerの登録に使用されます。登録トークン、および特定の設定引数のサポートは、今後のGitLabリリースで削除されます。詳細については、新しいRunner登録ワークフローに移行するを参照してください。認証トークンに対して無効になっている設定引数は次のとおりです:

• --locked
• --access-level
• --run-untagged
• --tag-list

これは破壊的な変更です。代わりに、gitlab-runner registerコマンドで認証トークンを使用する必要があります。

GitLab 17.0以降でRunner登録ワークフローが中断されないようにする方法も参照してください。

POST /api/v4/runnersエンドポイントの登録トークンとサーバー側のRunner引数

/api/v4/runnersエンドポイントでのPOSTメソッド操作における登録トークンと特定のRunner設定引数のサポートは、非推奨となります。このエンドポイントは、APIを介してインスタンス、グループ、またはプロジェクトレベルでGitLabインスタンスにRunnerを登録します。今後のGitLabメジャーリリースでは、登録トークンと特定の設定引数のサポートにより、HTTP 410 Goneステータスコードが返されるようになります。詳細については、新しいRunner登録ワークフローに移行するを参照してください。

Runner認証トークンに対して無効になっている設定引数は次のとおりです:

• --locked
• --access-level
• --run-untagged
• --maximum-timeout
• --paused
• --tag-list
• --maintenance-note

これは破壊的な変更です。設定を追加するには、UIでRunnerを作成し、代わりにgitlab-runner registerコマンドでRunner認証トークンを使用する必要があります。

gitlab-runner registerコマンドの登録トークンとサーバー側のRunner引数

Runnerを登録するコマンドgitlab-runner registerの登録トークンと特定の設定引数は、非推奨となります。代わりに、認証トークンがRunnerの登録に使用されます。登録トークン、および特定の設定引数のサポートは、今後のGitLabリリースで削除されます。詳細については、新しいRunner登録ワークフローに移行するを参照してください。認証トークンに対して無効になっている設定引数は次のとおりです:

• --locked
• --access-level
• --run-untagged
• --maximum-timeout
• --paused
• --tag-list
• --maintenance-note

これは破壊的な変更です。設定を追加するには、UIでRunnerを作成し、代わりにgitlab-runner registerコマンドで認証トークンを使用する必要があります。

RunnersRegistrationTokenReset GraphQLミューテーションは非推奨

Runner登録トークンのサポートは非推奨となります。その結果、登録トークンのリセット機能も非推奨となり、今後のGitLabリリースで削除されます。

新しいGitLab Runnerトークンアーキテクチャの一部として、RunnerをGitLabインスタンスにバインドする新しいメソッドが実装されました。詳細については、エピック7633を参照してください。この新しいアーキテクチャでは、Runnerを登録する新しいメソッドが導入され、従来のRunner登録トークンが不要になります。今後のGitLabリリースでは、新しいGitLab Runnerトークンアーキテクチャで実装されたRunner登録メソッドのみがサポートされます。

Runner登録トークンをリセットするREST APIエンドポイントのサポート

Runner登録トークンのサポートは非推奨となります。その結果、登録トークンをリセットするためのREST APIエンドポイントも非推奨となり、今後のGitLabリリースでHTTP 410 Goneステータスコードが返されるようになります。非推奨のエンドポイントは次のとおりです:

• POST /runners/reset_registration_token
• POST /projects/:id/runners/reset_registration_token
• POST /groups/:id/runners/reset_registration_token

新しいGitLab Runnerトークンアーキテクチャの一部として、RunnerをGitLabインスタンスにバインドする新しいメソッドを実装する予定です。作業はこのエピックで計画されています。この新しいアーキテクチャでは、Runnerを登録する新しいメソッドが導入され、従来のRunner登録トークンは不要になります。今後のGitLabリリースでは、新しいGitLab Runnerトークンアーキテクチャによって実装されたRunner登録メソッドのみがサポートされます。

GITLAB_SHARED_RUNNERS_REGISTRATION_TOKENは非推奨

GITLAB_SHARED_RUNNERS_REGISTRATION_TOKEN環境変数は非推奨となります。GitLabは、GitLab 15.8で新しいGitLab Runnerトークンアーキテクチャを導入しました。これにより、Runnerを登録する新しいメソッドが導入され、従来のRunner登録トークンは不要になります。新しいワークフローへの移行に関するガイダンスは、ドキュメントを参照してください。

GitLab Runner HelmチャートのrunnerRegistrationTokenパラメータ

KubernetesにRunnerをインストールするためにGitLab Helmチャートを使用するrunnerRegistrationTokenパラメータは非推奨となります。

新しいGitLab Runnerトークンアーキテクチャの一部として、runnerTokenを利用してRunnerをGitLabインスタンスにバインドする新しいメソッドを実装する予定です。作業はこのエピックで計画されています。

今後のGitLabリリースでは、新しいGitLab Runnerトークンアーキテクチャによって導入されたRunner登録メソッドのみがサポートされます。

Amazon S3署名バージョン2

コンテナレジストリでAmazon S3バケットへのリクエストを認証するために署名バージョン2を使用することは、非推奨となりました。

継続的な互換性とセキュリティを確保するには、署名バージョン4に移行してください。この変更には、S3バケット設定項目の更新と、GitLabコンテナレジストリ設定が署名バージョン4に対応していることの確認が必要です。

移行するには:

1. GitLabコンテナレジストリ設定で、S3ストレージバックエンドの設定を確認します。
2. v4authがfalseに設定されている場合、オプションを削除します。
3. 既存の認証情報がv4認証で動作することを確認します。

これらの変更を加えた後に問題が発生した場合は、AWS認証情報を再生成してみてください。

保護された変数とマルチプロジェクトパイプラインの動作変更

プロジェクトで十分な権限を持つユーザーが保護された変数を安全でないプロジェクトに転送する可能性があるため、この変更により、保護された変数の値が公開されるリスクを最小限に抑えるセキュリティ強化が実現します。

ダウンストリームのパイプラインを介してCI/CD変数を転送することは一部のワークフローで役立ちますが、保護された変数にはさらなる注意が必要です。保護された変数は、特定の保護ブランチまたはタグでのみ使用することを目的としています。

GitLab 19.0では、変数の転送が更新され、保護された変数が特定の状況でのみ渡されるようになります:

• プロジェクトレベルの保護された変数は、同じプロジェクト（子パイプライン）のダウンストリームのパイプラインにのみ転送できます。
• グループレベルの保護された変数は、ソースプロジェクトと同じグループに属するプロジェクトのダウンストリームのパイプラインにのみ転送できます。

パイプラインが保護された変数の転送に依存している場合は、上記の2つのオプションに準拠するように設定を更新するか、保護された変数の転送を避けてください。

CodeClimateベースのCode Qualityスキャンを削除

GitLab 19.0では、CodeClimateベースのCode Qualityスキャンを削除します。この変更は以前、GitLab 18.0で予定されていましたが、延期されました。

その代わりに、CI/CDパイプラインで品質ツールを直接使用し、ツールのレポートをアーティファクトとして提供する必要があります。多くのツールを直接統合する方法はすでにドキュメント化されており、ドキュメントに従ってツールを統合できます。

この変更は、次の方法で実装する予定です:

1. Code-Quality.gitlab-ci.yml CI/CDテンプレートを変更してスキャンを実行しないようにします。現在、このテンプレートはCodeClimateベースのスキャンを実行しています。（19.0以降もテンプレートをinclude（包含）するパイプラインへの影響を軽減するために、テンプレートを削除するのではなく、テンプレートを変更する予定です。）
2. Auto DevOpsの一部として、CodeClimateベースのスキャンを実行しなくなります。

CodeClimateベースのスキャンは、ただちに限定的な更新のみを受け取ります。GitLab 19.0でサポートが終了した後、それ以上の更新は提供しません。ただし、以前に公開されたコンテナイメージを削除したり、カスタムCI/CDパイプラインジョブ定義を使用してそれらを実行する機能を削除したりすることはありません。

詳細については、品質違反のコードをスキャンするを参照してください。

コンプライアンスパイプライン

現在、コンプライアンスまたはセキュリティ関連のジョブがプロジェクトパイプラインで確実に実行されるようにするには、次の2つの方法があります:

• コンプライアンスパイプライン。
• セキュリティポリシー。

プロジェクトのすべてのパイプラインで必要なジョブが確実に実行されるようにするための一元的な場所を提供するために、GitLab 17.3でコンプライアンスパイプラインを非推奨にし、GitLab 19.0でこの機能を削除します。

お客様は、できるだけ早くコンプライアンスパイプラインから新しいパイプライン実行ポリシータイプに移行する必要があります。詳細については、移行ガイドとブログ記事を参照してください。

カバレッジガイドファズテストは非推奨

カバレッジガイドファズテストは非推奨となり、GitLab 18.0以降ではサポートされません。この機能は、GitLab 19.0で完全に削除されます。

カバレッジガイドファズテストでは、いくつかのオープンソースfuzzerがGitLabに統合されました。影響を受ける場合は、オープンソースfuzzerをスタンドアロンアプリケーションとして統合するか、GitLabの高度なSASTのような別のセキュリティ機能に移行することができます。

JavaScriptベンダーライブラリの依存関係スキャン

依存関係をスキャンするGemnasiumアナライザーによって提供される、JavaScriptベンダーライブラリの依存関係スキャン機能は、GitLab 17.9で非推奨になります。

この機能はGemnasiumアナライザーの使用時は引き続き機能しますが、新しい依存関係スキャンアナライザーに移行すると使用できなくなります。詳細については、移行ガイドを参照してください。

代替機能はベンダーライブラリの依存関係スキャンで開発されますが、その提供のタイムラインは設定されていません。

依存関係スキャンをGitLab SBOM脆弱性スキャナーにアップグレード

依存関係スキャン機能は、GitLab SBOM脆弱性スキャナーにアップグレードされます。この変更の一環として、Gemnasiumアナライザー（以前はCI/CDパイプラインで使用）はGitLab 17.9で非推奨になります。

これは、SBOMを使用した依存関係スキャン機能と、依存関係とその関係の検出に重点を置いた新しい依存関係スキャンアナライザーに置き換えられます。このアップグレードは基本的な変更を表しています。新しいシステムは、CIパイプライン内でセキュリティ分析を実行する代わりに、すでに継続的な脆弱性スキャンで使用されているGitLabの組み込みSBOM脆弱性スキャナーを使用します。

GitLab 17.9の時点では、この新機能はベータ版です。したがって、一般公開されるまで、GitLabは引き続きGemnasiumアナライザーをサポートします。新機能の公開後、Gemnasiumアナライザーはサポート終了となります。

このアップグレードでは大幅な変更と機能削除が導入されるため、自動的には実装されません。Gemnasiumアナライザーを使用する既存のCI/CDジョブは、CI設定への影響を防ぐために、デフォルトで引き続き機能します。

簡単に移行できるようにするために、以下に示す詳細な変更をよく確認するとともに、移行ガイドを参照してください。

• CI/CD設定への影響を防ぐために、アプリケーションが安定した依存関係スキャンCI/CDテンプレート（Dependency-Scanning.gitlab-ci.yml）を使用している場合、依存関係スキャンは、Gemnasiumアナライザーに基づく既存のCI/CDジョブのみを使用します。
• アプリケーションが最新の依存関係スキャンCI/CDテンプレート（Dependency-Scanning.latest.gitlab-ci.yml）を使用している場合、依存関係スキャンが、Gemnasiumアナライザーに基づく既存のCI/CDジョブを使用するほか、新しい依存関係スキャンアナライザーが、サポートされているファイルタイプで実行されます。また、すべてのプロジェクトに対して新しい依存関係スキャンアナライザーを強制的に適用することもできます。
• この機能が成熟するにつれて、他の移行パスも検討される可能性があります。
• Gemnasiumアナライザープロジェクトに加えて、対応するコンテナイメージgemnasium、gemnasium-maven、gemnasium-pythonは非推奨となります。これらのイメージは、GitLabコンテナレジストリから削除されません。
• Gemnasiumアナライザーに関連付けられている以下のCI/CD変数も非推奨です。これらの変数は、Gemnasiumアナライザーの使用時は引き続き機能しますが、新しい依存関係スキャンアナライザーに移行した後は有効になりません。変数も別のコンテキストで使用されている場合、非推奨は依存関係スキャン機能にのみ適用されます（たとえば、GOOSとGOARCHは依存関係スキャン機能に固有ではありません）。DS_EXCLUDED_ANALYZERS、DS_GRADLE_RESOLUTION_POLICY、DS_IMAGE_SUFFIX、DS_JAVA_VERSION、DS_PIP_DEPENDENCY_PATH、DS_PIP_VERSION、DS_REMEDIATE_TIMEOUT、DS_REMEDIATE、GEMNASIUM_DB_LOCAL_PATH、GEMNASIUM_DB_REF_NAME、GEMNASIUM_DB_REMOTE_URL、GEMNASIUM_DB_UPDATE_DISABLED、GEMNASIUM_LIBRARY_SCAN_ENABLED、GOARCH、GOFLAGS、GOOS、GOPRIVATE、GRADLE_CLI_OPTS、GRADLE_PLUGIN_INIT_PATH、MAVEN_CLI_OPTS、PIP_EXTRA_INDEX_URL、PIP_INDEX_URL、PIPENV_PYPI_MIRROR、SBT_CLI_OPTS。
• CI/CDコンポーネント: Android、Rust、Swift、Cocoapodsは非推奨です。これらは、サポートされているすべての言語とパッケージマネージャーに対応したメインの依存関係スキャンCI/CDコンポーネントに置き換えられます。
• 脆弱性の解決機能for Yarn projects（（Yarnプロジェクトの場合））は、GitLab 17.9で非推奨になります。この機能はGemnasiumアナライザーの使用時は引き続き機能しますが、新しい依存関係スキャンアナライザーに移行すると使用できなくなります。詳細については、対応する非推奨のお知らせを参照してください。
• JavaScriptベンダーライブラリの依存関係スキャン機能は、GitLab 17.9で非推奨になります。この機能はGemnasiumアナライザーの使用時は引き続き機能しますが、新しい依存関係スキャンアナライザーに移行すると使用できなくなります。詳細については、対応する非推奨のお知らせを参照してください。

監査イベントAPIでキーセットページネーションを適用する

インスタンス、グループ、プロジェクトの監査イベントAPIは現在、オプションのキーセットページネーションをサポートしています。GitLab 18.0では、これらのAPIでキーセットページネーションを適用します。

GitLabの高度なSASTがデフォルトで有効

GitLab 19.0では、SAST CI/CDテンプレートを更新して、GitLab Ultimateを使用しているプロジェクトでデフォルトでGitLabの高度なSASTを有効にするようにします。この変更前は、CI/CD変数GITLAB_ADVANCED_SAST_ENABLEDをtrueに設定した場合にのみ、GitLabの高度なSASTアナライザーが有効になります。この変更は以前、GitLab 18.0で予定されていましたが、延期されました。

高度なSASTは、クロスファイル、クロスファンクションスキャン、新しいルールセットを使用して、より正確な結果を提供します。高度なSASTはサポートされる言語のカバレッジを引き継ぎ、以前のスキャナーでのそれらの言語のスキャンを無効にします。自動化されたプロセスでは、各プロジェクトのデフォルトブランチでの最初のスキャン後に、以前のスキャナーからの結果が引き続き検出される場合、その結果を移行します。

高度なSASTでは、プロジェクトのスキャンが詳細に行われるため、プロジェクトのスキャンに時間がかかる場合があります。必要に応じて、CI/CD変数GITLAB_ADVANCED_SAST_ENABLEDをfalseに設定して、GitLabの高度なSASTを無効にできます。この変数をプロジェクト、グループ、またはポリシーで今すぐ設定すると、GitLab 19.0でデフォルトで高度なSASTが有効になるのを防ぐことができます。

KubernetesとのGitLab Self-Managed証明書ベースのインテグレーション

Kubernetesとの証明書ベースのインテグレーションは非推奨となり、削除されます。

GitLab Self-Managedの場合、GitLab 15.0で機能フラグcertificate_based_clustersを導入しているため、証明書ベースのインテグレーションを有効にしたままにすることができます。ただし、機能フラグはデフォルトで無効になるため、この変更はbreaking change（破壊的な変更）です。

GitLab 19.0では、機能とその関連コードの両方を削除します。19.0で最終的に削除されるまで、このインテグレーションに基づいて構築された機能は、機能フラグを有効にすると引き続き動作します。機能が削除されるまで、GitLabは、発生したセキュリティおよび重大な問題を修正し続けます。

Kubernetesとのより堅牢で安全かつ信頼性の高いインテグレーションを実現するには、Kubernetes用エージェントを使用して、KubernetesクラスターをGitLabに接続することをおすすめします。移行方法はこちらです。

明示的な削除日が設定されていますが、新しいソリューションに機能の同等性が備わるまでは、この機能を削除する予定はありません。削除のブロッカーの詳細については、このイシューを参照してください。

この非推奨化に関する最新情報と詳細については、このエピックをご覧ください。

To-DoアイテムのGraphQL targetフィールドをtargetEntityに置換

特定の状況下では、To-Doアイテムのtargetフィールドがnullになる可能性があります。GraphQLスキーマは現在、このフィールドを非nullとして宣言しています。新しいtargetEntityフィールドはnullにすることができ、非nullのtargetフィールドを置き換えます。currentUser.todos.targetフィールドを使用するGraphQLクエリを更新して、代わりに新しいcurrentUser.todos.targetEntityフィールドを使用するようにします。

GraphQLのdependencyProxyTotalSizeInBytesフィールドの非推奨化

GraphQLを使用して、GitLab依存プロキシで使用されるストレージの量をクエリできます。ただし、dependencyProxyTotalSizeInBytesフィールドは約2ギガバイトに制限されており、依存プロキシにとっては必ずしも十分な大きさではありません。その結果、dependencyProxyTotalSizeInBytesは非推奨となり、GitLab 17.0で削除されます。

代わりに、GitLab 16.1で導入されたdependencyProxyTotalSizeBytesを使用してください。

パイプライン実行ポリシーのinject_ci戦略をinject_policyに置換

パイプライン実行ポリシーのカスタムステージの導入（GitLab 17.9で提供開始）に伴い、非推奨のinject_ciの代わりとなる設定オプションinject_policyが導入されました。

この新しい戦略により、inject_ci戦略を使用した既存のパイプライン実行ポリシーを導入しているユーザーに対して、カスタムステージ機能を段階的にロールアウトできます。

19.0での削除に備えて、inject_ciを使用するすべてのパイプライン実行ポリシーを更新して、代わりにinject_policyを使用するようにします。

パイプラインジョブの制限をコミットAPIに拡張

GitLab 18.0以降、アクティブなパイプラインのジョブの最大数は、コミットAPIを使用してジョブを作成する場合にも適用されます。インテグレーションを見直して、設定済みのジョブ制限内に収まるようにしてください。

パイプラインサブスクリプション

パイプラインサブスクリプション機能は非推奨となり、GitLab 18.0以降はサポートされなくなります。また、GitLab 19.0で完全に削除される予定です。パイプラインサブスクリプションは、アップストリームプロジェクトのタグパイプラインに基づいてダウンストリームパイプラインを実行するために使用されます。

代わりに、別のパイプラインが実行されたときにパイプラインをトリガーするには、パイプライントリガートークンを利用したCI/CDジョブを使用してください。この方法は、パイプラインサブスクリプションよりも信頼性が高く、柔軟性があります。

ContainerRepository GraphQL APIのmigrationStateフィールドを削除

GitLab GraphQL APIのContainerRepositoryTypeのmigrationStateフィールドは、GitLab 18.0で削除されます。この非推奨化は、APIを効率化し、改善するための取り組みの一環です。

この変更に備えるため、ContainerRepositoryTypeとやり取りするGraphQLクエリを確認し、更新することをおすすめします。migrationStateフィールドへの参照を削除し、それに応じてアプリケーションロジックを調整します。

PipelineSchedulePermissionsでGraphQLフィールドtake_ownership_pipeline_scheduleをadmin_pipeline_scheduleに置換

GraphQLフィールドtake_ownership_pipeline_scheduleは非推奨になります。ユーザーがパイプラインスケジュールの所有権を取得できるかどうかを判断するには、代わりにadmin_pipeline_scheduleフィールドを使用します。

コンテナレジストリ通知のthresholdをmaxretriesに置換

レジストリで発生するイベントに応じてWebhook通知を送信するようにコンテナレジストリを設定できます。この設定では、thresholdパラメータとbackoffパラメータを使用して、再試行前に一定期間バックオフするまでに許可される失敗回数を指定します。

問題は、イベントが成功するか、レジストリがシャットダウンされるまで、イベントがメモリに保持されることです。イベントが適切に送信されない場合、レジストリ側でメモリとCPUの使用量が多くなる可能性があるため、これは理想的ではありません。また、イベントのキューに追加された新しいイベントも遅延します。

イベントをドロップする前にイベントを再試行する回数を制御するために、新しいmaxretriesパラメータが追加されました。そのため、イベントがメモリに永久に保持されないようにするために、maxretriesを優先して、thresholdパラメータは非推奨となりました。

Yarnプロジェクトでの依存関係スキャンの脆弱性を解決する

依存関係スキャンのためにGemnasiumアナライザーによって提供される、Yarnプロジェクトの脆弱性の解決機能は、GitLab 17.9で非推奨となりました。

この機能はGemnasiumアナライザーの使用時は引き続き機能しますが、新しい依存関係スキャンアナライザーに移行すると使用できなくなります。詳細については、移行ガイドを参照してください。

代替機能は自動修正ビジョンの一部として計画されていますが、その提供のタイムラインは設定されていません。

リソースオーナーパスワード認証情報付与は非推奨

リソースオーナーパスワード認証情報（ROPC）付与をOAuthフローとして使用することは非推奨となり、GitLab 19.0では完全にサポートされなくなります。インスタンス内でクライアント認証情報のみを使用してこの付与タイプを利用できるようにするために、管理者が有効または無効にできる設定を追加しました。これにより、クライアント認証情報なしでROPCの使用をオプトアウトしたいユーザーは、19.0より前にオプトアウトできます。ROPCは19.0で完全に削除され、それ以降はクライアント認証情報を使用しても利用できなくなります。

GitLabは、セキュリティ上の理由から、2025年4月8日以降、GitLab.comでのROPCのクライアント認証を必須にしました。ROPCサポートを完全に削除すると、OAuth RFCバージョン2.1に沿ったセキュリティが維持されます。

Slack通知インテグレーション

すべてのSlack機能をGitLab for Slackアプリに統合しているため、Slack通知インテグレーションは非推奨となりました。Slackワークスペースへの通知を管理するには、GitLab for Slackアプリを使用してください。

パブリックAPIのサブスクリプション関連APIエンドポイントは非推奨

パブリックREST APIの次のエンドポイントが削除されます:

• PUT /api/v4/user/:id/credit_card_validation
• POST /api/v4/namespaces/:namespace_id/minutes
• PATCH /api/v4/namespaces/:previous_namespace_id/minutes/move/:target_namespace_id
• GET /api/v4/namespaces/:namespace_id/subscription_add_on_purchase/:id
• PUT /api/v4/namespaces/:namespace_id/subscription_add_on_purchase/:id
• POST /api/v4/namespaces/:namespace_id/subscription_add_on_purchase/:id
• POST /api/v4/namespaces/:id/gitlab_subscription
• PUT /api/v4/namespaces/:id/gitlab_subscription
• PUT /api/v4/namespaces/:id

これらのエンドポイントは、サブスクリプションポータルによってGitLab.comのサブスクリプション情報を管理するために使用されていました。それらの使用法は、今後のセルアーキテクチャをサポートするために、JWT認証を備えた内部エンドポイントに置き換えられました。パブリックAPIのエンドポイントは、誤って再度使用されないように、また機能に構成ドリフトが生じた場合のメンテナンスの負担を軽減するために削除されています。

これらは内部で使用されていたエンドポイントであるため、この変更の結果として、何らかの影響を受けることはないはずです。

作業アイテムIIDを優先してGitLabの従来の要件IIDは非推奨

要件を作業アイテムタイプに移行した結果、新しいIIDに移行します。GitLab 18.0で従来のIIDおよび既存の形式のサポートが終了するため、ユーザーは新しいIIDの使用を開始する必要があります。従来の要件IIDは、GitLab 18.0で削除されるまで引き続き利用できます。

Project.services GraphQLフィールドは非推奨

Project.services GraphQLフィールドは非推奨です。代わりに、イシュー389904でProject.integrationsフィールドが提案されています。

heroku/builder:22イメージは非推奨

Auto DevOpsビルドプロジェクトでクラウドネイティブビルドパック（CNB）ビルダーイメージがheroku/builder:24に更新されました。ほとんどの場合、変更によって混乱が発生することはないと考えていますが、Auto DevOpsの一部のユーザー、特にAuto Buildのユーザーにとっては、これは破壊的な変更となる可能性があります。ワークロードの影響をより深く理解するには、次を確認してください:

• Heroku-24スタックのリリースノート
• Heroku-24スタックのアップグレードノート
• Herokuスタックパッケージ

これらの変更は、Auto DevOpsのAuto Buildステージによって提供されるauto-build-imageをパイプラインが使用している場合に影響を及ぼします。

CI/CDコンポーネントをカタログにリリースするためのツールを更新

GitLab 18.0以降、CI/CDコンポーネントをカタログにリリースする内部プロセスが変更されます。推奨されるCI/CDコンポーネントリリースプロセスを使用している場合（releaseキーワードとregistry.gitlab.com/gitlab-org/release-cli:latestコンテナイメージを使用）、変更を加える必要はありません。このコンテナイメージのlatestバージョン（v0.24.0）には、glab v1.58.0が含まれており、GitLab 18.0以降のCI/CDカタログへのすべてのリリースに使用されます。その他の場合は、次のようになります:

• コンテナイメージを特定のバージョンに固定する必要がある場合は、v0.24.0以降（registry.gitlab.com/gitlab-org/release-cli:v0.24.0）を使用して、リリースプロセスでglabが利用可能であることを確認してください。
• RunnerにRelease CLIツールを手動でインストールした場合は、それらのRunnerにglab v1.58.0以降をインストールする必要があります。

CI/CDジョブトークンをJWT標準に更新

GitLab 19.0では、CI/CDジョブトークンが文字列トークン形式からJWTトークン形式に切り替わります。この変更は、すべてのプロジェクトの新規および既存のCI/CDジョブトークンに影響を及ぼします。問題が発生した場合は、GitLab 20.0がリリースされるまで、CI/CDトークンにレガシー形式を使用できます。

既知の問題:

1. GitLab RunnerのAWS Fargate Drive 0.5.0以前のバージョンは、JWT標準と互換性がありません。file name too longエラーが返され、ジョブが失敗します。AWS Fargateカスタムexecutorドライバーのユーザーは、0.5.1以降にアップグレードする必要があります。移行手順については、ドキュメントを参照してください。
2. 非常に長いJWT標準は、一部のCI/CD設定ファイルで使用されているecho $CI_JOB_TOKEN | base64コマンドを壊します。代わりにecho $CI_JOB_TOKEN | base64 -w0コマンドを使用できます。

ZenTaoのインテグレーション

ZenTao製品のインテグレーションは非推奨となっていて、JiHu GitLabのコードベースに移行します。

Gitalyのbin_pathおよびuse_bundled_binaries設定オプション

Gitalyでbin_pathおよびuse_bundled_binaries設定オプションを使用するためのサポートは非推奨となり、GitLab 19.0で削除されます。

Gitalyが提供するGitバイナリが、Gitを実行する際にサポートされる唯一の方法になります。

ciJobTokenScopeAddProject GraphQLミューテーションは非推奨

GitLab 18.0のCI/CDジョブトークンの今後のデフォルト動作の変更に伴い、関連するciJobTokenScopeAddProject GraphQLミューテーションを非推奨とし、ciJobTokenScopeAddGroupOrProjectを推奨します。

scanResultPolicies GraphQLフィールドは非推奨

16.10では、スキャン結果ポリシーの名前がマージリクエスト承認ポリシーに変更され、ポリシータイプに対するスコープと機能の変更がより正確に反映されるようになりました。

その結果、GraphQLエンドポイントを更新しました。scanResultPoliciesの代わりにapprovalPoliciesを使用してください。

workflow:rulesテンプレート

workflow:rulesテンプレートは非推奨となり、使用は推奨されなくなっています。これらのテンプレートを使用すると、パイプラインの柔軟性が大幅に制限され、新しいworkflow機能が使いにくくなります。

これは、CI/CDテンプレートから移行し、CI/CDコンポーネントを優先するための小さな一歩です。CI/CDカタログで代替手段を検索するか、パイプラインに明示的にworkflow:rulesを追加できます。

Ubuntu 20.04のLinuxパッケージ

Ubuntu 20.04のUbuntu標準サポートは、2025年5月に終了します。

したがって、GitLab 18.9以降、Linuxパッケージインストール用のUbuntu 20.04ディストリビューションのパッケージは提供されなくなります。GitLab 18.8が、Ubuntu 20.04用のLinuxパッケージを含む最後のGitLabバージョンになります。継続的なサポートを受けるには、Ubuntu 22.04にアップグレードする必要があります。

静的コンプライアンス違反レポート

既存の静的コンプライアンス違反レポートは、GitLab 18.2で非推奨となり、GitLab 18.8で削除されます。

静的コンプライアンス違反レポートを置き換えるために、次のようにしました:

• GitLab 17.11では、カスタムコンプライアンスフレームワークをリリースしました。
• GitLab 18.2では、新しい動的コンプライアンス違反レポートをリリースしました。

これらの機能は静的な違反レポートと同じ機能をすべて提供しますが、必要な違反を設定することもできます。

GitLab 18.8では、要件とコントロールに関するより正確なレポート作成のために、コンプライアンスフレームワークを使用して、静的コンプライアンス違反レポートを動的レポートに置き換えます。

GitLabチャートのBitnami PostgreSQLおよびRedisイメージ

GitLab Helmチャートのデフォルト設定は、PostgreSQLおよびRedisのBitnamiチャートとコンテナイメージに依存しています。Bitnamiは、2025年9月29日にこれらのイメージをFreeカタログから廃止します。イメージを一時的に停止させるブラウンアウトは、2025年8月28日に開始されました。

GitLabチャートは、デモおよびテスト目的でのみBitnamiのPostgreSQLおよびRedisをバンドルします。これらは、サポートされるGitLabリファレンスアーキテクチャの一部ではありません。リファレンスアーキテクチャを使用している場合、または別のベンダーのパッケージまたはイメージを使用して外部PostgreSQLおよびRedisをデプロイしている場合は、この変更によるnot impacted（影響を受けません）。

一時的な解決策として、GitLabはチャート設定をBitnamiレガシーリポジトリに移行しました。ただし、パッチが適用されていないGitLabチャート環境（GitLab 17.11、GitLab 18.0.5）。GitLab 18.1.4、およびGitLab 18.2.1以前）は、非推奨のBitnamiリポジトリからイメージをプルし続け、9月29日以降にデプロイの失敗を引き起こし、ブラウンアウト段階でデプロイの失敗を引き起こす可能性があります。

影響を受けるGitLabチャート設定を実行している場合は、次のいずれかを実行する必要があります:

• サポートされるGitLabリファレンスアーキテクチャに移行します。
• パッチが適用されたチャートバージョンにアップグレードします。
• チャートの値でレガシーリポジトリを設定します。例については、[マージリクエスト4421][https://gitlab.com/gitlab-org/charts/gitlab/-/merge_requests/4421]を参照してください。

今後、GitLabチャートからBitnamiコンポーネントを完全に置き換えるか、または削除するための代替手段を評価します。詳細については、Bitnamiからの公式発表を参照してください。

cert-manager Helmチャートの更新

新しいcert-managerチャートのスキーマ検証を有効にするために、GitLab Helmチャートのcertmanager.install値は非推奨となり、installCertmanagerが推奨されます。スキーマ定義は、GitLabチャートのcertmanagerセクション内に追加したプロパティを受け入れません。

GitLab 18.3（GitLabチャート9.3）では、非推奨の値を削除し、バンドルされたcert-managerを更新します。

以前にcertmanager.install設定を使用したことがある場合:

1. certmanager.installの値をinstallCertmanagerに転送します。
2. certmanager.install設定を完全に削除します。

cert-managerのリリースノートも確認してください:

• リリースノート1.12 - 1.16
• リリースノート1.17

APIディスカバリがデフォルトでブランチパイプラインを使用

GitLab 18.0では、APIディスカバリのCI/CDテンプレート（API-Discovery.gitlab-ci.yml）のデフォルトの動作を更新します。

GitLab 18.0より前では、このテンプレートは、MRが開いているときに、ジョブをデフォルトでマージリクエスト（MR）パイプラインで実行するように設定します。GitLab 18.0以降は、このテンプレートの動作を、他のASTスキャナーの安定版テンプレートエディションの動作に合わせます:

• デフォルトでは、テンプレートはブランチパイプラインでスキャンジョブを実行します。
• MRが開いているときにMRパイプラインを使用するには、CI/CD変数AST_ENABLE_MR_PIPELINES: trueを設定してください。この新しい変数の実装は、イシュー410880で追跡されます。

アプリケーションセキュリティテストアナライザーのメジャーバージョンの更新

GitLab 18.0では、すべてのアプリケーションセキュリティテストアナライザーのコンテナイメージのメジャーバージョンを更新します。

デフォルトの組み込みテンプレートを使用していない場合、またはアナライザーのバージョンをピン留めしている場合は、固定バージョンを削除するか、最新のメジャーバージョンに更新するために、CI/CDジョブ定義を更新する必要があります。

GitLab 17.0からGitLab 17.11のユーザーは、GitLab 18.0のリリースまでアナライザーの更新を引き続き利用できます。その後、新しく修正されたバグとリリースされた機能は、アナライザーの新しいメジャーバージョンでのみリリースされます。ただし、公開されているコンテナイメージをコンテナレジストリから削除することはありません。

メンテナンスポリシーに従い、バグや機能を非推奨バージョンにバックポートすることはありません。必要に応じて、セキュリティパッチは、最新の3つのマイナーリリース内でバックポートされます。

具体的には、GitLab 18.0のリリース後、次のアナライザーは更新されなくなります:

• GitLabの高度なSAST: バージョン1
• コンテナスキャン: バージョン7
• Gemnasium: バージョン5
• DAST: バージョン5
• DAST API: バージョン4
• ファズAPI: バージョン4
• IaCスキャン: バージョン5
• パイプラインシークレット検出: バージョン6
• 静的アプリケーションセキュリティテスト（SAST）: すべてのアナライザーのバージョン5
  • kics
  • kubesec
  • pmd-apex
  • semgrep
  • sobelow
  • spotbugs

今後および開始済みのマイルストーンフィルターの動作変更

「今後」および「開始済み」の特別なフィルターの動作は、今後のGitLabメジャーリリース18.0で変更される予定です。両方のフィルターの新しい動作は、イシュー429728で概説されています。

この変更はGitLab REST APIには影響しません。GitLab REST APIは、引き続き既存のマイルストーンフィルタリングロジックを使用します。GitLab GraphQL APIは、新しいフィルタリングロジックに準拠するように更新されます。

CI/CDジョブトークン - 認証されたグループとプロジェクト許可リストの適用

GitLab 15.9で導入された認証されたグループとプロジェクト設定（GitLab 16.3でLimit access to this project（このプロジェクトへのアクセスを制限）から名称変更）を使用すると、プロジェクトへのCI/CDジョブトークンアクセスを制御できます。このプロジェクトと許可リスト内のグループとプロジェクトのみに設定すると、許可リストに追加されたグループまたはプロジェクトのみがジョブトークンを使用してプロジェクトにアクセスできます。

GitLab 15.9より前に作成されたプロジェクトでは、許可リストはデフォルトで無効になっており（全グループとプロジェクトアクセス設定が選択されています）、どのプロジェクトからでもジョブトークンアクセスを許可していました。許可リストは現在、すべての新しいプロジェクトでデフォルトで有効になっています。古いプロジェクトでは、許可リストが無効になっているか、アクセスを無制限にするために全グループとプロジェクトオプションを手動で選択している可能性があります。

GitLab 17.6以降、GitLab Self-ManagedおよびGitLab Dedicatedインスタンスの管理者は、オプションでこのより安全な設定をすべてのプロジェクトに対して適用できます。この設定では、プロジェクトメンテナーが全グループとプロジェクトを選択できなくなります。この変更により、プロジェクト間のセキュリティレベルが向上します。

GitLab 18.0では、このインスタンス設定はGitLab.com、GitLab Self-Managed、GitLab Dedicatedでデフォルトで有効になります。GitLab Self-ManagedおよびGitLab Dedicatedの管理者はGitLab 18.0にアップグレードした後、設定を無効にして、アップグレード前の動作を復元できます。GitLab Self-ManagedおよびGitLab Dedicatedでは、GitLab 18.0でプロジェクト設定は変更されませんが、インスタンス設定のステータスはインスタンス上のすべてのプロジェクトに影響します。

この変更に備えて、クロスプロジェクト認証にジョブトークンを使用するプロジェクトメンテナーは、プロジェクトの認証されたグループとプロジェクト許可リストを入力する必要があります。次に、設定をこのプロジェクトと許可リスト内のグループとプロジェクトのみに変更する必要があります。

CI/CDジョブトークンで認証してプロジェクトにアクセスする必要があるプロジェクトを特定するために、GitLab 17.6では、プロジェクトへのジョブトークン認証を追跡する方法も導入しました。そのデータを使用して、CI/CDジョブトークン許可リストを設定できます。

GitLab 17.10では、ジョブトークン認証ログからCI/CDジョブトークン許可リストを自動的に設定する移行ツールを導入しました。GitLab 18.0で許可リストが一般的に適用される前に、この移行ツールを使用して許可リストを設定し、使用することをおすすめします。GitLab 18.0では、以前に発表されたように、GitLab.comで許可リストの自動設定と適用が行われます。

この移行ツールは、GitLab 18.6で削除されます。

CI/CDジョブトークン - Limit access from your project（プロジェクトからのアクセスを制限）設定の削除

GitLab 14.4では、より安全にするために、プロジェクトのCI/CDジョブトークン（CI_JOB_TOKEN）_からの_アクセスを制限する設定を導入しました。この設定は、Limit CI_JOB_TOKEN access（CI_JOB_TOKENアクセスを制限）と呼ばれていました。GitLab 16.3では、明確にするために、この設定の名前をLimit access from this project（このプロジェクトからのアクセスを制限）に変更しました。

GitLab 15.9では、認証されたグループとプロジェクトと呼ばれる代替設定を導入しました。この設定は、許可リストを使用して、プロジェクト_への_ジョブトークンアクセスを制御します。この新しい設定は、元の設定よりも大幅に改善されています。最初のイテレーションはGitLab 16.0で非推奨となり、GitLab 18.0で削除される予定です。

Limit access from this project（このプロジェクトからのアクセスを制限）設定は、すべての新しいプロジェクトでデフォルトで無効になっています。GitLab 16.0以降では、この設定をプロジェクトで無効にした後、再度有効にすることはできません。代わりに、認証されたグループとプロジェクト設定を使用して、プロジェクトへのジョブトークンアクセスを制御します。

DASTのdast_devtools_api_timeout変数のデフォルト値の低下

DAST_DEVTOOLS_API_TIMEOUT環境変数は、DASTスキャンがブラウザからの応答を待機する時間を決定します。GitLab 18.0より前は、変数の静的な値は45秒でした。GitLab 18.0以降、DAST_DEVTOOLS_API_TIMEOUT環境変数は動的な値を持ち、これは他のタイムアウト設定に基づいて計算されます。ほとんどの場合、45秒の値は、多くのスキャナー機能のタイムアウト値を上回っていました。動的に計算された値により、DAST_DEVTOOLS_API_TIMEOUT変数が適用されるケースが増え、より有用になります。

潜在的な影響を軽減するために、このスケジュールに従ってデフォルトのタイムアウト値を段階的に調整します:

依存プロキシトークンスコープの適用

コンテナの依存プロキシは、スコープを検証することなく、パーソナルアクセストークンまたはグループアクセストークンを使用して、docker loginおよびdocker pullリクエストを受け入れます。

GitLab 18.0では、依存プロキシには、認証にread_registryとwrite_registryの両方のスコープが必要です。この変更後、これらのスコープを持たないトークンを使用した認証試行は拒否されます。

これは破壊的な変更です。アップグレードする前に、必要なスコープを持つ新しいアクセストークンを作成し、これらの新しいトークンを使用してワークフロー変数とスクリプトを更新します。

この変更がGitLab Self-Managedインスタンスに与える影響を評価するには、GitLab 17.10以降で認証ログを監視して、警告メッセージがないか確認します。auth_json.logファイルで、Dependency proxy missing authentication abilitiesを含むエントリを探します。GitLab HelmチャートまたはGitLab Dedicatedを使用している場合、ログはcomponent: "gitlab"およびsubcomponent: "auth_json"にあります。これらのエントリは、必要なスコープなしでトークンを使用した認証試行を示しており、GitLab 18.0へのアップグレード後は失敗します。

Terraform CI/CDテンプレートを非推奨化

Terraform CI/CDテンプレートは非推奨となり、GitLab 18.0で削除されます。これは、次のテンプレートに影響します:

• Terraform.gitlab-ci.yml
• Terraform.latest.gitlab-ci.yml
• Terraform/Base.gitlab-ci.yml
• Terraform/Base.latest.gitlab-ci.yml

GitLab 16.9では、非推奨についてユーザーに通知する新しいジョブがテンプレートに追加されました。この警告は、影響を受けるパイプラインでプレースホルダージョブを使用してdeprecated-and-will-be-removed-in-18.0ジョブを上書きすることでオフにできます。

GitLabは、ジョブイメージ内のterraformバイナリを、BSLに基づいてライセンスされたバージョンに更新できません。

Terraformの使用を続行するには、テンプレートとTerraformイメージのクローンを作成し、必要に応じてメンテナンスします。GitLabには、カスタムビルドイメージへの移行に関する詳細な手順が用意されています。

代替として、GitLab.comで新しいOpenTofu CI/CDコンポーネントを使用するか、GitLab Self-Managedで新しいOpenTofu CI/CDテンプレートを使用することをおすすめします。GitLab Self-ManagedではCI/CDコンポーネントをまだ利用できませんが、イシュー#415638ではこの機能を追加することが提案されています。CI/CDコンポーネントがGitLab Self-Managedで利用可能になると、OpenTofu CI/CDテンプレートは削除されます。

新しいOpenTofu CI/CDコンポーネントの詳細をご覧ください。

ライセンスメタデータ形式V1を非推奨化

ライセンスメタデータ形式V1データセットは非推奨となっており、GitLab 18.0で削除されます。

package_metadata_synchronization機能フラグを有効にしているユーザーは、GitLab 16.3以降にアップグレードし、機能フラグ設定を削除することをおすすめします。

NamespaceProjectSortEnum GraphQL APIでのSTORAGE enumの非推奨化

GitLab GraphQL APIのNamespaceProjectSortEnumのSTORAGE enumは、GitLab 18.0で削除されます。

この変更に備えるため、NamespaceProjectSortEnumとやり取りするGraphQLクエリを確認し、更新することをおすすめします。STORAGEフィールドへの参照をEXCESS_REPO_STORAGE_SIZE_DESCに置き換えてください。

ProjectMonthlyUsageType GraphQL APIでのnameフィールドの非推奨化

GitLab GraphQL APIのProjectMonthlyUsageTypeのnameフィールドは、GitLab 18.0で削除されます。

この変更に備えるため、ProjectMonthlyUsageTypeとやり取りするGraphQLクエリを確認し、更新することをおすすめします。nameフィールドへの参照をproject.nameに置き換えてください。

GitLab NGINXチャートコントローラーイメージv1.3.1のフォールバックサポート

GitLab 17.6（Helmチャート8.6）では、GitLabチャートでデフォルトのNGINXコントローラーイメージがバージョン1.3.1から1.11.2に更新されました。この新しいバージョンでは、GitLab NGINXチャートに追加された新しいRBACルールが必要になるため、最終的にこれらのルールを作成する必要があります。この変更は、以下にもバックポートされます:

• GitLab 17.5.1（Helmチャート8.5.1）
• GitLab 17.4.3（Helmチャート8.4.3）
• GitLab 17.3.6（Helmチャート8.3.6）

独自のNGINX RBACルールを管理している場合は、nginx-ingress.rbac.createをfalseに設定していることになります。その場合、GitLab 17.3（Helmチャート8.3）からGitLab 17.11（Helmチャート8.11）までは、その変更を検出し、古いコントローラーイメージを使用するフォールバックメカニズムがあるため、RBACルールを変更する必要はありません。

GitLab 18.0（Helmチャート9.0）以降、このフォールバックメカニズムは削除されるため、新しいコントローラーイメージが使用され、新しいRBACルールが存在する必要があります。

GitLab 18.0での適用前に、新しいNGINXコントローラーイメージを利用する場合は:

1. 新しいRBACルールをクラスターに追加します（例を参照）。
2. nginx-ingress.controller.image.disableFallbackをtrueに設定します。

詳細については、チャートリリースページを参照してください。

従来のWeb IDEは非推奨

Vueベースの従来のGitLab Web IDE実装は、GitLabから削除されます。この変更は、GitLab 15.11以降でデフォルトのWeb IDEエクスペリエンスとなっているGitLab VSCode ForkベースのWeb IDEへの移行が成功したことによるものです。

この削除は、従来のWeb IDE実装に引き続きアクセスしているユーザーに影響します。

この削除に備えるため、GitLabインスタンスでvscode_web_ide機能フラグが以前に無効にされていた場合は、このフラグを有効にしてください。

ポリシーごとに許可されるスキャン実行ポリシーアクションの数を制限

ポリシーごとに許可される最大スキャン実行ポリシーアクションに対して、新しい制限が追加されました。この変更は、17.4で導入され、機能フラグscan_execution_policy_action_limitとscan_execution_policy_action_limit_groupの背後に配置されました。有効にすると、スキャン実行ポリシーの最初のアクション10個のみが処理されます。

制限を追加することで、セキュリティポリシーのパフォーマンスとスケーラビリティを確保できます。

追加のアクションが必要な場合は、既存のポリシーを10個以下のアクションに制限します。次に、セキュリティポリシープロジェクトごとに5つのスキャン実行ポリシーの制限内で、追加のアクションを含む新しいスキャン実行ポリシーを作成します。

GitLab Self-ManagedおよびGitLab Dedicated管理者の場合は、scan_execution_policies_action_limitアプリケーション設定でカスタム制限を設定できます。

スキャン実行ポリシーでの制限付きscanアクション

GitLab.comでは、GitLab 18.0以降、スキャン実行ポリシーは、ポリシーごとに10個のscanアクションに制限されています。制限を超える新しいポリシーを作成することはできず、制限を超える既存のポリシーを更新することもできません。制限を超える既存のポリシーの場合、ポリシーの最初の10個のscanアクションのみが実行されます。

GitLab Self-ManagedおよびGitLab Dedicatedインスタンスでは、scan_execution_policies_action_limitアプリケーション設定でカスタム制限を設定できます。これらのインスタンスの制限は、デフォルトでゼロアクションになります。10個のアクションの制限を設定することをおすすめします。

Prometheusサブチャートのメジャーアップデート

GitLab 18.0およびGitLabチャート9.0では、Prometheusサブチャートが15.3から27.3に更新されます。この更新に伴い、Prometheus 3がデフォルトで提供されます。

アップグレードを実行するには、手動による手順が必要です。Alertmanager、Node Exporter、またはPushgatewayが有効になっている場合は、Helmの値も更新する必要があります。

詳細については、移行ガイドを参照してください。

GitLab.comでの脆弱性に対する新しいデータ保持制限

GitLab 18.0では、システムパフォーマンスと信頼性を向上させるために、GitLab.com Ultimateのお客様向けに新しいデータ保持制限を導入します。データ保持制限は、脆弱性データの保存期間に影響します。12か月以上経過し、更新されていない脆弱性は、コールドストレージアーカイブに移送されます。これらのアーカイブは、次のようになります:

• GitLab UIからアクセスしてダウンロードできます。
• 3年間保持されます。
• 3年後に完全に削除されます。

PostgreSQL 14および15はサポート終了

GitLabは、PostgreSQLの年間アップグレードケイデンスに従います。

PostgreSQL 14および15のサポートは、GitLab 18.0で削除される予定です。GitLab 18.0では、PostgreSQL 16が最小要件のPostgreSQLバージョンになります。

PostgreSQL 14および15は、GitLab 17のリリースサイクル全体でサポートされます。PostgreSQL 16は、GitLab 18.0に先立ってアップグレードする必要があるインスタンスでもサポートされます。

Omnibus Linuxパッケージを使用してインストールした単一のPostgreSQLインスタンスを実行している場合、17.11で自動アップグレードが試行される場合があります。アップグレードに対応できるように、十分なディスク容量があることを確認してください。詳細については、Omnibusデータベースのドキュメントを参照してください。

Raspberry Pi 32ビットパッケージは非推奨

GitLabバージョン18.0以降、Raspberry Piの32ビットパッケージは提供されなくなります。64ビットのRaspberry Pi OSを使用して、arm64 Debianパッケージをインストールする必要があります。32ビットOSでのデータのバックアップと64ビットOSへの復元については、PostgreSQLが動作しているオペレーティングシステムをアップグレードするを参照してください。

allowed_pull_policiesにないコンテナイメージプルポリシーを拒否する

設定されているすべてのプルポリシーは、Runnerのconfig.tomlファイルで指定されたallowed_pull_policies設定に存在する必要があります。そうでない場合、incompatible pull policyエラーが発生し、ジョブは失敗します。

現在の実装では、複数のプルポリシーが定義されている場合、他のポリシーが含まれていなくても、少なくとも1つのプルポリシーがallowed-pull-policiesのポリシーと一致すると、ジョブは合格します。

GitLab 18.0では、いずれかのプルポリシーがallowed-pull-policiesのポリシーと一致しない場合にのみ、ジョブは失敗します。ただし、現在の動作とは異なり、ジョブはallowed-pull-policiesにリストされているプルポリシーのみを使用します。この違いにより、現在合格になっているジョブがGitLab 18.0では失敗する可能性があります。

duoProAssignedUsersCount GraphQLフィールドを削除

18.0では、duoProAssignedUsersCount GraphQLフィールドを削除します。ユーザーがaiMetrics APIでこのフィールドを使用している場合に問題が発生する可能性があり、代わりにduoAssignedUsersCountを使用できます。この削除は、GitLab Duo ProとDuoの両方のシートが割り当てられたユーザーをカウントするための修正の一部です。

add_on_purchase GraphQLフィールドをadd_on_purchasesに置換

GraphQLフィールドadd_on_purchaseはGitLab 17.4で非推奨となり、GitLab 18.0で削除されます。代わりにadd_on_purchasesフィールドを使用します。

ネームスペースadd_on_purchase GraphQLフィールドをadd_on_purchasesに置換

ネームスペースGraphQLフィールドadd_on_purchaseはGitLab 17.5で非推奨となり、GitLab 18.0で削除されます。代わりに、ルートadd_on_purchasesフィールドを使用します。

SUSE Linux Enterprise Server 15 SP2のサポート

SUSE Linux Enterprise Server（SLES）15 SP2の長期サービスとサポート（LTSS）は、2024年12月に終了しました。

したがって、Linuxパッケージインストール用のSLES SP2ディストリビューションはサポートされなくなります。継続的なサポートを受けるには、SLES 15 SP6にアップグレードする必要があります。

ciJobTokenScopeRemoveProjectのdirection GraphQL引数は非推奨

ciJobTokenScopeRemoveProjectミューテーションのdirection GraphQL引数は非推奨になります。GitLab 15.9で発表されたデフォルトのCI/CDジョブトークンスコープの変更に続いて、direction引数はデフォルトでINBOUNDになり、GitLab 17.0でOUTBOUNDは有効ではなくなります。GitLab 18.0でdirection引数を削除します。

プロジェクトのトークンアクセスの方向を制御するためにdirection引数でOUTBOUNDを使用している場合、ジョブトークンを使用するパイプラインには認証に失敗するリスクがあります。パイプラインが引き続き期待どおりに実行されるようにするには、プロジェクトの許可リストに他のプロジェクトを明示的に追加する必要があります。

APIでのノートの機密性の切替

RESTおよびGraphQL APIを使用したノートの機密性の切替は非推奨となります。ノートの機密属性の更新は、いかなる手段でもサポートされなくなっています。エクスペリエンスを簡素化し、非公開情報が意図せずに公開されるのを防ぐために、これを変更しています。

Gitalyストレージを設定するためのgit_data_dirs

git_data_dirsを使用してLinuxパッケージインスタンスのGitalyストレージを設定するためのサポートは、16.0以降で非推奨になっていて、18.0で削除されます。

移行手順については、git_data_dirsからの移行を参照してください。

クライアント認証情報のないOAuth ROPC付与は非推奨

GitLab.comでは、2025年4月8日の時点で、OAuthリソースオーナーパスワード認証情報（ROPC）OAuth付与にクライアント認証が必要です。ROPCは、OAuthワーキンググループによってRFCバージョン2.1で省略されました。クライアント認証情報のない既存のROPCインテグレーションは、この日以降、サービスが中断されます。中断が発生した場合は、期限までにクライアント認証情報を含めるようにインテグレーションを更新してください。詳細については、ブログをご覧ください。

/repository/tree REST APIエンドポイントのエラー処理が404を返す

GitLab 17.7では、リストリポジトリツリーAPIエンドポイント/projects/:id/repository/treeのエラー処理動作は、要求されたパスが見つからない場合に更新されます。エンドポイントは、ステータスコード404 Not Foundを返すようになりました。以前は、ステータスコードは200 OKでした。

この変更はGitLab 16.5のGitLab.comで有効になり、GitLab 17.7のSelf-Managedインスタンスで使用できるようになります。

実装が、存在しないパスに対して空の配列を持つ200ステータスコードを受信することに依存している場合は、新しい404応答を処理するようにエラー処理を更新する必要があります。

Kubernetesのエージェントのオプションca-cert-fileの名前変更

Kubernetes向けGitLabエージェント（agentk）では、--ca-cert-fileコマンドラインオプションとそれに対応するconfig.caCert Helmチャートの値の名前がそれぞれ--kas-ca-cert-fileとconfig.kasCaCertに変更されました。

古い--ca-cert-fileオプションとconfig.caCertオプションは非推奨になり、GitLab 17.0で削除されます。

HerokuishのAuto DevOpsサポートは非推奨

Cloud Native Buildpacksを優先して、HerokuishのAuto DevOpsサポートは非推奨になります。HerokuishからCloud Native Buildpacksにビルドを移行する必要があります。GitLab 14.0からは、Auto BuildはデフォルトでCloud Native Buildpacksを使用します。

Cloud Native Buildpacksは自動テストをサポートしていないため、Auto DevOpsの自動テスト機能も非推奨です。

ダッシュ（-）文字を含む自動生成されたMarkdownアンカーリンク

GitLabでは、すべての見出しに対して自動的にアンカーリンクが作成されるため、ユーザーは、MarkdownドキュメントまたはWikiページの特定の位置にリンクできます。ただし、一部のエッジケースでは、自動生成されたアンカーは、多くのユーザーが予想するよりも少ないダッシュ（-）文字で作成されます。たとえば、## Step - 1の見出しでは、他のほとんどのMarkdownツールとLinterは#step---1を予期します。しかし、GitLabは#step-1のアンカーを生成し、連続するダッシュは1つに圧縮されます。

GitLab 17.0では、連続するダッシュを削除しないようにすることで、自動生成されたアンカーを業界標準に合わせます。17.0では、Markdownドキュメントがあり、複数のダッシュを持つ可能性のある見出しにリンクしている場合、このエッジケースを回避するために、見出しを更新する必要があります。上記の例では、ページ内リンクが引き続き機能するように、## Step - 1を## Step 1に変更できます。

CiRunner.projectsのデフォルトの並べ替えをid_descに変更

CiRunner.projectsのフィールドのデフォルトの並べ替え順の値が、id_ascからid_descに変更されます。返されるプロジェクトの順序をid_ascにする必要がある場合は、その選択を明示的にするためにスクリプトを変更してください。

一般設定でのコンプライアンスフレームワーク

コンプライアンスフレームワークの管理を、コンプライアンスセンターのフレームワークおよびプロジェクトレポートに移動しました。

そのため、GitLab 17.0では、グループおよびプロジェクトの一般設定ページからコンプライアンスフレームワークの管理を削除します。

SwiftおよびOSSストレージドライバーのコンテナレジストリのサポート

コンテナレジストリは、ストレージドライバーを使用して、さまざまなオブジェクトストレージプラットフォームと連携します。各ドライバーのコードは比較的自己完結型ですが、これらのドライバーのメンテナンス負荷は高くなっています。各ドライバーの実装は一意であり、ドライバーを変更するには、その特定のドライバーに関する高度なドメイン専門知識が必要です。

メンテナンスコストを削減するために、OSS（オブジェクトストレージサービス）およびOpenStack Swiftのサポートを非推奨にしています。どちらもアップストリームのDocker Distributionからすでに削除されています。これは、オブジェクトストレージのサポートに関して、より広範なGitLab製品の提供内容とコンテナレジストリを整合させるのに役立ちます。

OSSにはS3互換モードがあるため、サポートされているドライバーに移行できない場合は、それを使用することを検討してください。Swiftは、S3ストレージドライバーでも必要となるS3 API操作に対応しています。

DAST ZAPの高度な設定変数は非推奨

GitLab 15.7で新しいブラウザベースのDASTアナライザーが一般公開になったため、将来的には、このアナライザーをデフォルトのDASTアナライザーにすることを目指しています。この準備として、従来のDAST変数DAST_ZAP_CLI_OPTIONSおよびDAST_ZAP_LOG_CONFIGURATIONは非推奨となり、GitLab 17.0で削除される予定です。これらの変数により、OWASP ZAPに基づいた従来のDASTアナライザーで高度な設定が利用可能になっていましたこれらの機能はZAPの動作に固有のものであるため、新しいブラウザベースのアナライザーには含まれません。

これらの3つの変数は、GitLab 17.0で削除されます。

依存関係スキャンでのSBOMメタデータプロパティの誤り

GitLab 17.0では、CycloneDX SBOMレポートの次のメタデータプロパティのサポートが削除されます:

• gitlab:dependency_scanning:input_file
• gitlab:dependency_scanning:package_manager

これらのプロパティは、GitLab 15.7で依存関係スキャンによって生成されたSBOMに追加されました。ただし、これらのプロパティは正しくなく、GitLab CycloneDXプロパティ分類に準拠していませんでした。この問題に対処するために、GitLab 15.11で次の正しいプロパティが追加されました:

• gitlab:dependency_scanning:input_file:path
• gitlab:dependency_scanning:package_manager:name

正しくないプロパティは、下位互換性を保つために保持されていました。これらは現在非推奨であり、17.0で削除されます。

sbt 1.0.Xの依存関係スキャンのサポート

sbtの非常に古いバージョンをサポートすると、メンテナンスコストを増やすことなく、このパッケージマネージャーで追加ユースケースのサポートを改善できなくなります。

sbtのバージョン1.1.0は6年前にリリースされており、依存関係スキャンが機能しなくなるため、1.0.xからアップグレードすることをおすすめします。

コンテナスキャンのGrypeスキャナーを非推奨化

GitLabコンテナスキャンアナライザーでのGrypeスキャナーのサポートは、GitLab 16.9で非推奨になります。

GitLab 17.0以降、Grypeアナライザーは、サポートに関する声明で説明されている限定的な修正を除き、保守されなくなります。

Trivyスキャナーを使用するCS_ANALYZER_IMAGEのデフォルト設定を使用することをおすすめします。

Grypeアナライザーイメージの現行メジャーバージョンは、GitLab 19.0まで最新のアドバイザリーデータベースとオペレーティングシステムパッケージで更新され続けます。GitLab 19.0の時点で、アナライザーは動作を停止します。

19.0の後もGrypeを引き続き使用するには、セキュリティスキャナーのインテグレーションに関するドキュメントを参照して、GitLabとの独自のインテグレーションを作成する方法を確認してください。

ライセンススキャンCIテンプレートを非推奨化

GitLab 17.0で、ライセンススキャンCIテンプレートが削除されます:

• Jobs/License-Scanning.gitlab-ci.yml
• Jobs/License-Scanning.latest.gitlab-ci.yml
• Security/License-Scanning.gitlab-ci.yml

上記のテンプレートのいずれかを含むCI設定は、GitLab 17.0では機能しなくなります。

代わりに、CycloneDXファイルのライセンススキャンを使用することをおすすめします。

依存関係スキャンおよびライセンススキャンでPython 3.9を非推奨化

GitLab 16.9以降、依存関係スキャンおよびライセンススキャンにおけるPython 3.9のサポートは非推奨になります。GitLab 17.0では、Python 3.10が依存関係スキャンCI/CDジョブのデフォルトバージョンです。

GitLab 17.0以降、依存関係スキャンおよびライセンススキャン機能は、互換性のあるロックファイルなしでは、Python 3.9を必要とするプロジェクトをサポートしなくなります。

GitLab RunnerでWindows CMDを非推奨化

GitLab 11.11では、PowerShellを優先して、WindowsバッチexecutorであるCMD ShellがGitLab Runnerで非推奨になりました。それ以降も、CMD ShellはGitLab Runnerで引き続きサポートされています。ただし、これにより、エンジニアリングチームと、WindowsでRunnerを使用しているお客様の両方にとって、複雑さが増しています。17.0で、GitLab RunnerからのWindows CMDのサポートを完全に削除する予定です。お客様は、Shell executorでWindows上のRunnerを使用する場合は、PowerShellを使用するように計画する必要があります。お客様は、削除イシューのイシュー29479でフィードバックを提供したり、質問したりできます。

CiRunnerManagerで複製されたCiRunner GraphQLフィールドを非推奨化

これらのフィールド（architectureName、ipAddress、platformName、revision、version）は、Runner設定内でグループ化されたRunnerマネージャーの導入により重複しているため、GraphQL CiRunnerタイプで非推奨になりました。

TerraformモジュールCI/CDテンプレートでfmtジョブを非推奨化

TerraformモジュールCI/CDテンプレートのfmtジョブは非推奨となり、GitLab 17.0で削除されます。これは、次のテンプレートに影響します:

• Terraform-Module.gitlab-ci.yml
• Terraform/Module-Base.gitlab-ci.yml

以下を使用して、Terraform fmtジョブを手動でパイプラインに追加し直すことができます:

fmt:
  image: hashicorp/terraform
  script: terraform fmt -chdir "$TF_ROOT" -check -diff -recursive

OpenTofu CI/CDコンポーネントのfmtテンプレートを使用することもできます。

脆弱性管理機能においてmessageフィールドを非推奨化

このMRは、VulnerabilityCreate GraphQLミューテーションのmessageフィールド、および脆弱性エクスポートのAdditionalInfo列を非推奨にします。メッセージフィールドは、GitLab 16.0でセキュリティレポートスキーマから削除され、他の場所では使用されなくなっています。

機能フラグAPIでversionフィールドを非推奨化

機能フラグREST APIのversionフィールドは非推奨となり、GitLab 17.0で削除されます。

versionフィールドが削除されると、従来の機能フラグを作成する方法はなくなります。

デベロッパーロールからの脆弱性ステータスの変更を非推奨化

デベロッパーが脆弱性ステータスを変更する機能は、現在非推奨となっています。今後のGitLab 17.0リリースで破壊的な変更を加え、この機能をデベロッパーロールから削除する予定です。デベロッパーにこの権限を引き続き付与したいユーザーは、デベロッパー用のカスタムロールを作成して、admin_vulnerability権限を追加すると、このアクセス権を付与できます。

GitLab Self-Managedでグループオーナーのカスタムロール作成を非推奨化

GitLab Self-Managed 17.0では、グループオーナーに対して、カスタムロールの作成が削除されます。この機能は、管理者専用のインスタンスレベルに移動します。グループオーナーは、グループレベルでカスタムロールを割り当てることができます。

GitLab.comのグループオーナーは、引き続きカスタムロールを管理して、グループレベルで割り当てることができます。

APIを使用してGitLab Self-Managedでカスタムロールを管理する場合、新しいインスタンスエンドポイントが追加されており、これはAPI操作を続行するために必須です。

• インスタンス上のすべてのメンバーロールを一覧表示 - GET /api/v4/member_roles
• インスタンスにメンバーロールを追加 - POST /api/v4/member_roles
• インスタンスからメンバーロールを削除 - DELETE /api/v4/member_roles/:id

GraphQL VulnerabilityTypeのフィールドhasSolutionsを非推奨化

GraphQLフィールドVulnerability.hasSolutionsは非推奨となり、GitLab 17.0で削除されます。代わりに、Vulnerability.hasRemediationsを使用してください。

サインインページのカスタムテキストに関連する非推奨のパラメータ

パラメータのsign_in_textとhelp_textは、設定APIでは非推奨です。サインインページとサインアップページにカスタムテキストを追加するには、外観APIのdescriptionフィールドを使用します。

Windows Server 2022を優先してWindows Server 2019を非推奨化

Windows上のGitLab.com Runner用のWindows Server 2022（ベータ版）のリリースを最近発表しました。これに伴い、GitLab 17.0でWindows 2019を非推奨にします。

Windows 2022の使用に移行する方法の詳細については、GitLab.com RunnerのWindows 2022サポートが利用可能にを参照してください。

DingTalk OmniAuthプロバイダー

GitLabにDingTalk OmniAuthプロバイダーを提供するomniauth-dingtalk gemは、次のメジャーリリースであるGitLab 17.0で削除されます。このgemはほとんど使用されていませんが、JiHuエディションに適しています。

Gitaly設定内のストレージの重複

同じストレージパスを指す複数のGitalyストレージの設定のサポートは非推奨であり、GitLab 17.0で削除されます。GitLab 17.0以降では、このタイプの設定でエラーが発生します。

このタイプの設定のサポートを削除する理由は、バックグラウンドリポジトリのメンテナンスで問題が発生する可能性があり、将来のGitalyストレージの実装と互換性がないためです。

インスタンス管理者は、gitlab.rb設定ファイルのgitaly['configuration']セクションのstorageエントリを更新して、各ストレージが一意のパスで設定されていることを確認する必要があります。

ダウンストリームパイプラインで修正されたファイルタイプ変数の展開

以前は、別のCI/CD変数でファイルタイプCI/CD変数を参照しようとすると、CI/CD変数はファイルの内容を含むように展開されていました。この動作は、一般的なシェル変数展開ルールに準拠していないため、正しくありませんでした。CI/CD変数の参照は、ファイルの内容ではなく、ファイルへのパスのみを含むように展開する必要があります。これは、GitLab 15.7のほとんどのユースケースで修正されました。残念ながら、CI/CD変数をダウンストリームパイプラインに渡すことは、まだ修正されていないエッジケースですが、GitLab 17.0で修正される予定です。

この変更により、.gitlab-ci.ymlファイルで設定された変数は、ファイル変数を参照してダウンストリームパイプラインに渡すことができ、ファイル変数もダウンストリームパイプラインに渡されます。ダウンストリームパイプラインは、ファイルの内容ではなく、ファイルパスへの変数参照を展開します。

この破壊的な変更により、ダウンストリームパイプラインでのファイル変数の展開に依存するユーザーワークフローが混乱する可能性があります。

Geo: デザインとプロジェクトの従来のレプリケーション詳細ルートは非推奨

従来のデータ型からGeoセルフサービスフレームワークへの移行の一環として、次のレプリケーション詳細ルートは非推奨になります:

• デザイン/admin/geo/replication/designsは/admin/geo/sites/<Geo Node/Site ID>/replication/design_management_repositoriesに置き換えられました
• プロジェクト/admin/geo/replication/projectsは/admin/geo/sites/<Geo Node/Site ID>/replication/projectsに置き換えられました

GitLab 16.4から17.0までは、従来のルートのルックアップは自動的に新しいルートにリダイレクトされます。17.0でリダイレクトを削除します。従来のルートを使用する可能性のあるブックマークまたはスクリプトを更新してください。

GitLab Helmチャートの値gitlab.kas.privateApi.tls.*は非推奨

KASとHelmチャートコンポーネント間のTLS通信を容易にするために、global.kas.tls.* Helm値を導入しました。古い値gitlab.kas.privateApi.tls.enabledおよびgitlab.kas.privateApi.tls.secretNameは非推奨となり、GitLab 17.0で削除される予定です。

新しい値ではKASのTLSを有効にする合理化された包括的な方法が提供されるため、gitlab.kas.privateApi.tls.*の代わりにglobal.kas.tls.*を使用する必要があります。gitlab.kas.privateApi.tls.*の詳細については、以下を参照してください:

• global.kas.tls.*値を導入するマージリクエスト。
• 非推奨のgitlab.kas.privateApi.tls.*に関するドキュメント。
• 新しいglobal.kas.tls.*に関するドキュメント。

GitLab Runnerの来歴メタデータSLSA v0.2ステートメント

現在、Runnerは来歴メタデータを生成して、SLSA v0.2に準拠するステートメントを生成するようにデフォルト設定されています。SLSA v1.0がリリースされ、GitLabでサポートされるようになったため、v0.2ステートメントは非推奨となり、GitLab 17.0での削除が計画されています。SLSA v1.0ステートメントは、GitLab 17.0で新しいデフォルトのステートメント形式になる予定です。

サポートされていないメソッドによるGraphQL APIアクセス

GitLab 17.0以降、GraphQLへのアクセスを、すでにドキュメント化されているサポート対象のトークンタイプを介してのみ行うように制限します。

ドキュメント化されたサポート対象のトークンタイプをすでに使用しているお客様には、破壊的な変更はありません。

GraphQL networkPoliciesリソースは非推奨

networkPoliciesGraphQLリソースは非推奨となっていて、GitLab 17.0で削除されます。GitLab 15.0以降、このフィールドはデータを返していません。

GraphQLフィールドconfidentialをノート上でinternalに変更

Noteのconfidentialフィールドは非推奨となり、internalに名前が変更されます。

GraphQLフィールドregistrySizeEstimatedは非推奨

明確にするため、GraphQLフィールドregistrySizeEstimatedの名前を、対応するものと一致するようにcontainerRegistrySizeIsEstimatedに変更しました。registrySizeEstimatedはGitLab 16.2で非推奨となっていて、GitLab 17.0で削除されます。代わりにGitLab 16.2で導入されたcontainerRegistrySizeIsEstimatedを使用してください。

GraphQLフィールドtotalWeightは非推奨

GraphQLを使用して、イシューボードのイシューの合計ウェイトをクエリできます。ただし、totalWeightフィールドは最大サイズ2147483647に制限されています。その結果、totalWeightは非推奨となり、GitLab 17.0で削除されます。

代わりに、GitLab 16.2で導入されたtotalIssueWeightを使用してください。

GraphQLのタイプRunnerMembershipFilterの名前をCiRunnerMembershipFilterに変更

GraphQLのタイプRunnerMembershipFilterの名前がCiRunnerMembershipFilterに変更されました。GitLab 17.0では、RunnerMembershipFilterタイプのエイリアスが削除されます。

GraphQL: SharedRunnersSetting enumのDISABLED_WITH_OVERRIDE値は非推奨

GitLab 17.0では、SharedRunnersSetting GraphQL enumタイプのDISABLED_WITH_OVERRIDE値が削除されます。代わりに、DISABLED_AND_OVERRIDABLEを使用してください。

GraphQL: canDestroyとcanDeleteのサポートを非推奨化

パッケージレジストリのUIは、GitLab GraphQL APIに依存しています。誰もが簡単にコントリビュートできるように、すべてのGitLab製品領域でフロントエンドが一貫してコーディングされていることが重要です。ただし、GitLab 16.6より前は、パッケージレジストリUIの権限処理が製品の他の領域とは異なっていました。

16.6では、パッケージレジストリをGitLabの他の部分と連携させるために、Types::PermissionTypes::PackageタイプのUserPermissionsフィールドを新たに追加しました。この新しいフィールドは、Package、PackageBase、PackageDetailsTypeタイプのcanDestroyフィールドを置き換えます。また、ContainerRepository、ContainerRepositoryDetails、ContainerRepositoryTagのフィールドcanDeleteも置き換えます。GitLab 17.0では、canDestroyフィールドとcanDeleteフィールドが削除されます。

これは17.0で完了する破壊的な変更です。

HashiCorp VaultインテグレーションはデフォルトでCI_JOB_JWT CI/CDジョブトークンの使用を停止

JWTとOIDCを使用してCIワークフローのセキュリティを向上させる取り組みの一環として、ネイティブHashiCorpインテグレーションもGitLab 16.0で更新されています。Vaultからシークレットを取得するためにsecrets:vaultキーワードを使用するすべてのプロジェクトは、IDトークンを使用するように設定する必要があります。IDトークンは15.7で導入されました。

この変更に備えるには、新しいid_tokensキーワードを使用し、audクレームを設定します。bound_audiencesの前にhttps://が付いていることを確認してください。

GitLab 15.9から15.11では、Limit JSON Web Token (JWT) access（JSON Webトークン（JWT）アクセスを制限する）設定を有効にすることができます。これにより、古いトークンがジョブに公開されるのを防ぎ、secrets:vaultキーワードのIDトークン認証が有効になります。

GitLab 16.0以降では、次のようになります:

• この設定は削除されます。
• id_tokensキーワードを使用するCI/CDジョブは、secrets:vaultでIDトークンを使用でき、利用可能なCI_JOB_JWT*トークンはありません。
• id_tokensキーワードを使用しないジョブは、GitLab 17.0までCI_JOB_JWT*トークンを引き続き使用できます。

Auto DevOpsビルドのHerokuイメージのアップグレード

GitLab 17.0では、auto-build-imageプロジェクトはheroku/builder:20イメージからheroku/builder:22にアップグレードされます。

新しいイメージの動作をテストするには、CI/CD変数のAUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDERをheroku/builder:22に設定します。

GitLab 17.0以降もheroku/builder:20を引き続き使用するには、AUTO_DEVOPS_BUILD_IMAGE_CNB_BUILDERをheroku/builder:20に設定します。

内部コンテナレジストリAPIタグの削除エンドポイント

DockerレジストリHTTP API V2仕様（後にOCIディストリビューション仕様に置き換えられました）には、タグの削除操作が含まれていませんでした。また、時間がかかる安全ではない回避策を使用して、同じ目的を達成する必要がありました。

タグの削除は重要な機能であるため、DockerおよびOCIディストリビューション仕様の範囲を超えてV2 APIを拡張し、GitLabコンテナレジストリにタグ削除操作を追加しました。

それ以降、OCIディストリビューション仕様ではいくつかの更新が行われ、DELETE /v2/<name>/manifests/<tag>エンドポイントを使用してタグ削除操作を実行できるようになりました。

これにより、コンテナレジストリにはまったく同じ機能を提供する2つのエンドポイントが残されています。DELETE /v2/<name>/tags/reference/<tag>はカスタムGitLabタグ削除エンドポイントであり、DELETE /v2/<name>/manifests/<tag>はGitLab 16.4で導入されたOCI準拠のタグ削除エンドポイントです。

カスタムGitLabタグ削除エンドポイントのサポートはGitLab 16.4で非推奨となり、GitLab 17.0で削除される予定です。

このエンドポイントは、パブリックGitLabコンテナレジストリAPIではなく、internal（内部）コンテナレジストリアプリケーションAPIによって使用されます。ほとんどのコンテナレジストリユーザーは、何も操作を行う必要はありません。新しいOCI準拠のエンドポイントに移行する際に、タグの削除に関連するすべてのGitLab UIおよびAPI機能はそのまま残ります。

内部コンテナレジストリAPIにアクセスし、元のタグ削除エンドポイントを使用する場合は、新しいエンドポイントに更新する必要があります。

JWT /-/jwksインスタンスエンドポイントは非推奨

GitLab 17.0で古いJSON Webトークンバージョンが非推奨になることで、/oauth/discovery/keysのエイリアスである関連する/-/jwksエンドポイントは不要になり、削除されます。認証設定でjwks_urlを指定している場合は、代わりに設定をoauth/discovery/keysに更新し、エンドポイントでの/-/jwksの使用箇所をすべて削除します。認証設定でoauth_discovery_keysをすでに使用し、エンドポイントで/-/jwksエイリアスをすでに使用している場合は、エンドポイントから/-/jwksを削除します。たとえば、https://gitlab.example.com/-/jwksをhttps://gitlab.example.comに変更します。

従来のGeo Prometheusメトリクス

Geoセルフサービスフレームワークへのプロジェクトの移行後、多くのPrometheusメトリクスを非推奨にしました。次のGeo関連のPrometheusメトリクスは非推奨となり、17.0で削除されます。以下の表に、非推奨のメトリクスとそれぞれの代替メトリクスを示します。代替メトリクスは、GitLab 16.3.0以降で使用できます。

ライセンスリストは非推奨

GitLabでは現在、プロジェクトのすべてのライセンスとそのライセンスを使用するすべてのコンポーネントのリストを、ライセンスリストで確認できます。16.8の時点で、ライセンスリストは非推奨であり、破壊的な変更として17.0で削除される予定です。プロジェクトまたはグループが依存関係リストで使用しているすべてのライセンスにアクセスできるようになりました。ライセンスでフィルタリングする機能も含まれています。

sbt 1.0.Xのライセンススキャンのサポート

GitLab 17.0では、sbt 1.0.xのライセンススキャンのサポートが削除されます。

sbt 1.0.xからアップグレードすることをおすすめします。

リポジトリディレクトリの一覧表示Rakeタスク

gitlab-rake gitlab:list_repos Rakeタスクは機能せず、GitLab 17.0で削除されます。GitLabを移行する場合は、代わりにバックアップと復元を使用してください。

GraphQL APIを使用してパッケージ設定を変更する機能を提供するメンテナーロール

メンテナーロールを持つユーザーがGraphQL APIを使用してグループのパッケージとレジストリの設定を変更する機能はGitLab 15.8で非推奨となり、GitLab 17.0で削除される予定です。これらの設定には以下が含まれます:

• 重複するパッケージのアップロードの許可または禁止。
• パッケージリクエストの転送。
• 依存プロキシのライフサイクルルールの有効化。

GitLab 17.0以降では、GitLab UIまたはGraphQL APIを使用して、グループのパッケージとレジストリの設定を変更するには、グループのオーナーロールが必要です。

依存関係スキャンおよびライセンススキャンにおける3.8.8より前のMavenバージョンのサポート

GitLab 17.0では、3.8.8より前のMavenバージョンの依存関係スキャンとライセンススキャンのサポートが削除されます。

3.8.8以降へのアップグレードをおすすめします。

Sidekiqオプションの最小並行処理と最大並行処理

• Linuxパッケージ（Omnibus）インストールの場合、sidekiq['min_concurrency']およびsidekiq['max_concurrency']の設定はGitLab 16.9で非推奨となり、GitLab 17.0で削除されます。

  GitLab 16.9以降では、sidekiq['concurrency']を使用して、各プロセスで明示的にスレッド数を設定できます。

  上記の変更は、Linuxパッケージ（Omnibus）インストールにのみ適用されます。

• GitLab Helmチャートインストールの場合、SIDEKIQ_CONCURRENCY_MINまたはSIDEKIQ_CONCURRENCY_MAXをextraEnvとしてsidekiqサブチャートに渡すことは、GitLab 16.10で非推奨となり、GitLab 17.0で削除されます。

  concurrencyオプションを使用すると、各プロセスで明示的にスレッド数を設定できます。

/users REST APIエンドポイントのオフセットページネーションは非推奨

/users REST APIのオフセットページネーションはGitLab 16.5で非推奨となり、GitLab 17.0で削除される予定です。代わりにキーセットページネーションを使用してください。

古いバージョンのJSON Webトークンは非推奨

OIDCをサポートするIDトークンは、GitLab 15.7で導入されました。これらのトークンは、古いJSON Webトークン（JWT）よりも設定しやすく、OIDCに準拠しており、IDトークンが明示的に設定されているCI/CDジョブでのみ使用できます。IDトークンは、すべてのジョブで公開されている古いCI_JOB_JWT* JSON Webトークンよりも安全であるため、次の古いJSON Webトークンは非推奨になります:

• CI_JOB_JWT
• CI_JOB_JWT_V1
• CI_JOB_JWT_V2

この変更に備えるには、パイプラインを設定して、非推奨のトークンの代わりにIDトークンを使用するようにします。OIDCに準拠するために、issクレームは、CI_JOB_JWT_V2トークンで以前に導入された完全修飾ドメイン名（https://example.comなど）を使用するようになりました。

GitLab 15.9から15.11では、Limit JSON Web Token (JWT) access（JSON Webトークン（JWT）アクセスを制限する）設定を有効にすることができます。これにより、古いトークンがジョブに公開されるのを防ぎ、secrets:vaultキーワードのIDトークン認証が有効になります。

GitLab 16.0以降では、次のようになります:

• この設定は削除されます。
• id_tokensキーワードを使用するCI/CDジョブは、secrets:vaultでIDトークンを使用でき、利用可能なCI_JOB_JWT*トークンはありません。
• id_tokensキーワードを使用しないジョブは、GitLab 17.0までCI_JOB_JWT*トークンを引き続き使用できます。

GitLab 17.0では、非推奨のトークンは完全に削除され、CI/CDジョブで使用できなくなります。

OmniAuth Facebookは非推奨

OmniAuth FacebookのサポートはGitLab 17.0で削除されます。最後のgemリリースは2021年に行われ、現在はメンテナンスされていません。現在の使用率は0.1%未満です。OmniAuth Facebookを使用している場合は、サポートが削除される前に、サポートされているプロバイダーに切り替えてください。

APIペイロードのパッケージパイプラインのページネーション

/api/v4/projects/:id/packagesへのAPIリクエストは、パッケージのページネーションされた結果を返します。各パッケージは、この応答ですべてのパイプラインを一覧表示します。パッケージが数百または数千の関連するパイプラインを持つ可能性があるため、これはパフォーマンス上の懸念事項です。

マイルストーン17.0では、API応答からpipelines属性を削除します。

PostgreSQL 13はサポート終了

GitLabは、PostgreSQLの年間アップグレードケイデンスに従います。

PostgreSQL 13のサポートは、GitLab 17.0で削除される予定です。GitLab 17.0では、PostgreSQL 14が最低限必要なPostgreSQLのバージョンとなります。

PostgreSQL 13は、GitLab 16リリースサイクル全体でサポートされます。PostgreSQL 14は、GitLab 17.0に先立ってアップグレードするインスタンスでもサポートされます。Omnibus Linuxパッケージを使用してインストールした単一のPostgreSQLインスタンスを実行している場合、16.11で自動アップグレードが試行される可能性があります。アップグレードに対応できるように、十分なディスク容量があることを確認してください。詳細については、Omnibusデータベースのドキュメントを参照してください。

プロキシベースのDASTは非推奨

GitLab 17.0以降、プロキシベースのDASTはサポートされません。動的な解析を介したセキュリティ検出結果のためにプロジェクトの分析を継続するには、ブラウザベースのDASTに移行してください。プロキシベースのDASTの上に構築されたインキュベーション機能であるBreach and Attack Simulation（Breach and Attack Simulation）も、この非推奨化の対象に含まれており、17.0以降はサポートされません。

Sidekiqの実行に使用されるキューセレクターは非推奨

キューセレクターとネゲート設定を使用してSidekiqを実行することは非推奨であり、17.0で完全に削除されます。

キューセレクターから、すべてのプロセスですべてのキューをリッスンすることに移行できます。たとえば、現在Sidekiqがキューセレクター（sidekiq['queue_selector'] = true）で4つのプロセスで実行されている場合（/etc/gitlab/gitlab.rbのsidekiq['queue_groups']に4つの要素で示される）、Sidekiqを変更して、4つすべてのプロセスですべてのキューをリッスンするようにできます（例: sidekiq['queue_groups'] = ['*'] * 4）。このアプローチは、リファレンスアーキテクチャでも推奨されています。Sidekiqは、マシン内のCPUの数と同じ数のプロセスを効果的に実行できることに注意してください。

上記のアプローチはほとんどのインスタンスで推奨されますが、Sidekiqはルーティングルールを使用して実行することもでき、これはGitLab.comでも使用されています。キューセレクターからルーティングルールへの移行ガイドに従うことができます。ジョブが完全に失われることを避けるために、移行には注意が必要です。

Linux上の小さなGitLab.com Runnerからのタグの削除

ラベルとして使用されていたという歴史的な理由から、小規模なLinux GitLab.com Runnerには多くのタグが付与されていました。saas-linux-small-amd64だけを使用するようにタグを効率化し、すべてのGitLab.com Runnerで一貫性を持たせたいと考えています。

タグdocker、east-c、gce、git-annex、linux、mongo、mysql、postgres、ruby、sharedは非推奨になります。

詳細については、Linux上の小規模なSaaS Runnerからのタグの削除を参照してください。

必須のパイプライン設定は非推奨

必須のパイプライン設定はGitLab 17.0で削除されます。これは、UltimateプランのGitLab Self-Managedのユーザーに影響します。

必須のパイプライン設定を次のいずれかに置き換える必要があります:

• コンプライアンスフレームワークにスコープされたセキュリティポリシー。
• コンプライアンスパイプライン（現在利用可能です）。

これらの代替ソリューションをおすすめする理由は、柔軟性が向上し、必要なパイプラインを特定のコンプライアンスフレームワークラベルに割り当てることができるからです。

コンプライアンスパイプラインは将来的に非推奨となり、セキュリティポリシーに移行します。詳細については、移行と非推奨のエピックを参照してください。

GitLab 17.0でのSASTアナライザーのカバレッジの変更

GitLab SASTでデフォルトで使用されるサポート対象のアナライザーの数を削減しています。これは、さまざまなプログラミング言語で、より高速で一貫性のあるユーザーエクスペリエンスを実現するための長期的な戦略の一環です。

GitLab 17.0では、次のようになります:

1. SAST CI/CDテンプレートから一連の言語固有のアナライザーを削除し、SemgrepベースのアナライザーでGitLabがサポートする検出ルールでカバレッジを置き換えます。次のアナライザーは現在、非推奨となっており、GitLab 17.0でサポートが終了します:
   1. Brakeman（Ruby、Ruby on Rails）
   2. Flawfinder（C、C++）
   3. MobSF（Android、iOS）
   4. NodeJS Scan（Node.js）
   5. PHPCS Security Audit（PHP）
2. SAST CI/CDテンプレートを変更して、KotlinおよびScalaコードのSpotBugsベースのアナライザーの実行を停止します。代わりに、これらの言語は、SemgrepベースのアナライザーでGitLabがサポートする検出ルールを使用してスキャンされます。

非推奨のアナライザーはただちに、セキュリティアップデートのみを受け取ります。その他の定期的な改善や更新は保証されません。GitLab 17.0でアナライザーがサポート終了になると、それ以上の更新は提供されません。ただし、これらのアナライザー用に以前に公開されたコンテナイメージを削除したり、カスタムCI/CDパイプラインジョブ定義を使用してアナライザーを実行する機能を削除したりすることはありません。

脆弱性管理システムは、既存のほとんどの検出結果を更新して、新しい検出ルールと一致するようにします。新しいアナライザーに移行されない検出結果は、自動的に解決されます。詳細については、脆弱性の移行ドキュメントを参照してください。

削除されたアナライザーにカスタマイズを適用した場合、またはパイプラインでSemgrepベースのアナライザーを現在無効にしている場合は、この変更の非推奨に関するイシューの記載に従って対処する必要があります。

_EXCLUDED_ANALYZERS変数を使用したスキャン実行ポリシーによるプロジェクト変数のオーバーライド

SEP変数を最高の優先度で適用することを配信および検証した後、意図しない動作が発見されました。これにより、ユーザーはパイプライン設定で_EXCLUDED_PATHSを設定できるようになりましたが、ポリシーとパイプライン設定の両方で_EXCLUDED_ANALYZERSを設定することはできなくなりました。

スキャン実行変数が適切に適用されるようにするため、GitLabスキャンアクションを使用してスキャン実行ポリシーに_EXCLUDED_ANALYZERSまたは_EXCLUDED_PATHS変数を指定した場合に、その変数が、除外されたアナライザーに対して定義されたプロジェクト変数をオーバーライドするようになります。

ユーザーは、17.0より前に機能フラグを有効にして、この動作を適用できます。17.0では、_EXCLUDED_ANALYZERS/_EXCLUDED_PATHS変数を活用するプロジェクト（この変数を含むスキャン実行ポリシーが定義されている）は、デフォルトでオーバーライドされます。

Secureアナライザーのメジャーバージョン更新

Secureステージでは、GitLab 17.0のリリースと連携して、アナライザーのメジャーバージョンが引き上げられます。

デフォルトの内蔵テンプレートを使用していない場合、またはアナライザーのバージョンを固定している場合は、CI/CDジョブ定義を更新して、固定されたバージョンを削除するか、最新のメジャーバージョンに更新する必要があります。

GitLab 16.0 - 16.11のユーザーは、GitLab 17.0のリリースまでは通常どおりアナライザーの更新を引き続き利用できます。その後、新たに修正されたバグやリリースされた機能はすべて、アナライザーの新しいメジャーバージョンでのみリリースされます。

メンテナンスポリシーに従い、バグや機能を非推奨バージョンにバックポートすることはありません。必要に応じて、セキュリティパッチは、最新の3つのマイナーリリース内でバックポートされます。

具体的には、次のアナライザーは非推奨となり、GitLab 17.0のリリース後は更新されなくなります:

• コンテナスキャン: バージョン6
• 依存関係スキャン: バージョン4
• DAST: バージョン4
• DAST API: バージョン3
• ファズAPI: バージョン3
• IaCスキャン: バージョン4
• シークレット検出: バージョン5
• 静的アプリケーションセキュリティテスト（SAST）: すべてのアナライザーのバージョン4
  • brakeman
  • flawfinder
  • kubesec
  • mobsf
  • nodejs-scan
  • phpcs-security-audit
  • pmd-apex
  • semgrep
  • sobelow
  • spotbugs

セキュリティポリシーフィールドmatch_on_inclusionは非推奨

スキャン結果ポリシーの追加フィルターのサポートでは、newly_detectedフィールドをnew_needs_triageおよびnew_dismissedの2つのオプションに分割しました。セキュリティポリシーYAMLに両方のオプションを含めることで、元のnewly_detectedフィールドと同じ結果が得られます。ただし、new_needs_triageのみを使用することで、フィルターを絞り込んで、無視された検出結果を無視できるようになりました。エピック10203でのディスカッションに基づいて、YAML定義の明確化のために、match_on_inclusionフィールドの名前をmatch_on_inclusion_licenseに変更しました。

セキュリティポリシーフィールドnewly_detectedは非推奨

スキャン結果ポリシーの追加フィルターのサポートでは、newly_detectedフィールドをnew_needs_triageおよびnew_dismissedの2つのオプションに分割しました。セキュリティポリシーYAMLに両方のオプションを含めることで、元のnewly_detectedフィールドと同じ結果が得られます。ただし、new_needs_triageのみを使用することで、フィルターを絞り込んで、無視された検出結果を無視できるようになりました。

自己ホスト型Sentryバージョン21.4.1以前のサポート

自己ホスト型Sentryバージョン21.4.1以前のサポートは非推奨となり、GitLab 17.0で削除されます。

自己ホスト型Sentryのバージョンが21.4.1以前の場合、GitLab 17.0以降にアップグレードすると、GitLabインスタンスからエラーを収集できなくなる可能性があります。GitLabインスタンスからSentryインスタンスへのエラー送信を継続するには、Sentryをバージョン21.5.0以降にアップグレードします。詳細については、Sentryドキュメントを参照してください。

注: 非推奨のサポートは、管理者向けのGitLabインスタンスのエラー追跡機能を対象としています。非推奨のサポートは、デベロッパー自身のデプロイ済みアプリケーション用のGitLabエラー追跡には関連していません。

バックアップ用のカスタムスキーマの設定のサポートは非推奨

Linuxパッケージインストールの場合は、/etc/gitlab/gitlab.rbのgitlab_rails['backup_pg_schema'] = '<schema_name>'を設定し、自己コンパイルインストールの場合は、config/gitlab.ymlを編集することにより、バックアップ用のカスタムスキーマを使用するようにGitLabを設定することが可能でした。

この設定は利用可能でしたが、効果はなく、意図した目的を果たしていませんでした。この設定項目はGitLab 17.0で削除されます。

GitHubインポーターRakeタスク

GitHubインポーターRakeタスクは、GitLab 16.6で非推奨となりました。Rakeタスクは、APIでサポートされているいくつかの機能が欠落していて、積極的にメンテナンスされていません。

このRakeタスクは、GitLab 17.0で削除されます。

代わりに、APIまたはUIを使用してGitHubリポジトリをインポートできます。

Visual Reviewsツールは非推奨

お客様の利用状況と機能が限られているため、レビューアプリのVisual Reviews機能は非推奨となり、削除されます。代替手段は計画されておらず、ユーザーはGitLab 17.0の前にVisual Reviewsの使用を停止する必要があります。

gitlab-runner execコマンドは非推奨

gitlab-runner execコマンドは非推奨となり、16.0でGitLab Runnerから完全に削除されます。gitlab-runner exec機能は当初、GitLabインスタンスへの更新をコミットしなくても、ローカルシステムでGitLab CIパイプラインを検証できるようにするために開発されました。ただし、GitLab CIの継続的な進化に伴い、すべてのGitLab CI機能をgitlab-runner execに複製することはもはや実現可能ではありませんでした。パイプライン構文と検証のシミュレーションがGitLabパイプラインエディタで利用できます。

Kubernetes向けGitLabエージェントのプルベースのデプロイ機能は非推奨

Fluxおよび関連するインテグレーションを優先して、Kubernetes向けGitLabエージェントに組み込まれているプルベースのデプロイ機能は非推奨になります。

Kubernetes向けGitLabエージェントはis not deprecated（非推奨ではありません）。この変更は、エージェントのプルベースの機能のみに影響します。他のすべての機能はそのまま残り、GitLabは引き続きKubernetes向けエージェントをサポートします。

エージェントをプルベースのデプロイに使用する場合は、Fluxに移行する必要があります。FluxはGitOps向けの成熟したCNCFプロジェクトであるため、2023年2月にFluxをGitLabと統合することを決定しました。

Twitter OmniAuthログインオプションはGitLab Self-Managedで非推奨

Twitter OAuth 1.0a OmniAuthは非推奨となり、使用率が低く、gemのサポートがないため、GitLab 17.0のGitLab Self-Managedでは削除される予定です。代わりに、サポートされている別のOmniAuthプロバイダーを使用してください。

統合承認ルールは非推奨

より柔軟性の高い複数の承認ルールを優先して、統合承認ルールは非推奨となります。破壊的な変更を行わないと、統合承認ルールを複数の承認ルールに移行できない場合があります。手動での移行を支援するため、移行ドキュメントを提供しました。

統合承認ルールが削除される前に手動で移行しない場合、GitLabは自動的に設定を移行します。複数の承認ルールを使用すると、承認ルールをきめ細かく設定できるようになるため、GitLabに移行を任せた場合、自動移行によって、予想以上に制限の厳しいルールになる可能性があります。予想以上に多くの承認が必要なイシューが発生した場合は、移行ルールを確認してください。

GitLab 15.11では、統合承認ルールのUIサポートが削除されました。APIを使用して統合承認ルールにアクセスすることもできます。

Linux上のGitLab.com Runnerのオペレーティングシステムバージョンのアップグレード

GitLabは、Linux上のGitLab.com Runnerのジョブ実行に使用される一時的なVMのコンテナ最適化オペレーティングシステム（COS）をアップグレードしています。COSのこのアップグレードには、Docker Engineのバージョン19.03.15からバージョン23.0.5へのアップグレードが含まれており、これにより既知の互換性の問題が発生します。

バージョン20.10より前のDocker-in-Docker、またはv1.9.0より古いKanikoイメージは、コンテナランタイムを検出できず、失敗します。

詳細については、Linux上のSaaS Runnerのオペレーティングシステムバージョンのアップグレードを参照してください。

脆弱性の信頼度フィールド

GitLab 15.3では、バージョン15より前のセキュリティレポートスキーマは非推奨になりました。脆弱性の検出結果のconfidence属性は、15-0-0より前のスキーマバージョンにのみ存在し、GitLab 15.4がスキーマバージョン15-0-0をサポートしているため、事実上非推奨となっています。レポートとパブリックAPIの一貫性を維持するため、GraphQL APIの脆弱性関連コンポーネントのconfidence属性は非推奨となり、17.0で削除されます。

after_scriptキーワードはキャンセルされたジョブでも実行

after_script CI/CDキーワードは、ジョブのメインscriptセクションに続いて追加コマンドを実行するために使用されます。これは多くの場合、ジョブで使用された環境またはその他のリソースをクリーンアップするために使用されます。多くのユーザーにとって、ジョブがキャンセルされた場合にafter_scriptコマンドが実行されないという事実は、予想外であり、望ましくありませんでした。17.0では、キーワードが更新され、ジョブのキャンセル後にもコマンドが実行されるようになります。after_scriptキーワードを使用するCI/CD設定が、キャンセルされたジョブに対しても実行を処理できることを確認してください。

dependency_filesは非推奨

GitLabでは現在、プロジェクトの依存関係リストは、依存関係スキャンレポートのdependency_filesの内容を使用して生成されます。ただし、グループ依存関係リストとの一貫性を維持するために、GitLab 17.0以降では、プロジェクトの依存関係リストは、PostgreSQLデータベースに保存されているCycloneDX SBOMレポートアーティファクトを使用します。そのため、依存関係スキャンレポートスキーマのdependency_filesプロパティは非推奨となり、17.0で削除されます。

この非推奨化の一環として、dependency_pathも非推奨となり、17.0で削除されます。GitLabは、同様の情報を提供するために、CycloneDX仕様を使用した依存関係グラフの実装を進めます。

さらに、コンテナスキャンCIジョブは、オペレーティングシステムコンポーネントのリストを提供するために依存関係スキャンレポートを生成しなくなります。このレポートは、CycloneDX SBOMレポートに置き換えられます。コンテナスキャン用のCS_DISABLE_DEPENDENCY_LIST環境変数は使用されなくなっており、17.0で削除されます。

DORA APIのmetricフィルターとvalueフィールド

複数のDORAメトリクスを、新しいメトリクスフィールドを使用して同時にクエリできるようになりました。GraphQL DORA APIのmetricフィルターとvalueフィールドは、GitLab 17.0で削除されます。

omniauth-azure-oauth2 gemは非推奨

GitLabユーザーは、omniauth-azure-oauth2 gemを使用してGitLabで認証できます。17.0では、このgemはomniauth_openid_connect gemに置き換えられます。新しいgemには、古いgemと同じ機能がすべて含まれていますが、アップストリームのメンテナンスもあり、セキュリティと集中メンテナンスに適しています。

この変更のために、ユーザーは移行時にOAuth 2.0プロバイダーに再接続する必要があります。混乱を回避するために、17.0より前の任意のタイミングでomniauth_openid_connectを新しいプロバイダーとして追加してください。ユーザーには新しいログインボタンが表示され、手動で認証情報を再接続する必要があります。17.0より前にomniauth_openid_connect gemを実装しない場合、ユーザーはAzureログインボタンを使用してサインインできなくなるため、管理者が適切なgemを実装するまで、ユーザー名とパスワードを使用してサインインする必要があります。

omnibus_gitconfig設定項目は非推奨

omnibus_gitconfig['system']設定項目は非推奨となりました。omnibus_gitconfig['system']を使用してGitalyのカスタムGit設定を行う場合は、GitLab 17.0にアップグレードする前に、gitaly[:configuration][:git][:config]の下のGitaly設定を直接使用してGitを設定する必要があります。

次に例を示します:

  gitaly[:configuration][:git][:config] = [
    {
      key: 'fetch.fsckObjects',
      value: 'true',
    },
    # ...
  ]

設定キーの形式は、CLIフラグgit -c <configuration>を介してgitに渡される内容と一致する必要があります。

既存のキーを予期される形式に変換する際に問題が発生した場合は、GitalyのLinuxパッケージ生成設定ファイルで正しい形式の既存のキーを確認してください。デフォルトでは、設定ファイルは/var/opt/gitlab/gitaly/config.tomlにあります。

Gitalyによって管理されている次の設定オプションを削除する必要があります。これらのキーをGitalyに移行する必要はありません:

• pack.threads=1
• receive.advertisePushOptions=true
• receive.fsckObjects=true
• repack.writeBitmaps=true
• transfer.hideRefs=^refs/tmp/
• transfer.hideRefs=^refs/keep-around/
• transfer.hideRefs=^refs/remotes/
• core.alternateRefsCommand="exit 0 #"
• core.fsyncObjectFiles=true
• fetch.writeCommitGraph=true

postgres_exporter['per_table_stats']設定項目

Linuxパッケージは、バンドルされているPostgreSQL Exporter用のカスタムクエリを提供します。これには、postgres_exporter['per_table_stats']設定項目によって制御されるper_table_statsクエリが含まれていました。

PostgreSQL Exporterは、同じメトリクスを提供するstat_user_tablesコレクターを提供するようになりました。postgres_exporter['per_table_stats']を有効にしていた場合は、代わりにpostgres_exporter['flags']['collector.stat_user_tables']を有効にします。

projectFingerprint GraphQLフィールド

uuid属性を優先して、脆弱性検出のproject_fingerprint属性は非推奨になります。UUIDv5値を使用して検出結果を識別することにより、関連するエンティティを検出結果に簡単に関連付けることができます。project_fingerprint属性は検出の追跡に使用されなくなり、GitLab 17.0で削除されます。16.1以降、project_fingerprintの出力はuuidフィールドと同じ値を返します。

公開プロジェクトのrepository_download_operation監査イベントタイプ

監査イベントタイプrepository_download_operationは現在、すべてのプロジェクトのダウンロード（公開プロジェクトと非公開プロジェクトの両方）でデータベースに保存されます。公開プロジェクトの場合、この監査イベントは認証されていないユーザーによってトリガーされる可能性があるため、監査目的ではあまり有用ではありません。

GitLab 17.0以降、repository_download_operation監査イベントタイプは、非公開プロジェクトまたは内部プロジェクトに対してのみトリガーされます。公開プロジェクトのダウンロード用に、public_repository_download_operationという新しい監査イベントタイプを追加します。この新しい監査イベントタイプは、ストリーミング専用になります。

npmパッケージのアップロードが非同期で行われる

GitLabパッケージレジストリは、npmとYarnをサポートしています。npmまたはYarnパッケージをアップロードする場合、アップロードは同期的に処理されます。ただし、同期アップロードには既知の問題があります。たとえば、GitLabはオーバーライドなどの機能をサポートしていません。

17.0以降、npmおよびYarnパッケージは非同期でアップロードされます。これは破壊的な変更です。パッケージの公開後すぐに利用可能になることが求められるパイプラインが存在する可能性があるためです。

回避策として、パッケージAPIを使用してパッケージを確認する必要があります。

Shimoのインテグレーション

Shimo Workspace integration（Shimoワークスペースのインテグレーション）は非推奨となっていて、JiHu GitLabのコードベースに移行します。

user_email_lookup_limit APIフィールド

user_email_lookup_limit APIフィールドはGitLab 14.9で非推奨となり、GitLab 16.7で削除されました。機能が削除されるまで、user_email_lookup_limitはsearch_rate_limitにエイリアスされ、既存のワークフローは引き続き機能します。

user_email_lookup_limitのレート制限を変更するAPIコールは、代わりにsearch_rate_limitを使用する必要があります。

ジョブトークン許可リストは公開プロジェクトと内部プロジェクトを対象とする

16.6以降、public（公開）またはinternal（内部）のプロジェクトは、Limit access to this project（このプロジェクトへのアクセスを制限する）が有効になっている場合、プロジェクトの許可リストにnot（ない）プロジェクトからのジョブトークンリクエストを承認しなくなります。

Limit access to this project（このプロジェクトへのアクセスを制限する）設定が有効になっている公開または内部プロジェクトがある場合は、承認を継続するために、ジョブトークンリクエストを行うプロジェクトをプロジェクトの許可リストに追加する必要があります。

Geo: ハウスキーピングRakeタスク

Geoセルフサービスフレームワーク（SSF）へのレプリケーションと検証の移行の一環として、プロジェクトリポジトリの従来のレプリケーションは削除されました。その結果、レガシーコードに依存していた以下のRakeタスクも削除されました。これらのRakeタスクによって実行される作業は、定期的に、またはトリガーイベントに基づいて自動的にトリガーされるようになりました。

バンドルされたGrafanaは非推奨および無効

Omnibus GitLabにバンドルされているGrafanaのバージョンは、16.0で非推奨および無効になり、16.3で削除されます。バンドルされたGrafanaを使用している場合は、次のいずれかに移行する必要があります:

• Grafanaの別の実装。詳細については、新しいGrafanaインスタンスへの切り替えを参照してください。
• 選択した別の可観測性プラットフォーム。

現在提供されているGrafanaのバージョンは、サポートされなくなったバージョンです。

GitLabバージョン16.0～16.2では、バンドルされたGrafanaを再度有効にすることができます。ただし、バンドルされたGrafanaの有効化は、GitLab 16.3以降では機能しなくなります。

ライセンスコンプライアンスCIテンプレート

更新: 以前に、GitLab 16.0で既存のライセンスコンプライアンスCIテンプレートを削除すると発表しましたが、CycloneDXファイルのライセンススキャンに関するパフォーマンスの問題のため、代わりに16.3で削除します。

GitLabライセンスコンプライアンスCI/CDテンプレートは非推奨となり、GitLab 16.3リリースで削除される予定です。

ライセンスコンプライアンスにGitLabを引き続き使用するには、CI/CDパイプラインからライセンスコンプライアンステンプレートを削除し、依存関係スキャンテンプレートを追加します。依存関係スキャンテンプレートは必要なライセンス情報を収集できるようになったため、個別のライセンスコンプライアンスジョブを実行する必要はなくなりました。

ライセンスコンプライアンスCI/CDテンプレートを削除する前に、新しいライセンススキャン方法をサポートするバージョンにインスタンスがアップグレードされていることを確認してください。

依存関係スキャナーを大規模かつ迅速に使用できるようにするために、グループレベルでスキャン実行ポリシーを設定して、グループ内のすべてのプロジェクトに対してSBOMベースのライセンススキャンを適用することができます。次に、CI/CD設定からJobs/License-Scanning.gitlab-ci.ymlテンプレートの組み込みを削除できます。

従来のライセンスコンプライアンス機能を引き続き使用する場合は、LICENSE_MANAGEMENT_VERSION CI変数を4に設定します。この変数は、プロジェクト、グループ、またはインスタンスレベルで設定できます。この設定変更により、新しいアプローチを採用しなくても、既存のバージョンのライセンスコンプライアンスを引き続き使用できます。

この従来のアナライザーのバグや脆弱性は修正されなくなります。

RSAキーサイズの制限

Goバージョン1.20.7以降では、RSAキーを最大8192ビットに制限するmaxRSAKeySize定数が追加されています。その結果、8192ビットを超えるRSAキーはGitLabでは機能しなくなります。8192ビットを超えるRSAキーは、これより小さいサイズで再生成する必要があります。

ログにtls: server sent certificate containing RSA key larger than 8192 bitsのようなエラーが含まれているためにこの問題に気づく場合もあります。キーの長さをテストするには、コマンドopenssl rsa -in <your-key-file> -text -noout | grep "Key:"を使用します。

Twitter OmniAuthログインオプションはGitLab.comから削除

Twitter OAuth 1.0a OmniAuthは、使用率が低く、gemのサポートがないことに加えて、この機能の機能的なサインインオプションがないため、GitLab 16.3のGitLab.comで非推奨となり、削除されます。TwitterでGitLab.comにサインインする場合は、パスワードで、または別のサポートされているOmniAuthプロバイダーでサインインできます。

Auto DevOpsはデフォルトでのPostgreSQLデータベースのプロビジョニングを終了

現在、Auto DevOpsは、デフォルトでクラスター内PostgreSQLデータベースをプロビジョニングしています。GitLab 16.0では、データベースはオプトインしたユーザーに対してのみプロビジョニングされます。この変更は、より堅牢なデータベース管理を必要とする本番環境のデプロイをサポートします。

Auto DevOpsでクラスター内データベースをプロビジョニングする場合は、POSTGRES_ENABLED CI/CD変数をtrueに設定します。

Azure Storageドライバーの正しいルートプレフィックスがデフォルト設定に

コンテナレジストリのAzure Storageドライバーは、デフォルトのルートディレクトリとして//に書き込みます。このデフォルトのルートディレクトリは、Azure UI内の一部の場所では/<no-name>/として表示されます。このストレージドライバーを使用する以前のデプロイをサポートするために、この従来の動作を維持してきました。ただし、別のストレージドライバーからAzureに移行する場合、この動作は、trimlegacyrootprefix: trueを設定して、余分な先頭のスラッシュなしでストレージドライバーがルートパスを構築するように設定するまで、すべてのデータを非表示にします。

ストレージドライバーの新しいデフォルト設定では、trimlegacyrootprefix: trueが設定され、/がデフォルトのルートディレクトリになります。混乱を回避するために、現在の設定にtrimlegacyrootprefix: falseを追加できます。

この破壊的な変更は、GitLab 16.0で発生します。

バンドルされたGrafana Helmチャートは非推奨

GitLab HelmチャートにバンドルされているGrafana Helmチャートは非推奨であり、GitLab Helmチャート7.0リリース（GitLab 16.0とともにリリース）で削除されます。

バンドルされたGrafana Helmチャートはオプションのサービスであり、オンにすると、GitLab HelmチャートのPrometheusメトリクスに接続されたGrafana UIを提供することができます。

GitLab Helmチャートが現在提供しているGrafanaのバージョンは、サポート対象のGrafanaバージョンではなくなります。バンドルされたGrafanaを使用している場合は、Grafana Labsの新しいチャートバージョン、または信頼できるプロバイダーのGrafana Operatorに切り替える必要があります。

新しいGrafanaインスタンスで、GitLabが提供するPrometheusをデータソースとして設定し、GrafanaをGitLab UIに接続することができます。

CAS OmniAuthプロバイダー

GitLabにCAS OmniAuthプロバイダーを提供するomniauth-cas3 gemは、次回のメジャーリリースであるGitLab 16.0で削除されます。このgemの使用頻度は非常に低く、アップストリームのメンテナンスが不足しているため、GitLabをOmniAuth 2.0にアップグレードすることはできません。

HashiCorp Vaultからシークレットが返されない場合、CI/CDジョブは失敗する

ネイティブのHashiCorp Vaultインテグレーションを使用すると、Vaultからシークレットが返されない場合、CI/CDジョブは失敗します。GitLab 16.0より前に、設定が常にシークレットを返すようにするか、この変更を処理するようにパイプラインを更新してください。

マルチモジュールAndroidプロジェクトでMobSFベースのSASTアナライザーの動作を変更

更新: 以前に、MobSFベースのGitLab SASTアナライザーがマルチモジュールAndroidプロジェクトをスキャンする方法の変更を発表しました。その変更はキャンセルされており、対応は必要ありません。

スキャンする単一のモジュールを変更する代わりに、マルチモジュールのサポートを改善しました。

/approvals APIエンドポイントを使用したマージリクエストの承認を変更

マージリクエストに必要な承認を変更するために、GitLab 14.0で非推奨になった/approvals APIエンドポイントを使用しないでください。

代わりに、/approval_rulesエンドポイントを使用して、マージリクエストの承認ルールを作成または更新します。

Conanプロジェクトレベルの検索エンドポイントはプロジェクト固有の結果を返す

プロジェクトレベルまたはインスタンスレベルのエンドポイントでGitLab Conanリポジトリを使用できます。各レベルがConan検索コマンドをサポートしています。ただし、プロジェクトレベルの検索エンドポイントは、ターゲットプロジェクトの外部からもパッケージを返します。

この意図しない機能は、GitLab 15.8で非推奨となり、GitLab 16.0で削除されます。プロジェクトレベルの検索エンドポイントは、ターゲットプロジェクトのパッケージのみを返すようになります。

GitLab Runner Helmチャートの設定フィールド

GitLab 13.6以降、ユーザーはGitLab Runner Helmチャートで任意のRunner設定を指定できます。この機能を実装したときに、GitLab Helmチャート設定のGitLab Runner固有の値を非推奨にしました。非推奨の値はGitLab 16.0で削除されます。

環境変数を使用したRedis設定ファイルのパスの設定は非推奨

GITLAB_REDIS_CACHE_CONFIG_FILEやGITLAB_REDIS_QUEUES_CONFIG_FILEのような環境変数を使用してRedis設定ファイルの場所を指定することはできなくなりました。代わりに、config/redis.cache.ymlやconfig/redis.queues.ymlなどのデフォルトの設定ファイルの場所を使用してください。

Dockerを参照するコンテナスキャン変数

変数名にDOCKER_がプレフィックスとして付いているすべてのコンテナスキャン変数は非推奨です。これには、DOCKER_IMAGE、DOCKER_PASSWORD、DOCKER_USER、およびDOCKERFILE_PATH変数が含まれます。これらの変数のサポートは、GitLab 16.0リリースで削除されます。非推奨になった変数の名前の代わりに、新しい変数名であるCS_IMAGE、CS_REGISTRY_PASSWORD、CS_REGISTRY_USER、CS_DOCKERFILE_PATHを使用します。

コンテナレジストリのプルスルーキャッシュ

コンテナレジストリのプルスルーキャッシュはGitLab 15.8で非推奨となり、GitLab 16.0で削除されます。プルスルーキャッシュは、アップストリームのDocker Distributionプロジェクトの一部です。ただし、Docker HubからコンテナイメージをプロキシおよびキャッシュできるGitLab依存プロキシを優先して、プルスルーキャッシュを削除します。プルスルーキャッシュを削除すると、機能を犠牲にすることなく、アップストリームクライアントコードも削除できます。

GitLab for Jira CloudアプリのCookie認証

OAuth認証を優先して、GitLab for Jira CloudアプリのCookie認証は非推奨になりました。GitLab Self-Managedで、GitLab for Jira Cloudアプリを引き続き使用するには、OAuth認証を設定する必要があります。OAuthがないと、リンクされたネームスペースを管理できません。

DASTテンプレートを使用したDAST APIスキャンは非推奨

新しいDAST APIアナライザーと、DAST APIスキャン用のDAST-API.gitlab-ci.ymlテンプレートへの移行に伴い、DASTアナライザーでAPIをスキャンする機能は削除されます。APIスキャンでのDAST.gitlab-ci.ymlまたはDAST-latest.gitlab-ci.ymlテンプレートの使用は、GitLab 15.7の時点で非推奨となり、GitLab 16.0では機能しなくなります。DAST-API.gitlab-ci.ymlテンプレートを使用し、DAST APIアナライザーのドキュメントで設定の詳細を確認してください。

DAST API変数

GitLab 15.6で新しいDAST APIアナライザーに切り替えたことにより、2つの従来のDAST API変数が非推奨になります。変数DAST_API_HOST_OVERRIDEおよびDAST_API_SPECIFICATIONは、DAST APIスキャンには使用されなくなります。

OpenAPI仕様のホストを自動的にオーバーライドするDAST_API_TARGET_URLの使用を優先して、DAST_API_HOST_OVERRIDEは非推奨になりました。

DAST_API_OPENAPIを優先して、DAST_API_SPECIFICATIONは非推奨になりました。OpenAPI仕様を使用してテストをガイドし続けるには、DAST_API_SPECIFICATION変数をDAST_API_OPENAPI変数に置き換える必要があります。値は同じままでかまいませんが、変数名を置き換える必要があります。

これらの2つの変数は、GitLab 16.0で削除されます。

DASTレポート変数の非推奨化

GitLab 15.7で新しいブラウザベースのDASTアナライザーが一般公開になったため、将来的には、このアナライザーをデフォルトのDASTアナライザーにすることを目指しています。この準備として、従来のDAST変数DAST_HTML_REPORT、DAST_XML_REPORT、およびDAST_MARKDOWN_REPORTが非推奨になり、GitLab 16.0で削除される予定です。これらのレポートは従来のDASTアナライザーに依存しており、新しいブラウザベースのアナライザーに実装する予定はありません。GitLab 16.0の時点で、これらのレポートアーティファクトは生成されなくなります。

これらの3つの変数は、GitLab 16.0で削除されます。

Java 13、14、15、16の依存関係スキャンのサポート

GitLabは、Javaバージョン13、14、15、16の依存関係スキャンサポートを非推奨にしており、今後のGitLab 16.0リリースでそのサポートを削除する予定です。これらのバージョンのOracle PremierおよびExtended Supportが終了したため、これはOracleサポートポリシーと一致しています。これにより、GitLabは、依存関係スキャンJavaサポートで今後のLTSバージョンに重点を置くことができるようにもなりました。

updated_atとupdated_atを一緒に使用しない場合、デプロイAPIはをエラーを返す

updated_atフィルタリングとupdated_atソートを一緒に使用しない場合、デプロイAPIはエラーを返すようになります。一部のユーザーは、updated_atソートを使用せずに、updated_atでフィルタリングして「最新」のデプロイを取得していましたが、これは誤った結果をもたらす可能性があります。代わりに、それらを一緒に使用するか、finished_atでフィルタリングし、finished_atでソートするように移行する必要があります。これにより、「最新のデプロイ」が一貫して得られます。

従来のGitaly設定方法を非推奨化

環境変数GIT_CONFIG_SYSTEMとGIT_CONFIG_GLOBALを使用して、Gitalyを設定することは非推奨になりました。これらの変数は、標準のconfig.toml Gitaly設定に置き換えられています。

GIT_CONFIG_SYSTEMとGIT_CONFIG_GLOBALを使用してGitalyを設定するGitLabインスタンスは、config.tomlを使用して設定するように切り替える必要があります。

非推奨のConsul httpメトリクス

Linuxパッケージで提供されるConsulは、GitLab 16.0以降、以前の非推奨のConsulメトリクスを提供しなくなります。

GitLab 14.0では、Consulが1.9.6に更新され、一部のテレメトリメトリクスがconsul.httpパスに存在することは非推奨になりました。GitLab 16.0では、consul.httpパスが削除されます。

Consulメトリクスを使用するモニタリングがある場合は、consul.httpの代わりにconsul.api.httpを使用するように更新します。詳細については、Consul 1.9.0の非推奨化に関する注意を参照してください。

GitLab.comでのCI_PRE_CLONE_SCRIPT変数の非推奨化と計画された削除

GitLab.com RunnerでサポートされているCI_PRE_CLONE_SCRIPT変数は、GitLab 15.9の時点で非推奨となり、16.0で削除されます。CI_PRE_CLONE_SCRIPT変数を使用すると、RunnerがGit initとget fetchを実行する前に、CI/CDジョブでコマンドを実行できます。この機能の仕組みについて詳しくは、Pre-clone scriptを参照してください。別の方法として、pre_get_sources_scriptを使用できます。

グループにプロジェクトをインポートする機能を提供するデベロッパーロール

グループのデベロッパーロールを持つユーザーがそのグループにプロジェクトをインポートする機能はGitLab 15.8で非推奨となり、GitLab 16.0で削除されます。GitLab 16.0以降、グループのメンテナーロール以上のユーザーのみがそのグループにプロジェクトをインポートできます。

PHPおよびPython用の開発依存関係の報告

GitLab 16.0では、GitLab依存関係スキャンアナライザーは、Python/pipenvプロジェクトとPHP/composerプロジェクトの両方について、開発依存関係の報告を開始します。これらの開発依存関係の報告を希望しないユーザーは、CI/CDファイルでDS_INCLUDE_DEV_DEPENDENCIES: falseを設定する必要があります。

MarkdownでのGrafanaパネルの埋め込みは非推奨

GitLab Flavored MarkdownでのGrafanaパネルの追加機能は15.9で非推奨となり、16.0で削除されます。この機能を、GitLab可観測性UIでチャートを埋め込む機能に置き換える予定です。

CI/CDパラメータの文字長の強制検証

CI/CDのジョブ名には255文字の厳密な制限がありますが、他のCI/CDパラメータには、制限を超えないことを保証する検証がまだありません。

GitLab 16.0では、検証が追加され、次の項目も255文字に厳密に制限されます:

• stageキーワード。
• ref。これは、パイプラインのGitブランチまたはタグ名です。
• 外部CI/CDインテグレーションで使用されるdescriptionパラメータとtarget_urlパラメータ。

GitLab Self-Managedのユーザーは、255文字を超えるパラメータを使用しないように、パイプラインを更新する必要があります。GitLab.comのユーザーは、これらがそのデータベースですでに制限されているため、何も変更する必要はありません。

環境検索クエリには3文字以上が必要

GitLab 16.0以降、APIで環境を検索する場合、3文字以上を使用する必要があります。この変更は、検索操作のスケーラビリティを確保するのに役立ちます。

GraphQL ReleaseAssetLinkタイプの外部フィールド

GraphQL APIでは、ReleaseAssetLinkタイプのexternalフィールドを使用して、リリースリンクがGitLabインスタンスの内部であるか外部であるかを示していました。GitLab 15.9の時点で、すべてのリリースリンクを外部として扱っているので、このフィールドはGitLab 15.9で非推奨となり、GitLab 16.0で削除されます。externalフィールドは削除され、代替されないため、ワークフローの混乱を避けるために、このフィールドの使用を中止してください。

リリースおよびリリースリンクAPIの外部フィールド

リリースAPIとリリースリンクAPIでは、externalフィールドを使用して、リリースリンクがGitLabインスタンスの内部であるか外部であるかを示していました。GitLab 15.9の時点で、すべてのリリースリンクを外部として扱っているので、このフィールドはGitLab 15.9で非推奨となり、GitLab 16.0で削除されます。externalフィールドは削除され、代替されないため、ワークフローの混乱を避けるために、このフィールドの使用を中止してください。

GitLab管理者には保護ブランチまたはタグを変更する権限が必要

GitLab管理者は、保護されたブランチまたはタグに対してアクションを実行する権限が明示的に付与されていない限り、そのアクションを実行できなくなりました。これらのアクションには、保護されたブランチへのプッシュとマージ、ブランチの保護解除、保護されたタグの作成が含まれます。

GitLab自己モニタリングプロジェクト

GitLab自己モニタリングは、インスタンス管理者がインスタンスのヘルスを監視するためのツールを提供します。この機能はGitLab 14.9で非推奨となり、16.0で削除される予定です。

GraphQL API Runnerのステータスでpausedを返さなくなる

GitLab 16.0では、GraphQL API Runnerのエンドポイントは、ステータスとしてpausedまたはactiveを返しません。今後のREST API v5では、GitLab Runnerのエンドポイントもpausedまたはactiveを返しません。

Runnerのステータスは、online、offline、not_connectedなど、Runnerの接続ステータスのみに関連します。ステータスpausedまたはactiveは表示されなくなります。

Runnerがpausedかどうかを確認する場合、APIユーザーは、代わりにブール属性pausedがtrueであるかどうかを確認することをおすすめします。Runnerがactiveかどうかを確認する場合は、pausedがfalseであるかどうかを確認します。

Jira Cloud用のJira DVCSコネクタ

Jira Cloud用のJira DVCSコネクタは非推奨となり、GitLab 16.0で削除されます。Jira CloudでJira DVCSコネクタを使用している場合は、GitLab for Jira Cloudアプリに移行してください。

Jira DVCSコネクタはJira 8.13以前でも非推奨です。Jira DVCSコネクタは、Jira 8.14以降のJira ServerまたはJira Data Centerでのみ使用できます。

GitLab HelmチャートのKASメトリクスポート

GitLab Helmチャートの新しいgitlab.kas.observability.port設定フィールドを優先して、gitlab.kas.metrics.portは非推奨になりました。このポートは、メトリクスだけでなく、多くの目的に使用されるため、設定の混乱を避けるためにこの変更が必要になりました。

従来のGitaly設定方法

Omnibus GitLab内のGitaly設定は、すGitaly関連のべての設定キーが、標準のGitaly設定に一致する単一の設定構造になるように更新されました。そのため、以前の設定構造は非推奨になります。

単一の設定構造はGitLab 15.10から利用可能で、下位互換性は維持されます。削除後は、単一の設定構造を使用してGitalyを設定する必要があります。できるだけ早くGitalyの設定を更新する必要があります。

この変更により、Omnibus GitLabとソースインストールの整合性が向上し、両方に対してより優れたドキュメントとツールを提供できるようになります。

アップグレード手順を使用して、できるだけ早く新しい設定構造に更新する必要があります。

従来のPraefect設定方法

以前は、Praefect設定キーは設定ファイル全体に散在していました。現在、これらはPraefect設定に一致する単一の設定構造になっているため、以前の設定方法は非推奨になります。

単一の設定構造はGitLab 15.9から利用可能で、下位互換性は維持されます。削除後は、単一の設定構造を使用してPraefectを設定する必要があります。アップグレード手順を使用して、できるだけ早くPraefect設定を更新する必要があります。

この変更により、Omnibus GitLabのPraefect設定がPraefectの設定構造に準拠します。以前は、階層と設定キーが一致しませんでした。この変更により、Omnibus GitLabとソースインストールの整合性が向上し、両方に対してより優れたドキュメントとツールを提供できるようになります。

従来のURLの置き換えまたは削除

GitLab 16.0では、GitLabアプリケーションから従来のURLが削除されます。

GitLab 9.0でサブグループが導入されたとき、グループパスの終わりを示すために/-/区切り記号がURLに追加されました。GitLabのすべてのURLで、プロジェクト、グループ、インスタンスレベルの機能にこの区切り記号が使用されるようになりました。

/-/区切り記号を使用しないURLは、GitLab 16.0で削除される予定です。これらのURLの完全なリストとその代替については、イシュー28848を参照してください。

従来のURLを参照するスクリプトまたはブックマークを更新します。GitLab APIはこの変更の影響を受けません。

ライセンスチェックとライセンスコンプライアンスページのポリシータブ

License-Check feature（ライセンスチェック機能）は非推奨となり、GitLab 16.0で削除される予定です。さらに、ライセンスコンプライアンスページのポリシータブと、ライセンスチェック機能に関連するすべてのAPIは非推奨となり、GitLab 16.0で削除される予定です。検出されたライセンスに基づいて承認を引き続き適用したい場合は、代わりに新しいライセンス承認ポリシーを作成することをおすすめします。

外部認証を使用したパーソナルアクセストークン（PAT）とデプロイトークンのアクセスの制限

外部認証を有効にすると、パーソナルアクセストークン（PAT）とデプロイトークンは、コンテナまたはパッケージレジストリにアクセスできなくなります。この多層防御のセキュリティ対策は、16.0でデプロイされます。PATとデプロイトークンを使用してこれらのレジストリにアクセスするユーザーの場合、この対策によりこれらのトークンの使用が中断されます。コンテナまたはパッケージレジストリでトークンを使用するには、外部認証を無効にします。

GitLab Helmチャート用の主要なバンドルHelmチャートの更新

GitLab 16.0と同時に、GitLab Helmチャートは7.0のメジャーバージョンをリリースします。次の主要なバンドルチャートの更新が含まれます:

• GitLab 16.0では、PostgreSQL 12のサポートが削除され、PostgreSQL 13が新しい最小バージョンになります。
  • 本番環境対応の外部データベースを使用するインストールでは、アップグレードする前に、より新しいPostgreSQLバージョンへの移行を完了する必要があります。
  • 非本番環境バンドルPostgreSQL 12チャートを使用するインストールでは、チャートが新しいバージョンにアップグレードされます。詳細については、イシュー4118を参照してください。
• 非本番環境バンドルRedisチャートを使用するインストールでは、チャートが新しいバージョンにアップグレードされます。詳細については、イシュー3375を参照してください。
• バンドルされたcert-managerチャートを使用するインストールでは、チャートが新しいバージョンにアップグレードされます。詳細については、イシュー4313を参照してください。

GitLab Helmチャート7.0の完全なアップグレード手順は、アップグレードドキュメントで確認できます。

管理ライセンスAPI

管理ライセンスAPIは現在非推奨となっており、GitLab 16.0で削除される予定です。

Prometheusを介したパフォーマンスメトリクスのモニタリング

GitLabは、Prometheusインスタンスに格納されているデータを表示することにより、ユーザーがパフォーマンスメトリクスを閲覧できるようにします。GitLabは、ダッシュボードにもこれらのメトリクスの可視化を表示します。ユーザーは、以前に設定した外部Prometheusインスタンスに接続するか、PrometheusをGitLab Managed Appとして設定できます。ただし、GitLabではKubernetesクラスターとの証明書ベースのインテグレーションは非推奨であるため、Prometheusに依存するGitLabのメトリクス機能も非推奨となっています。これには、ダッシュボードでのメトリクスの表示も含まれます。GitLabは、Opstraceに基づいて単一のユーザーエクスペリエンスを開発することに取り組んでいます。Opstraceインテグレーションの作業をフォローするためのイシューが存在します。

有効期限のないアクセストークン

既存のプロジェクトアクセストークンに有効期限が自動的に適用されるかどうかは、お使いのGitLabの提供形態と、GitLab 16.0以降にアップグレードした時期によって異なります:

• GitLab.comでは、16.0マイルストーン期間中に、有効期限のない既存のプロジェクトアクセストークンには、現在の日付より365日後の有効期限日が自動的に付与されました。
• GitLab Self-Managedで、GitLab 15.11以前からGitLab 16.0以降にアップグレードした場合:
  • 2024年7月23日以前は、有効期限のない既存のプロジェクトアクセストークンには、現在の日付より365日後の有効期限日が自動的に付与されました。これは破壊的な変更です。
  • 2024年7月24日以降は、有効期限のない既存のプロジェクトアクセストークンには、有効期限日が設定されていませんでした。

GitLab Self-Managedで、次のいずれかのGitLabバージョンを新規インストールした場合、既存のプロジェクトアクセストークンに有効期限が自動的に適用されることはありません:

• 16.0.9
• 16.1.7
• 16.2.10
• 16.3.8
• 16.4.6
• 16.5.9
• 16.6.9
• 16.7.9
• 16.8.9
• 16.9.10
• 16.10.9
• 16.11.7
• 17.0.5
• 17.1.3
• 17.2.1

有効期限のないアクセストークンは無期限に有効であるため、アクセストークンが漏洩した場合、セキュリティリスクが生じます。有効期限のあるアクセストークンの方が優れているため、GitLab 15.3以降では、デフォルトの有効期限を設定します。

GitLab 16.0では、有効期限のないパーソナルアクセストークン 、プロジェクトアクセストークン 、またはグループアクセストークンには、1年の有効期限が自動的に設定されます。

次の期間にデフォルトが適用される前に、会社のセキュリティポリシーに沿ってアクセストークンに有効期限を設定することをおすすめします:

• GitLab.comでは、16.0マイルストーン期間中。
• GitLab Self-Managedでは、16.0にアップグレードされたとき。

非標準のデフォルトRedisポートは非推奨

GitLabがRedis設定ファイルなしで起動した場合、GitLabは、localhost:6380、localhost:6381、localhost:6382の3つのRedisサーバーに接続できると想定します。この動作を変更して、GitLabがlocalhost:6379に1つのRedisサーバーがあると想定するようにします。

3つのサーバーを維持したい管理者は、config/redis.cache.yml、config/redis.queues.yml、およびconfig/redis.shared_state.ymlファイルを編集して、Redis URLを設定する必要があります。

削除保護設定でプロジェクトをすぐに削除するオプションは非推奨

管理者エリアのグループおよびプロジェクト削除保護設定には、グループおよびプロジェクトをすぐに削除するオプションがありました。16.0以降、このオプションは利用できなくなり、グループとプロジェクトの遅延削除がデフォルトの動作になります。

このオプションは、グループ設定として表示されなくなります。GitLab Self-Managedのユーザーは、削除遅延期間を定義するオプションを引き続き利用でき、GitLab.comのユーザーには、調整できない7日間のデフォルトの保持期間があります。ユーザーは今までどおり、プロジェクト設定からはプロジェクトを、グループ設定からはグループをすぐに削除できます。

デフォルトでグループとプロジェクトをすぐに削除するオプションは、ユーザーが誤ってこのアクションを実行して、グループとプロジェクトを完全に失うことを防ぐために非推奨になりました。

PostgreSQL 12は非推奨

PostgreSQL 12のサポートは、GitLab 16.0で削除される予定です。GitLab 16.0では、PostgreSQL 13が、必要なPostgreSQLの最小バージョンになります。

PostgreSQL 12は、GitLab 15リリースサイクル全体でサポートされます。PostgreSQL 13は、GitLab 16.0より前にアップグレードする必要があるインスタンスでもサポートされます。

PostgreSQL 13のサポートは、GitLab 15.2でGeoに追加されました。

プロジェクトAPIフィールドoperations_access_levelは非推奨

プロジェクトAPIのoperations_access_levelフィールドは非推奨になります。このフィールドは、特定の機能を制御するフィールド（releases_access_level、environments_access_level、feature_flags_access_level、infrastructure_access_level、monitor_access_level）に置き換えられました。

Redis 5は非推奨

GitLab 13.9のOmnibus GitLabパッケージおよびGitLab Helmチャート4.9では、RedisバージョンがRedis 6に更新されました。Redis 5は2022年4月にサポートが終了し、GitLab 15.6の時点でサポートされなくなります。独自のRedis 5.0インスタンスを使用している場合は、GitLab 16.0以降にアップグレードする前に、Redis 6.0以降にアップグレードする必要があります。

POST /jobs/request Runnerエンドポイントからjob_ageパラメータを削除

GitLab Runnerとの通信で使用される、POST /jobs/request APIエンドポイントから返されるjob_ageパラメータは、GitLabとRunnerのどの機能でも使用されたことがありません。このパラメータはGitLab 16.0で削除されます。

これは、このエンドポイントから返されるこのパラメータに依存する独自のRunnerを開発した人にとっては、破壊的な変更になる可能性があります。これは、GitLab.comのパブリック共有Runnerを含む、公式にリリースされたバージョンのGitLab Runnerを使用している人にとっては、破壊的な変更ではありません。

GitLab 16.0でSASTアナライザーのカバレッジを変更

GitLab SASTは、さまざまなアナライザーを使用してコードをスキャンし、脆弱性を確認します。

GitLab SASTでデフォルトで使用されるサポート対象のアナライザーの数を削減しています。これは、さまざまなプログラミング言語で、より高速で一貫性のあるユーザーエクスペリエンスを実現するための長期的な戦略の一環です。

GitLab 16.0以降、GitLab SAST CI/CDテンプレートは、.NETに対してセキュリティコードスキャンベースのアナライザーを使用しなくなり、サポート終了ステータスになります。このアナライザーをSAST CI/CDテンプレートから削除し、SemgrepベースのアナライザーのC#用のGitLabサポート検出ルールに置き換えます。

このアナライザーはただちに、セキュリティアップデートのみを受け取ります。その他の定期的な改善や更新は保証されません。GitLab 16.0でこのアナライザーのサポートが終了した後、それ以上の更新は提供されません。ただし、このアナライザー用に以前に公開されたコンテナイメージを削除したり、カスタムCI/CDパイプラインジョブを使用して実行する機能を削除したりすることはありません。

非推奨のアナライザーからの脆弱性検出をすでに無視している場合、置き換え先のアナライザーは以前の無視判定に従うよう試みます。システム動作は以下に依存します:

• Semgrepベースのアナライザーの実行を過去に除外したかどうか。
• プロジェクトの脆弱性レポートに表示される脆弱性を最初に検出したアナライザー。

詳細については、脆弱性の移行ドキュメントを参照してください。

影響を受けるアナライザーにカスタマイズを適用した場合、またはパイプラインでSemgrepベースのアナライザーを現在無効にしている場合は、この変更の非推奨に関するイシューの記載に従って対処する必要があります。

更新: この変更の範囲を縮小しました。GitLab 16.0では、次の変更は行いません:

1. PHPCS Security Auditに基づくアナライザーのサポートを削除し、SemgrepベースのアナライザーでGitLabが管理する検出ルールに置き換える。
2. SpotBugsベースのアナライザーのスコープからScalaを削除し、SemgrepベースのアナライザーでGitLabが管理する検出ルールに置き換える。

PHPCS Security Auditベースのアナライザーを置き換える作業は、イシュー364060で追跡され、ScalaスキャンをSemgrepベースのアナライザーに移行する作業は、イシュー362958で追跡されます。

Secureアナライザーのメジャーバージョン更新

Secureステージでは、GitLab 16.0のリリースと連携して、アナライザーのメジャーバージョンが引き上げられます。この引き上げにより、以下のアナライザーの明確な区別が可能になります:

• 2023年5月22日より前にリリースされたもの
• 2023年5月22日以降にリリースされたもの

デフォルトの内蔵テンプレートを使用していない場合、またはアナライザーのバージョンを固定している場合は、CI/CDジョブ定義を更新して、固定されたバージョンを削除するか、最新のメジャーバージョンに更新する必要があります。GitLab 13.0-15.10のユーザーは、GitLab 16.0のリリースまでは通常どおりアナライザーの更新を引き続き利用できます。その後、新たに修正されたバグやリリースされた機能はすべて、アナライザーの新しいメジャーバージョンでのみリリースされます。メンテナンスポリシーに従い、バグや機能を非推奨バージョンにバックポートすることはありません。必要に応じて、セキュリティパッチは、最新の3つのマイナーリリース内でバックポートされます。具体的には、次に挙げるものが非推奨となっており、GitLab 16.0リリース以降は更新されません:

• APIファジング: バージョン2
• コンテナスキャン: バージョン5
• カバレッジガイドファズテスト: バージョン3
• 依存関係スキャン: バージョン3
• 動的アプリケーションセキュリティテスト（DAST）: バージョン3
• DAST API: バージョン2
• IaCスキャン: バージョン3
• ライセンススキャン: バージョン4
• シークレット検出: バージョン4
• 静的アプリケーションセキュリティテスト（SAST）: すべてのアナライザーのバージョン3
  • brakeman: バージョン3
  • flawfinder: バージョン3
  • kubesec: バージョン3
  • mobsf: バージョン3
  • nodejs-scan: バージョン3
  • phpcs-security-audit: バージョン3
  • pmd-apex: バージョン3
  • security-code-scan: バージョン3
  • semgrep: バージョン3
  • sobelow: バージョン3
  • spotbugs: バージョン3

セキュアスキャンのCI/CDテンプレートは新しいジョブrulesを使用

セキュリティスキャン用のGitLab管理CI/CDテンプレートは、GitLab 16.0リリースで更新されます。この更新には、CI/CDテンプレートの最新バージョンですでにリリースされている改善が含まれます。カスタマイズされたCI/CDパイプライン設定に混乱を招く可能性があるため、これらの変更は、最新のテンプレートバージョンでリリースしました。

更新されたすべてのテンプレートで、値が"true"の場合のみスキャンを無効にするように、SAST_DISABLEDやDEPENDENCY_SCANNING_DISABLEDなどの変数の定義を更新しています。以前は、値が"false"であっても、スキャンは無効になっていました。

次のテンプレートが更新されます:

• APIファジング: API-Fuzzing.gitlab-ci.yml
• コンテナスキャン: Container-Scanning.gitlab-ci.yml
• カバレッジガイドファジング: Coverage-Fuzzing.gitlab-ci.yml
• DAST: DAST.gitlab-ci.yml
• DAST API: DAST-API.gitlab-ci.yml
• 依存関係スキャン: Dependency-Scanning.gitlab-ci.yml
• IaCスキャン：SAST-IaC.gitlab-ci.yml
• SAST: SAST.gitlab-ci.yml
• シークレット検出: Secret-Detection.gitlab-ci.yml

上記のテンプレートのいずれかを使用していて、_DISABLED変数を使用しているが、"true"以外の値を設定している場合は、16.0リリース前にパイプラインをテストすることをおすすめします。

更新: 以前、影響を受けるテンプレートのrulesを更新して、デフォルトでマージリクエストパイプラインで実行することを発表しました。しかし、非推奨に関するイシューで議論されている互換性の問題により、GitLab 16.0でこの変更を行うことはなくなりました。上記で説明したように、_DISABLED変数の変更は引き続きリリースします。

セキュリティレポートスキーマバージョン14.x.x

バージョン14.x.xのセキュリティレポートスキーマは非推奨となります。

GitLab 15.8以降、スキーマバージョン14.x.xを使用するセキュリティレポートスキャナーのインテグレーションでは、パイプラインのセキュリティタブに非推奨の警告が表示されます。

GitLab 16.0以降、この機能は削除されます。スキーマバージョン14.x.xを使用するセキュリティレポートでは、パイプラインのセキュリティタブでエラーが発生します。

詳細については、セキュリティレポートの検証を参照してください。

Kubernetes向けGitLabエージェントの設定におけるStarboardディレクティブ

GitLabコンテナスキャン機能は、Starboardのインストールを必要としなくなります。その結果、Kubernetes向けGitLabエージェントの設定ファイルでstarboard:ディレクティブを使用することは非推奨となり、GitLab 16.0で削除される予定です。container_scanning:ディレクティブを使用するように設定ファイルを更新します。

Praefectカスタムメトリクスのエンドポイント設定のサポート

prometheus_exclude_database_from_default_metrics設定値の使用のサポートはGitLab 15.9で非推奨となり、GitLab 16.0で削除されます。この設定値を使用するとパフォーマンスが低下するため、削除します。この変更は、次のメトリクスが/metricsで使用できなくなることを意味します:

• gitaly_praefect_unavailable_repositories。
• gitaly_praefect_verification_queue_depth。
• gitaly_praefect_replication_queue_depth。

その結果、/db_metricsもスクレイプするようにメトリクス収集ターゲットを更新する必要がある場合があります。

Terraformステート名でのピリオド（.）のサポートによる、既存のステートが破損する可能性

以前は、ピリオドを含むTerraformステート名はサポートされていませんでした。ただし、回避策を使用して、ピリオドを含むステート名を使用することもできました。

GitLab 15.7では、ピリオドを含むステート名の完全なサポートが追加されました。回避策を使用してこれらのステート名を処理する場合は、ジョブが失敗したり、Terraformを初めて実行したように見えたりする場合があります。

この問題を解決するには:

1. ピリオドとそれに続く文字を除外して、ステートファイルへの参照を変更します。
   • たとえば、ステート名がstate.nameの場合は、すべての参照をstateに変更します。
2. Terraformコマンドを実行します。

ピリオドを含む完全なステート名を使用するには、完全なステートファイルに移行します。

APIはKubernetes向けエージェントの失効したトークンを返さなくなる

現在、クラスターエージェントAPIエンドポイントへのGETリクエストは、失効したトークンを返すことができます。GitLab 16.0では、GETリクエストは失効したトークンを返しません。

これらのエンドポイントに対する呼び出しを確認し、失効したトークンを使用しないようにしてください。

この変更は、次のRESTおよびGraphQL APIエンドポイントに影響します:

• REST API:
  • トークンのリストを取得する
  • 1つのトークンを取得する
• GraphQL:
  • ClusterAgent.tokens

Phabricatorタスクインポーターは非推奨

Phabricatorタスクインポーターは非推奨になります。プロジェクトとしてのPhabricator自体は、2021年6月1日以降、積極的にメンテナンスされなくなります。このツールを使用したインポートは確認されていません。GitLabで公開されている関連イシューでのアクティビティーはありません。

最新のTerraformテンプレートは現在の安定版テンプレートを上書き

GitLabのメジャーバージョンがリリースされるたびに、安定版のTerraformテンプレートを現在の最新テンプレートで更新します。この変更は、クイックスタートテンプレートとベーステンプレートに影響します。

新しいテンプレートにはデフォルトのルールが付属しているため、更新するとTerraformパイプラインが壊れる可能性があります。たとえば、Terraformジョブがダウンストリームパイプラインとしてトリガーされる場合、GitLab 16.0ではルールがジョブをトリガーしません。

変更に対応するには、.gitlab-ci.ymlファイルでrulesを調整する必要がある場合があります。

マージリクエストでの/draftクイックアクションの動作の切替

クイックアクションを介してマージリクエストのドラフトステータスを切り替える動作をより明確にするために、/draftクイックアクションの切替動作を非推奨にして削除します。GitLab 16.0のリリース以降、/draftはマージリクエストをドラフトに設定するだけとなり、新しい/readyクイックアクションを使用してドラフトステータスを削除します。

vulnerabilityFindingDismissミューテーションでのidフィールドの使用

vulnerabilityFindingDismiss GraphQLミューテーションを使用して、脆弱性検出のステータスをDismissedに設定できます。以前は、このミューテーションはidフィールドを使用して検出を一意に識別していました。ただし、この方法では、パイプラインセキュリティタブからの検出を無視できませんでした。したがって、識別子としてidフィールドを使用することは中止され、uuidフィールドが優先されることになりました。識別子として「uuid」フィールドを使用すると、パイプラインセキュリティタブから検出を無視できます。

サードパーティ製コンテナレジストリの使用は非推奨

GitLabを認証エンドポイントとして使用するサードパーティのコンテナレジストリの使用はGitLab 15.8で非推奨となり、サポートの終了はGitLab 16.0で予定されています。これは、コンテナイメージを検索、表示、削除するために、外部レジストリをGitLabのUIに接続しているGitLab Self-Managedのユーザーに影響します。

GitLabコンテナレジストリとサードパーティのコンテナレジストリの両方をサポートすることは、メンテナンス、コード品質、下位互換性の点で困難であり、効率性の維持を妨げることになります。その結果、今後はこの機能をサポートしません。

この変更は、パイプラインを使用してコンテナイメージを外部レジストリにプルおよびプッシュする機能には影響しません。

GitLab.com用の新しいGitLabコンテナレジストリバージョンをリリースして以来、サードパーティのコンテナレジストリでは利用できない追加機能の実装を開始しました。これらの新機能により、クリーンアップポリシーなど、大幅なパフォーマンス改善を達成できました。新機能を提供することに注力しており、そのほとんどはGitLabコンテナレジストリでのみ利用可能な機能が必要になります。この非推奨化により、より堅牢な統合レジストリエクスペリエンスと機能セットの提供に注力することを通じて、長期的に断片化とユーザーの不満を軽減できるようになります。

今後、GitLabコンテナレジストリでのみ利用可能な新機能の開発とリリースに引き続き取り組んでいきます。

パスの最後にグローバルIDがある作業アイテムのパスは非推奨

作業アイテムのURLでグローバルIDを使用することは非推奨です。将来的には、内部ID（IID）のみがサポートされます。

GitLabは複数の作業アイテムタイプをサポートしているため、https://gitlab.com/gitlab-org/gitlab/-/work_items/<global_id>などのパスには、たとえば、タスクやOKRが表示されることがあります。

GitLab 15.10では、最後にクエリパラメータ（iid_path）を追加することにより（https://gitlab.com/gitlab-org/gitlab/-/work_items/<iid>?iid_path=trueの形式）、そのパスで内部ID（IID）を使用するためのサポートを追加しました。

GitLab 16.0では、作業アイテムのパスでグローバルIDを使用する機能が削除されます。パスの最後にある数値は、最後にクエリパラメータを追加しなくても、内部ID（IID）と見なされます。サポートされる形式は、https://gitlab.com/gitlab-org/gitlab/-/work_items/<iid>のみです。

CI_BUILD_*定義済み変数

CI_BUILD_*で始まる定義済みのCI/CD変数はGitLab 9.0で非推奨となっていて、GitLab 16.0で削除されます。これらの変数をまだ使用している場合は、機能的に同一である代替定義済み変数に必ず変更してください:

POST ci/lint APIエンドポイントは非推奨

POST ci/lint APIエンドポイントは15.7で非推奨となり、16.0で削除されます。このエンドポイントは、CI/CD設定オプションのすべての範囲を検証しません。代わりに、CI/CD設定を適切に検証するPOST /projects/:id/ci/lintを使用してください。

DORA API用のenvironment_tierパラメータ

混乱と重複を避けるため、environment_tiersパラメータを優先して、environment_tierパラメータは非推奨になります。新しいenvironment_tiersパラメータを使用すると、DORA APIは複数のプランの集約データを同時に返すことができます。environment_tierパラメータはGitLab 16.0で削除されます。

PipelineSecurityReportFinding GraphQLタイプ用のnameフィールド

以前、PipelineSecurityReportFinding GraphQLタイプが更新され、新しいtitleフィールドが含まれるようになりました。このフィールドは現在のnameフィールドのエイリアスであり、特定性の低いnameフィールドは冗長になっています。nameフィールドは、GitLab 16.0でPipelineSecurityReportFindingタイプから削除されます。

startedイテレーションステート

イテレーションGraphQL APIおよびイテレーションREST APIのstartedイテレーションステートは非推奨となります。

GitLab 16.0でGraphQL APIバージョンは削除されます。このステートは、マイルストーンなど、他の時間ベースのエンティティの命名規則に合わせて、currentステート（すでに利用可能）に置き換えられます。

次のv5 REST APIバージョンまで、REST APIバージョンでstartedステートのサポートを継続する予定です。

vulnerabilityFindingDismiss GraphQLミューテーション

VulnerabilityFindingDismiss GraphQLミューテーションは非推奨となり、GitLab 16.0で削除されます。このミューテーションは、ユーザーが脆弱性検出IDを利用できなかったため（このフィールドは15.3で非推奨になりました）、あまり使用されていませんでした。代わりに、ユーザーは脆弱性レポートの脆弱性を無視するにはVulnerabilityDismissを、CIパイプラインセキュリティタブのセキュリティ検出結果を無視するにはSecurityFindingDismissを使用する必要があります。

OpenStack SwiftおよびRackspace APIを使用した自動バックアップのアップロード

OpenStack SwiftおよびRackspace APIを使用したuploading backups to remote storage（リモートストレージへのバックアップのアップロード）のサポートを非推奨にします。これらのAPIのサポートは、積極的にメンテナンスされなくなり、Ruby 3用に更新されていないサードパーティライブラリに依存しています。GitLabは、セキュリティパッチを最新に保つため、Ruby 2のEOLより前にRuby 3に移行しています。

• OpenStackを使用している場合は、Swiftの代わりにS3 APIを使用するように設定を変更する必要があります。
• Rackspaceストレージを使用している場合は、別のプロバイダーに切り替えるか、バックアップタスクの完了後にバックアップファイルを手動でアップロードする必要があります。

Web IDEでのライブプレビューの利用停止

Web IDEのライブプレビュー機能は、静的なWebアプリケーションのクライアント側のプレビューを提供するように設計されていました。ただし、設定手順が複雑で、サポートされているプロジェクトタイプの範囲が狭いため、その有用性は限られています。GitLab 15.7でWeb IDEベータ版が導入されたことで、フルサーバー側のランタイム環境に接続できるようになりました。Web IDEで拡張機能をインストールすることを今後サポートするともに、ライブプレビューで利用できるワークフローよりも高度なワークフローのサポートも提供します。GitLab 15.9以降、Web IDEでライブプレビューは利用できなくなります。

omniauth-authentiq gemの利用停止

omniauth-authentiqは、GitLabの一部であったOmniAuth戦略gemです。認証サービスを提供する会社であるAuthentiqが閉鎖されました。そのため、gemは削除されます。

.gitlab-ci.ymlでのファイルタイプ変数の展開

以前は、エイリアスファイル変数を参照または適用していた変数では、File型変数の値を展開していました。たとえば、ファイルの内容です。この動作は、一般的なシェル変数展開ルールに準拠していないため、正しくありませんでした。File型変数に保存されているシークレットまたは機密情報を漏洩させるために、ユーザーが、変数を入力パラメータとして指定して$echoコマンドを実行する可能性がありました。

この破壊的な変更によりこの問題が修正されますが、この動作に対処するユーザーワークフローが混乱する可能性があります。この変更により、エイリアスファイル変数を参照または適用するジョブ変数展開は、ファイルの内容などの値の代わりに、File型変数のファイル名またはパスに展開されます。

SASTアナライザーの統合とCI/CDテンプレートの変更

GitLab SASTは、さまざまなアナライザーを使用してコードをスキャンし、脆弱性を確認します。

より優れた一貫性のあるユーザーエクスペリエンスを提供するための長期的な戦略の一環として、GitLab SASTで使用されるアナライザーの数を減らしています。アナライザーのセットを効率化すると、イテレーションの高速化、結果の向上、効率性の向上（ほとんどの場合、CI Runnerの使用量の削減を含む）が可能になります。

GitLab 15.4では、GitLab SASTは次のアナライザーを使用しなくなります:

• ESLint（JavaScript、TypeScript、React）
• Gosec
• Bandit（Python）

注: この変更は当初、GitLab 15.0で計画されていましたが、GitLab 15.4に延期されました。

これらのアナライザーはGitLab管理のSAST CI/CDテンプレートから削除され、Semgrepベースのアナライザーに置き換えられます。これらのアナライザーはただちに、セキュリティアップデートのみを受信するようになります。その他の定期的な改善や更新は保証されません。これらのアナライザーがサポート終了になると、それ以上の更新は提供されません。これらのアナライザー用に以前に公開したコンテナイメージは削除しません。そのような変更は、非推奨化、削除、または破壊的な変更の発表として発表します。

また、SpotBugsアナライザーのスコープからJavaを削除し、Semgrepベースのアナライザーに置き換えます。この変更により、Javaコードのスキャンが簡単になり、コンパイルが不要になります。この変更は、GitLab管理のSAST CI/CDテンプレートの自動言語検出部分に反映されます。SpotBugsベースのアナライザーは、Groovy、Kotlin、Scalaを引き続きカバーすることに注意してください。

いずれかの非推奨アナライザーからの脆弱性検出をすでに無視している場合、置き換え先のアナライザーは以前の無視判定に従うよう試みます。システム動作は以下に依存します:

• Semgrepベースのアナライザーの実行を過去に除外したかどうか。
• プロジェクトの脆弱性レポートに表示される脆弱性を最初に検出したアナライザー。

詳細については、脆弱性の移行ドキュメントを参照してください。

影響を受けるアナライザーのいずれかにカスタマイズを適用した場合、またはパイプラインでSemgrepアナライザーを現在無効にしている場合は、この変更の非推奨に関するイシューにの記載に従って対処する必要があります。

リポジトリプッシュイベントの監査イベント

repository events（リポジトリイベント）の監査イベントは非推奨となり、GitLab 15.0で削除されます。

これらのイベントは常にデフォルトで無効になっており、機能フラグを使用して手動で有効にする必要がありました。これらを有効にすると、生成されるイベントが多すぎてGitLabインスタンスの速度が大幅に低下する可能性があります。そのため、これらは削除されています。

オブジェクトストレージのバックグラウンドアップロード

オブジェクトストレージ機能の全体的な複雑さとメンテナンスの負担を軽減するために、background_uploadを使用してファイルをアップロードするサポートは非推奨となり、GitLab 15.0で完全に削除されます。オブジェクトストレージ用の削除されたバックグラウンドアップロード設定の15.0固有の変更点を確認してください。

これは、オブジェクトストレージプロバイダーの小さなサブセットに影響を与えます:

• OpenStack: OpenStackをご利用のお客様は、Swiftの代わりにS3 APIを使用するように設定を変更する必要があります。
• RackSpace: RackSpaceベースのオブジェクトストレージをご利用のお客様は、データを別のプロバイダーに移行する必要があります。

GitLabは、影響を受けるお客様の移行を支援するために、追加のガイダンスを公開します。

CI/CDジョブ名の長さ制限

GitLab 15.0では、CI/CDジョブ名の文字数を255文字に制限します。ジョブ名が255文字の制限を超えるパイプラインは、15.0のリリース後に動作しなくなります。

インスタンス（共有）Runnerをプロジェクト（特定）Runnerに変更

GitLab 15.0では、インスタンス（共有）Runnerをプロジェクト（特定）Runnerに変更できなくなります。

ユーザーはインスタンスRunnerをプロジェクトRunnerに誤って変更することが多く、元に戻すことができません。GitLabでは、セキュリティ上の理由から、プロジェクトRunnerを共有Runnerに変更することはできません。1つのプロジェクトを対象としたRunnerが、インスタンス全体のジョブを実行するように設定される可能性があります。

複数のプロジェクトにRunnerを追加する必要がある管理者は、1つのプロジェクトにRunnerを登録してから、管理者ビューに移動して追加のプロジェクトを選択することができます。

コンテナネットワークとホストのセキュリティ

GitLabコンテナネットワークセキュリティおよびコンテナホストセキュリティのカテゴリに関連するすべての機能は、GitLab 14.8で非推奨となり、GitLab 15.0で削除される予定です。この機能の代替が必要なユーザーは、GitLabの外部でインストールして管理できる潜在的なソリューションとして、オープンソースプロジェクトの: AppArmor 、Cilium 、Falco 、FluentD 、Podセキュリティアドミッションを評価することをおすすめします。

これらのテクノロジーをGitLabに統合するには、クラスター管理プロジェクトテンプレートのコピーに目的のHelmチャートを追加します。GitLab CI/CDを介してコマンドを呼び出すことにより、これらのHelmチャートを本番環境にデプロイします。

この変更の一環として、GitLab内の次の特定の機能が非推奨となり、GitLab 15.0で削除される予定です:

• Security & Compliance（セキュリティとコンプライアンス） > Threat Monitoring（脅威モニタリング）ページ。
• Security & Compliance（セキュリティとコンプライアンス） > ポリシーページにあるNetwork Policyセキュリティポリシータイプ。
• GitLabを介して複数のテクノロジー、つまり: AppArmor、Cilium、Falco、FluentD、Podセキュリティポリシーとのインテグレーションを管理する機能。
• 上記の機能に関連するすべてのAPI。

追加のコンテキストが必要な場合や、この変更に関するフィードバックを提供する場合は、公開されている非推奨に関するイシューを参照してください。

依存関係スキャンPython 3.9および3.6イメージの非推奨化

Pythonプロジェクトに依存関係スキャンを使用しているユーザーを対象として、Python 3.6を使用するデフォルトのgemnasium-python:2イメージと、Python 3.9を使用するカスタムgemnasium-python:2-python-3.9イメージを非推奨にします。GitLab 15.0以降の新しいデフォルトイメージは、Python 3.9用になります。Python 3.9がサポートされているバージョンであり、3.6はサポートされなくなるためです。

Python 3.9または3.9互換のプロジェクトを使用しているユーザーは、アクションを実行する必要はなく、依存関係スキャンはGitLab 15.0で動作するはずです。新しいコンテナを今すぐテストする場合は、このコンテナ（15.0で削除されます）を使用してプロジェクトでテストパイプラインを実行してください。Python 3.9イメージを使用します:

gemnasium-python-dependency_scanning:
  image:
    name: registry.gitlab.com/gitlab-org/security-products/analyzers/gemnasium-python:2-python-3.9

Python 3.6を使用しているユーザーの場合、GitLab 15.0以降では、依存関係スキャンのためにデフォルトテンプレートを使用できなくなります。非推奨のgemnasium-python:2アナライザーイメージの使用に切り替える必要があります。これによって影響を受ける場合は、このイシューにコメントしてください。必要に応じて削除を延長できます。

3.9の特別な例外イメージを使用しているユーザーは、代わりにデフォルト値を使用して、コンテナを上書きしないようにする必要があります。3.9の特別な例外イメージを使用しているかどうかを確認するには、.gitlab-ci.ymlファイルで次の参照を確認してください:

gemnasium-python-dependency_scanning:
  image:
    name: registry.gitlab.com/gitlab-org/security-products/analyzers/gemnasium-python:2-python-3.9

依存関係スキャンのデフォルトJavaバージョンを17に変更

GitLab 15.0では、依存関係スキャンの場合、スキャナーが予期するJavaのデフォルトバージョンが11から17に更新されます。Java 17は最新の長期サポート（LTS）バージョンです。依存関係スキャンは、同じバージョン範囲（8、11、13、14、15、16、17）を引き続きサポートしており、デフォルトバージョンのみが変更されます。プロジェクトが以前のJava 11のデフォルトを使用している場合は、一致するようにDS_Java_Version変数を設定してください。

機能フラグPUSH_RULES_SUPERSEDE_CODE_OWNERSを非推奨化

機能フラグPUSH_RULES_SUPERSEDE_CODE_OWNERSは、GitLab 15.0で削除されます。削除すると、プッシュルールはコードオーナーよりも優先されます。コードオーナーの承認が必要な場合でも、特定のユーザーがコードをプッシュすることを明示的に許可するプッシュルールは、コードオーナー設定よりも優先されます。

Elasticsearch 6.8

Elasticsearch 6.8はGitLab 14.8で非推奨となり、GitLab 15.0で削除される予定です。Elasticsearch 6.8を使用しているお客様は、GitLab 15.0にアップグレードする前に、Elasticsearchのバージョンを7.xにアップグレードする必要があります。Elasticsearchのすべての改善機能を活用するには、最新バージョンのElasticsearch 7を使用することをおすすめします。

Elasticsearch 6.8は、GitLab 15.0でサポートする予定のAmazon OpenSearchとも互換性がありません。

外部ステータスチェックAPIの破壊的な変更

外部ステータスチェックAPIは当初、ステータスチェックに合格としてマークされる、デフォルトで合格するリクエストをサポートするために実装されました。デフォルトで合格するリクエストは現在非推奨です。具体的には、次のリクエストが非推奨です:

• statusフィールドを含まないリクエスト。
• statusフィールドがapprovedに設定されているリクエスト。

GitLab 15.0以降、ステータスチェックは、statusフィールドが存在し、かつpassedに設定されている場合にのみ、合格に更新されます。各タイプのリクエストの動作:

• statusフィールドが含まれていない場合、422エラーで拒否されます。詳細については、関連イシューを参照してください。
• passed以外の値が含まれている場合、ステータスチェックが失敗します。詳細については、関連イシューを参照してください。

この変更に合わせて、外部ステータスチェックを一覧表示するAPIコールでも、合格したステータスチェックに対して、approvedではなく、passedの値が返されるようになります。

GitLab Serverless

GitLab Serverlessは、自動デプロイとモニタリングによるKnativeベースのサーバーレス開発をサポートするための機能セットです。

GitLab Serverlessの機能は、ユーザーから十分な反響が得られなかったため、削除することにしました。さらに、KubernetesとKnativeは進歩し続けているため、現在の実装は最新バージョンでは動作しません。

GraphQL IDとGlobalIDの互換性

下位互換性のために追加した、GraphQLプロセッサへの非標準の拡張機能を削除します。この拡張機能はGraphQLクエリの検証を変更し、通常は拒否される引数にIDタイプを使用できるようにします。一部の引数は元々IDタイプでした。これらは、特定の種類のIDに変更されました。この変更は、次の場合に破壊的な変更になる可能性があります:

• GraphQLを使用する。
• クエリシグネチャの引数にIDタイプを使用する。

一部のフィールドの引数では、依然としてIDタイプが使用されています。これらは通常、IID値またはネームスペースパス用です。たとえば、Query.project(fullPath: ID!)などがあります。

影響を受けるフィールドの引数と影響を受けないフィールドの引数のリストについては、非推奨に関するイシューを参照してください。

GitLabサーバーから取得したスキーマデータを使用して、クエリをローカルで検証することで、この変更による影響があるかどうかをテストできます。これを行うには、関連するGitLabインスタンスのGraphQLエクスプローラーツールを使用します。例: https://gitlab.com/-/graphql-explorer。

たとえば、次のクエリは、破壊的な変更を示しています:

# a query using the deprecated type of Query.issue(id:)
# WARNING: This will not work after GitLab 15.0
query($id: ID!) {
  deprecated: issue(id: $id) {
    title, description
  }
}

上記のクエリは、Query.issue(id:)のタイプが実際にはIssueID!であるため、GitLab 15.0のリリース後には機能しません。

代わりに、次の2つの形式のいずれかを使用する必要があります:

# This will continue to work
query($id: IssueID!) {
  a: issue(id: $id) {
    title, description
  }
  b: issue(id: "gid://gitlab/Issue/12345") {
    title, description
  }
}

このクエリは現在機能し、GitLab 15.0以降も引き続き機能します。最初の形式（シグネチャで名前付きタイプとしてIDを使用）のクエリは、他の2つの形式（シグネチャで正しい適切なタイプを使用するか、インライン引数式を使用）のいずれかに変換する必要があります。

パッケージ設定でのGraphQL権限の変更

GitLab Packageステージはパッケージレジストリ、コンテナレジストリ、依存プロキシを提供することで、GitLabを使用してすべての依存関係を管理できるようにします。これらの各製品カテゴリには、APIを使用して調整できるさまざまな設定があります。

GraphQLの権限モデルが更新されます。15.0以降、ゲスト、レポーター、デベロッパーのロールを持つユーザーは、次の設定を更新できなくなります:

• パッケージレジストリ設定
• コンテナレジストリクリーンアップポリシー
• 依存プロキシの有効期限ポリシー
• グループの依存プロキシの有効化

GitLab Runner SSH executorに必要な既知のホスト

GitLab 14.3で、GitLab Runner config.tomlファイルに設定項目を追加しました。この設定である[runners.ssh.disable_strict_host_key_checking]は、SSH executorで厳密なホストキーチェックを使用するかどうかを制御します。

GitLab 15.0以降、この設定オプションのデフォルト値は、trueからfalseに変更されます。これは、GitLab Runner SSH executorを使用する場合に、厳密なホストキーチェックが適用されることを意味します。

ライセンスコンプライアンスAPIの従来の承認ステータス名

managed_licenses APIでライセンスポリシーの承認ステータスの従来の名前（blacklisted、approved）を非推奨にしましたが、APIクエリと応答では引き続き使用されています。これらの名前は15.0で削除されます。

ライセンスコンプライアンスAPIを使用している場合は、approvedおよびblacklistedクエリパラメータの使用を停止する必要があります。このパラメータは現在、allowedおよびdeniedです。15.0では、応答でapprovedとblacklistedの使用も停止されるため、新旧の値を使用するようにカスタムツールを調整して、15.0リリースで破損しないようにする必要があります。

従来のデータベース設定

database.ymlにあるGitLabデータベース設定の構文が変更され、従来の形式は非推奨になります。従来の形式は単一のPostgreSQLアダプターの使用をサポートしていましたが、新しい形式は複数のデータベースをサポートするように変更されています。main:データベースは、最初の設定アイテムとして定義する必要があります。

この設定はOmnibusで自動的に処理されるため、この非推奨は主にソースからGitLabをコンパイルするユーザーに影響します。

GitLabでのログ機能

GitLabのログ生成機能を使用すると、ユーザーはELK（Elasticsearch、Logstash、Kibana）をインストールして、アプリケーションログを集約および管理できます。ユーザーはGitLabで関連するログを検索できます。ただし、KubernetesクラスターとGitLab Managed Appsとの証明書ベースのインテグレーションを非推奨にして以来、GitLab内でのログ生成に推奨されるソリューションはありません。詳細については、OpstraceとGitLabのインテグレーションに関するイシューを参照してください。

OAuthの暗黙的付与

OAuthの暗黙的付与認証フローは、次期メジャーリリースであるGitLab 15.0で削除されます。OAuthの暗黙的付与を使用するすべてのアプリケーションは、代替のサポートされているOAuthフローに切り替える必要があります。

有効期限のないOAuthトークン

すべての新しいアプリケーションでは、デフォルトでアクセストークンの有効期限が2時間後に切れます。GitLab 14.2以前は、OAuthアクセストークンに有効期限はありませんでした。GitLab 15.0では、有効期限がまだない既存のトークンに対して有効期限が自動的に生成されます。

GitLab 15.0のリリース前に、トークンを有効期限切れにするようオプトインする必要があります:

1. アプリケーションを編集します。
2. Expire access tokens（アクセストークンを有効期限切れにする）を選択して有効にします。トークンを失効させる必要があります。そうしないと、有効期限が切れません。

OmniAuth Kerberos gem

次のメジャーリリースであるGitLab 15.0で、omniauth-kerberos gemが削除されます。

このgemはメンテナンスされておらず、使用頻度は非常に低いです。そのため、この認証方法のサポートを削除する予定であり、代わりにKerberos SPNEGOインテグレーションを使用することをおすすめします。アップグレード手順に従って、omniauth-kerberosインテグレーションから、サポートされているインテグレーションにアップグレードできます。

Kerberos SPNEGOインテグレーションは非推奨にしていません。非推奨にするのは古いパスワードベースのKerberosインテグレーションのみです。

PAT有効期限をオプションで適用

セキュリティの観点からは、PAT有効期限の適用を無効にする機能は一般的ではありません。この一般的でない機能により、ユーザーにとって予期しない動作が引き起こされる可能性があることが懸念されます。セキュリティ機能での予期しない動作は本質的に危険であるため、この機能を削除することにしました。

SSH有効期限をオプションで適用

セキュリティの観点からは、SSH有効期限の適用を無効にする機能は一般的ではありません。この一般的でない機能により、ユーザーにとって予期しない動作が引き起こされる可能性があることが懸念されます。セキュリティ機能での予期しない動作は本質的に危険であるため、この機能を削除することにしました。

Java 8の標準サポート（SAST）

GitLab SAST SpotBugsアナライザーは、Java、Scala、Groovy、Kotlinコードをスキャンし、セキュリティの脆弱性を確認します。技術的な理由により、アナライザーは最初にコードをコンパイルしてからスキャンする必要があります。プリコンパイル戦略を使用しない限り、アナライザーはプロジェクトのコードを自動的にコンパイルしようとします。

15.0以前のGitLabバージョンでは、コンパイルを容易にするために、アナライザーイメージにJava 8およびJava 11ランタイムが含まれています。

GitLab 15.0では、次のようになります:

• イメージのサイズを小さくするために、アナライザーイメージからJava 8を削除します。
• Java 17でのコンパイルを容易にするために、アナライザーイメージにJava 17を追加します。

アナライザー環境にあるJava 8を利用している場合は、この変更の非推奨に関するイシューの記載に従って対処する必要があります。

高度な検索の移行の古いインデックス

高度な検索の移行では通常、長期間にわたって複数のコードパスをサポートする必要があるため、安全なクリーンアップが可能になったら、それらをクリーンアップすることが重要です。GitLabのメジャーバージョンアップグレードは、完全に移行されていないインデックスの下位互換性を削除する安全な期間として利用されます。詳細については、アップグレードドキュメントを参照してください。

instanceStatisticsMeasurements GraphQLノードを介した使用状況トレンドのクエリ

13.10でinstanceStatisticsMeasurements GraphQLノードの名前はusageTrendsMeasurementsに変更され、古いフィールド名は非推奨としてマークされています。既存のGraphQLクエリを修正するには、instanceStatisticsMeasurementsをusageTrendsMeasurementsに置き換えます。

リクエストプロファイリング

リクエストプロファイリングは、GitLab 14.8で非推奨となり、GitLab 15.0で削除される予定です。

プロファイリングツールを統合して、より簡単にアクセスできるようにすることに取り組んでいます。この機能の使用を評価したところ、広く使用されていないことがわかりました。また、この機能はいくつかのサードパーティ製gemに依存しており、これらのgemは、積極的にメンテナンスされなくなっていたり、最新バージョンのRuby用に更新されていなかったり、高負荷のページをプロファイリングする際に頻繁にクラッシュしたりします。

詳細については、非推奨に関するイシューの概要セクションを確認してください。

Premiumプランで必須のパイプライン設定

必須のパイプライン設定機能は、Premiumのお客様にはGitLab 14.8で非推奨となり、GitLab 15.0で削除される予定です。この機能は、GitLab Ultimateのお客様には非推奨ではありません。

この機能に対する需要は主に経営幹部から発生しているため、この機能をGitLab Ultimateプランに移行する変更は、機能を当社の価格に関する考え方とより良く合致させることを目的としています。

この変更は、GitLabが階層化戦略において、関連するその他のUltimateプランの機能である: セキュリティポリシーおよびコンプライアンスパイプラインとの整合性を保つのにも役立ちます。

Retire-JS依存関係スキャンツール

14.8の時点で、retire.jsジョブは依存関係スキャンで非推奨となっています。非推奨になっている間は、引き続きCI/CDテンプレートに含まれます。GitLab 15.0で2022年5月22日に、依存関係スキャンからretire.jsを削除します。JavaScriptスキャン機能は、Gemnasiumによって引き続きカバーされているため、影響を受けません。

DS_EXCLUDED_ANALYZERSを使用してretire.jsを明示的に除外した場合は、15.0でクリーンアップ（参照を削除）する必要があります。retire-js-dependency_scanningジョブに関連するパイプラインの依存関係スキャンの設定をカスタマイズした場合は、15.0で削除される前にgemnasium-dependency_scanningに切り替えて、パイプラインが失敗しないようにする必要があります。DS_EXCLUDED_ANALYZERSを使用してretire.jsを参照していない場合、または特にretire.js用にテンプレートをカスタマイズしていない場合、対応は不要です。

.NET 2.1用のSASTサポート

GitLab SASTセキュリティコードスキャンアナライザーは、.NETコードをスキャンして、セキュリティの脆弱性を確認します。技術的な理由により、アナライザーは最初にコードをビルドしてスキャンする必要があります。

15.0より前のGitLabバージョンでは、以下に対するサポートがデフォルトのアナライザーイメージ（バージョン2）に含まれています:

• .NET 2.1
• .NET 3.0および.NET Core 3.0
• .NET Core 3.1
• .NET 5.0

GitLab 15.0では、このアナライザーのデフォルトのメジャーバージョンをバージョン2からバージョン3に変更します。この変更の内容は次のとおりです:

• 脆弱性の重大度値とその他の新機能および改善を追加します。
• .NET 2.1のサポートを削除します。
• .NET 6.0、Visual Studio 2019、Visual Studio 2022のサポートを追加します。

バージョン3はGitLab 14.6で発表され、オプションのアップグレードとして利用できるようになりました。

デフォルトでアナライザーイメージにある.NET 2.1のサポートを利用している場合は、この変更の非推奨に関するイシューの記載に従って対処する必要があります。

新しい場所で公開されたSecureおよびProtectアナライザーのイメージ

GitLabは、さまざまなアナライザーを使用してセキュリティの脆弱性をスキャンします。各アナライザーはコンテナイメージとして配布されます。

GitLab 14.8以降、GitLab SecureおよびProtectアナライザーの新しいバージョンは、registry.gitlab.com/security-productsの下の新しいレジストリの場所に公開されます。

この変更を反映するために、GitLab管理のCI/CDテンプレートのデフォルト値を更新します:

• コンテナスキャンを除くすべてのアナライザーについて、変数SECURE_ANALYZERS_PREFIXを新しいイメージレジストリの場所に更新します。
• コンテナスキャンの場合、デフォルトのイメージアドレスはすでに更新されています。コンテナスキャンにはSECURE_ANALYZERS_PREFIX変数はありません。

将来のリリースでは、registry.gitlab.com/gitlab-org/security-products/analyzersへのイメージの公開を停止します。イメージの公開が停止された後で、手動でイメージをプルして別のレジストリにプッシュする場合は、対応が必要になります。この状況は、オフラインデプロイの場合によくあります。対応しないと、それ以上の更新は受信されません。

詳細については、非推奨に関するイシューを参照してください。

SecureおよびProtectアナライザーのメジャーバージョン更新

SecureおよびProtectのステージでは、GitLab 15.0リリースと連携して、アナライザーのメジャーバージョンが引き上げられます。このメジャーバージョンの引き上げにより、以下のアナライザーの明確な区別が可能になります:

• 2022年5月22日より前にリリースされたアナライザー。厳格なスキーマ検証の対象_ではない_レポートを生成します。
• 2022年5月22日より後にリリースされたアナライザー。厳格なスキーマ検証の対象_である_レポートを生成します。

デフォルトの内蔵テンプレートを使用していない場合、またはアナライザーのバージョンを固定している場合は、CI/CDジョブ定義を更新して、固定されたバージョンを削除するか、最新のメジャーバージョンに更新する必要があります。GitLab 12.0-14.10のユーザーは、GitLab 15.0のリリースまで通常どおりアナライザーの更新を引き続き利用できます。その後、GitLabではメンテナンスポリシーに従ってバグや新機能のバックポートを行わないため、アナライザーの新しいメジャーバージョンで新たに修正されたバグや新しくリリースされた機能は、非推奨バージョンでは利用できなくなります。必要に応じて、セキュリティパッチは最新の3つのマイナーリリース内でバックポートされます。具体的には、次に挙げるものが非推奨となっており、GitLab 15.0リリース以降は更新されません:

• APIセキュリティ: バージョン1
• コンテナスキャン: バージョン4
• カバレッジガイドファズテスト: バージョン2
• 依存関係スキャン: バージョン2
• 動的アプリケーションセキュリティテスト（DAST）: バージョン2
• Infrastructure as Code（IaC）スキャン: バージョン1
• ライセンススキャン: バージョン3
• シークレット検出: バージョン3
• 静的アプリケーションセキュリティテスト（SAST）: すべてのアナライザーのバージョン2（ただし、現在はバージョン3のgosecを除く）
  • bandit: バージョン2
  • brakeman: バージョン2
  • eslint: バージョン2
  • flawfinder: バージョン2
  • gosec: バージョン3
  • kubesec: バージョン2
  • mobsf: バージョン2
  • nodejs-scan: バージョン2
  • phpcs-security-audit: バージョン2
  • pmd-apex: バージョン2
  • security-code-scan: バージョン2
  • semgrep: バージョン2
  • sobelow: バージョン2
  • spotbugs: バージョン2

Sidekiqメトリクスとヘルスチェックの設定

単一のプロセスとポートを使用してSidekiqメトリクスとヘルスチェックをエクスポートすることは非推奨になります。15.0でサポートが削除されます。

安定性と可用性を向上させ、エッジケースでのデータ損失を防ぐために、2つの個別のプロセスからメトリクスとヘルスチェックをエクスポートするようにSidekiqを更新しました。これらは2つの個別のサーバーであるため、15.0では、メトリクスとヘルスチェックに個別のポートを明示的に設定するための設定変更が必要になります。sidekiq['health_checks_*']用に新しく導入された設定は、常にgitlab.rbで設定する必要があります。詳細については、Sidekiqの設定に関するドキュメントを確認してください。

これらの変更では、新しいエンドポイントをスクレイプするためのPrometheus、または新しいヘルスチェックポートをターゲットとして正常に機能させるためのk8sヘルスチェックのいずれかの更新も必要です。そうしないと、メトリクスまたはヘルスチェックが表示されなくなります。

非推奨期間中、これらの設定はオプションであり、GitLabはSidekiqヘルスチェックポートをsidekiq_exporterと同じポートにデフォルト設定し、1つのサーバーのみを実行します（現在の動作は変更されません）。両方が設定され、異なるポートが提供されている場合にのみ、個別のメトリクスサーバーが起動してSidekiqメトリクスを提供します。これは、15.0でのSidekiqの動作と同様です。

SLES 12 SP2のサポート

SUSE Linux Enterprise Server（SLES）12 SP2の長期サービスとサポート（LTSS）は、2021年3月31日に終了しました。SP2のCA証明書には、期限切れのDSTルート証明書が含まれており、新しいCA証明書パッケージの更新は取得されていません。いくつかの回避策を実装しましたが、ビルドを正常に実行し続けることはできません。

Gitalyと他のGitLabの間にデプロイされたgRPC対応プロキシのサポート

推奨もドキュメント化もされていませんが、Gitalyと他のGitLabの間にgRPC対応プロキシをデプロイすることができました。たとえば、NGINXやEnvoyなどです。gRPC対応プロキシをデプロイする機能は非推奨になりました。現在、Gitaly接続にgRPC対応プロキシを使用している場合は、TCPまたはTLSプロキシ（OSIレイヤー4）を使用するようにプロキシ設定を変更する必要があります。

Gitaly Clusterは、GitLab 13.12でgRPC対応プロキシとの互換性がなくなりました。Gitalyクラスターを使用していない場合でも、すべてのGitLabインストールではgRPC対応プロキシとの互換性がなくなります。

一部の内部RPCトラフィックをカスタムプロトコル（gRPCではなく）で送信することで、スループットが向上し、Goガベージコレクションのレイテンシーが短縮されます。詳細については、関連するエピックを参照してください。

テストカバレッジプロジェクトのCI/CD設定

テストカバレッジパターンの設定を簡単にするために、GitLab 15.0では、テストカバレッジ解析用のプロジェクト設定が削除されます。

代わりに、プロジェクトの.gitlab-ci.ymlを使用して、coverageキーワードで正規表現を指定し、マージリクエストでテストカバレッジ結果を設定します。

GitLabのトレーシング

GitLabのトレーシングは、オープンソースのエンドツーエンド分散トレーシングシステムであるJaegerとのインテグレーションです。GitLabユーザーはJaegerインスタンスにアクセスして、デプロイされたアプリケーションのパフォーマンスに関するインサイトを得ることで、特定のリクエストを処理する各関数またはマイクロサービスを追跡できます。GitLabのトレーシングはGitLab 14.7で非推奨となり、15.0で削除される予定です。可能な代替手段に関する作業を追跡するには、OpstraceとGitLabのインテグレーションに関するイシューを参照してください。

コンテナレジストリグループレベルAPIの更新

マイルストーン15.0では、tagsおよびtags_countパラメータのサポートが、グループからレジストリリポジトリを取得するコンテナレジストリAPIから削除されます。

GET /groups/:id/registry/repositoriesエンドポイントは残りますが、タグに関する情報は返されません。タグに関する情報を取得するには、既存のGET /registry/repositories/:idエンドポイントを使用できます。このエンドポイントは、現在と同様にtagsおよびtag_countオプションを引き続きサポートします。後者は、イメージリポジトリごとに1回呼び出す必要があります。

バリューストリーム分析のフィルタリング計算の変更

バリューストリーム分析の日付フィルターの動作方法を変更します。日付フィルターは、イシューまたはマージリクエストが作成された時刻でフィルタリングする代わりに、指定されたステージの終了イベント時刻でフィルタリングします。これにより、この変更がロールアウトされた後では、数値が完全に異なるものになります。

バリューストリーム分析のメトリクスを監視したり、日付フィルターを利用したりしている場合は、この変更の前にデータを保存して、データが失われないようにする必要があります。

脆弱性チェック

脆弱性チェック機能はGitLab 14.8で非推奨となり、GitLab 15.0で削除される予定です。代わりに、新しいセキュリティ承認機能に移行することをおすすめします。移行するには、Security & Compliance（セキュリティとコンプライアンス） > ポリシーに移動して、新しいスキャン結果ポリシーを作成します。

新しいセキュリティ承認機能は、脆弱性チェックに似ています。たとえば、どちらもセキュリティの脆弱性を含むMRの承認を要求できます。ただし、セキュリティ承認機能は、以前のエクスペリエンスを次のような点で改善します:

• ユーザーは、誰がセキュリティ承認ルールを編集できるかを選択できます。そのため、独立したセキュリティまたはコンプライアンスチームは、ルールを管理して、開発プロジェクトのメンテナーがルールを変更できなくすることができます。
• 複数のルールを作成してチェーン化し、スキャナーの種類ごとに異なる重大度しきい値でフィルタリングできるようにすることができます。
• セキュリティ承認ルールに対する望ましい変更について、2段階の承認プロセスを適用できます。
• 単一の中央集中型ルールセットのメンテナンスを容易にするために、単一のセキュリティポリシーセットを複数の開発プロジェクトに適用できます。

基本のPackageTypeのVersions

パッケージレジストリGraphQL APIを作成する作業の一環として、パッケージグループは、基本のPackageType型のVersion型を非推奨にし、PackageDetailsTypeに移行しました。

マイルストーン15.0では、PackageTypeからVersionを完全に削除します。

apiFuzzingCiConfigurationCreate GraphQLミューテーション

APIファジング設定スニペットはクライアント側で生成されるようになり、APIリクエストは不要になりました。したがって、GitLabで使用されなくなったapiFuzzingCiConfigurationCreateミューテーションは非推奨になります。

artifacts:reports:coberturaキーワード

現在、GitLabのテストカバレッジの可視化では、Coberturaレポートのみがサポートされています。15.0以降、artifacts:reports:coberturaキーワードはartifacts:reports:coverage_reportに置き換えられます。Coberturaは15.0でサポートされる唯一のレポートファイルになりますが、これはGitLabが他のレポートタイプをサポートするための最初のステップです。

defaultMergeCommitMessageWithDescription GraphQL APIフィールド

GraphQL APIフィールドdefaultMergeCommitMessageWithDescriptionは非推奨となっていて、GitLab 15.0で削除されます。コミットメッセージテンプレートが設定されたプロジェクトの場合、テンプレートは無視されます。

dependency_proxy_for_private_groups機能フラグ

GitLab-#11582によって公開グループが依存プロキシを使用する方法が変更されたため、機能フラグを追加しました。この変更前は、認証なしで依存プロキシを使用できました。この変更により、依存プロキシを使用するには認証が必要になります。

マイルストーン15.0では、機能フラグを完全に削除します。今後は、依存プロキシを使用する際に認証する必要があります。

htpasswdコンテナレジストリの認証

コンテナレジストリは、htpasswdでの認証をサポートしています。これは、bcryptを使用してハッシュされたパスワードを含む、Apache htpasswdファイルに依存しています。

GitLab（製品）のコンテキストで使用されないため、htpasswd認証はGitLab 14.9で非推奨となり、GitLab 15.0で削除されます。

versionフィールドのpipelinesフィールド

GraphQLには、パッケージバージョンのパイプラインを取得するためにPackageDetailsTypeで使用できる2つのpipelinesフィールドがあります:

• versionsフィールドのpipelinesフィールド。これにより、パッケージのすべてのバージョンに関連付けられたすべてのパイプラインが返されます。そのため、メモリ内で無制限の数のオブジェクトがプルされ、パフォーマンス上の懸念が生じる可能性があります。
• 特定のversionのpipelinesフィールド。これにより、その単一のパッケージバージョンに関連付けられたパイプラインのみが返されます。

考えられるパフォーマンスの問題を軽減するために、マイルストーン15.0でversionsフィールドのpipelinesフィールドを削除します。パッケージのすべてのバージョンのすべてのパイプラインを取得できなくなりますが、そのバージョンの残りのpipelinesフィールドを使用して、単一のバージョンのパイプラインを取得できます。

PipelineSecurityReportFinding GraphQLのprojectFingerprint

PipelineSecurityReportFinding GraphQLオブジェクトのprojectFingerprintフィールドは非推奨になります。このフィールドには、一意性を判断するために使用されるセキュリティ検出結果の「フィンガープリント」が含まれています。フィンガープリントを計算する方法が変更され、異なる値が生成されています。今後は、新しい値がUUIDフィールドに公開されます。projectFingerprintフィールドで以前に利用可能だったデータは、最終的に完全に削除されます。

gitlab-ctlからのpromote-dbコマンド

GitLab 14.5で、フェイルオーバー時にGeoセカンダリノードをプライマリにプロモートするコマンドgitlab-ctl promoteを導入しました。このコマンドは、マルチノードGeoセカンダリサイトでデータベースノードをプロモートするために使用されるgitlab-ctl promote-dbを置き換えます。gitlab-ctl promote-dbは引き続きそのまま機能し、GitLab 15.0まで使用できます。Geoをご利用のお客様は、ステージング環境で新しいgitlab-ctl promoteコマンドのテストを開始し、フェイルオーバー手順に新しいコマンドを組み込むことをおすすめします。

gitlab-ctlからのpromote-to-primary-nodeコマンド

GitLab 14.5で、フェイルオーバー時にGeoセカンダリノードをプライマリにプロモートするコマンドgitlab-ctl promoteを導入しました。このコマンドは、シングルノードGeoサイトでのみ使用可能だったgitlab-ctl promote-to-primary-nodeを置き換えます。gitlab-ctl promote-to-primary-nodeは引き続きそのまま機能し、GitLab 15.0まで使用できます。Geoをご利用のお客様は、ステージング環境で新しいgitlab-ctl promoteコマンドのテストを開始し、フェイルオーバー手順に新しいコマンドを組み込むことをおすすめします。

CI/CD設定のtypeおよびtypesキーワード

GitLab 15.0では、typeおよびtypes CI/CDキーワードが削除されます。これらのキーワードを使用するパイプラインは動作を停止するため、同じ動作をするstageおよびstagesに切り替える必要があります。

bundler-audit依存関係スキャンツール

14.6の時点で、bundler-auditは依存関係スキャンで非推奨となっています。非推奨になっている間は、引き続きCI/CDテンプレートに存在します。15.0では、2022年5月22日にbundler-auditを依存関係スキャンから削除します。この削除後も、Rubyスキャン機能はGemnasiumによって引き続きカバーされているため、影響を受けません。

DS_EXCLUDED_ANALYZERSを使用してbundler-auditを明示的に除外した場合は、15.0でクリーンアップ（参照を削除）する必要があります。パイプラインの依存関係スキャンの設定（たとえば、bundler-audit-dependency_scanningジョブを編集するなど）をカスタマイズした場合は、15.0で削除される前にgemnasium-dependency_scanningに切り替えて、パイプラインが失敗しないようにする必要があります。DS_EXCLUDED_ANALYZERSを使用してbundler-auditを参照したり、特にbundler-audit用にテンプレートをカスタマイズしたりしていない場合は、対応する必要はありません。

Composer依存関係をダウンロードするための権限の変更

GitLab Composerリポジトリを使用して、PHP依存関係のプッシュ、検索、そのメタデータの取得、ダウンロードを行うことができます。これらのすべてのアクションには認証が必要ですが、依存関係のダウンロードは例外です。

認証なしでComposer依存関係をダウンロードすることはGitLab 14.9で非推奨となり、GitLab 15.0で削除されます。GitLab 15.0以降では、Composer依存関係をダウンロードするには認証が必要となります。

統合されたエラー追跡はデフォルトで無効

GitLab 14.4で、GitLabはSentryの代替となる統合されたエラー追跡バックエンドをリリースしました。この機能により、データベースのパフォーマンスの問題が発生しました。GitLab 14.9で、統合されたエラー追跡はGitLab.comから削除され、GitLab Self-Managedでデフォルトでオフになりました。GitLabがこの機能の今後の開発について探索している間は、プロジェクト設定でエラー追跡をSentryに変更して、Sentryバックエンドに切り替えることを検討してください。

この削除に関する追加の背景については、統合されたエラー追跡をデフォルトで無効化を参照してください。フィードバックがある場合は、フィードバック: 統合されたエラー追跡の削除にコメントを追加してください。

KubernetesとのGitLab.com証明書ベースのインテグレーション

Kubernetesとの証明書ベースのインテグレーションは非推奨となり、削除されます。GitLab 15.0以降、GitLab.comユーザーとして、新しいネームスペースで証明書ベースのアプローチを使用して、GitLabとクラスターを統合できなくなります。現在のユーザーのインテグレーションは、ネームスペースごとに有効になります。

Kubernetesとのより堅牢で安全かつ信頼性の高いインテグレーションを実現するには、Kubernetes用エージェントを使用して、KubernetesクラスターをGitLabに接続することをおすすめします。移行方法はこちらです。

この非推奨化に関する最新情報と詳細については、このエピックをご覧ください。

GitLab Self-Managedのお客様は、機能フラグを使用して、引き続き機能を使用できます。

パイプライン変数の使用に対するデフォルトのセキュリティの強化

GitLabは、セキュアバイデフォルトの実践を重視しています。これを尊重するために、いくつかの変更を行って、CI/CD変数の使用に関する最小権限の原則がサポートされるようにしています。現在、デベロッパーロール以上のユーザーは、検証やオプトインなしで、デフォルトでパイプライン変数を使用できます。

推奨される「オーナーのみ」、または「誰にも許可しない」に最小ロールを引き上げることで、パイプライン変数に対してデフォルトでより安全なエクスペリエンスを使用し始めることができます。17.7以降、no one allowedは、GitLab.comの新しいネームスペースの新規プロジェクトすべてでデフォルトになります。

OpenTofu CI/CDテンプレート

16.8でOpenTofu CI/CDテンプレートを導入したのは、CI/CDコンポーネントがGitLab Self-Managedでまだ利用できなかったためです。GitLab Self-ManagedのGitLab CI/CDコンポーネントの導入に伴い、CI/CDコンポーネントを優先して、冗長なOpenTofu CI/CDテンプレートを削除します。

CI/CDテンプレートからコンポーネントへの移行については、OpenTofuコンポーネントのドキュメントを参照してください。

一般的なユーザー、プロジェクト、グループAPIエンドポイントのレート制限

ユーザー 、プロジェクト 、グループの一般的に使用されるエンドポイントに対して、デフォルトでレート制限が有効になります。これらのレート制限をデフォルトで有効にして、APIの大量使用が広範なユーザーエクスペリエンスに悪影響を与える可能性を減らすことにより、システム全体の安定性を向上させることができます。レート制限を超えてリクエストを行った場合、HTTP 429エラーコードと追加のレート制限ヘッダーが返されます。

デフォルトのレート制限は、GitLab.comで確認できるリクエストレートに基づいて、意図的にかなり高く設定して、ほとんどの使用状況で混乱を引き起こさないようにしています。インスタンス管理者は、すでに設定されている他のレート制限と同様に、管理者エリアで必要に応じてより高い制限またはより低い制限を設定できます。

GraphQLからpreviousStageJobsOrNeedsを削除

previousStageJobsOrNeedsフィールドは、previousStageJobsフィールドとneedsフィールドに置き換えられたため、GraphQLから削除されます。

agentkコンテナレジストリをクラウドネイティブGitLabに移行

agentkコンテナレジストリをプロジェクト固有のレジストリからクラウドネイティブGitLab（CNG）レジストリに移動します。GitLab 18.0以降、CNGで構築されたagentkイメージは、プロジェクト固有のレジストリにミラーリングされます。新しいイメージは古いイメージと同等ですが、新しいイメージはamd64およびarm64アーキテクチャのみをサポートします。32ビットのarmアーキテクチャはサポートされていません。GitLab 19.0以降、プロジェクト固有のレジストリはagentkの更新を受信しません。agentkコンテナをローカルレジストリにミラーリングする場合は、ミラーのソースをCNGレジストリに変更する必要があります。

公式のGitLabエージェントHelmチャートを使用している場合、GitLab 18.0では新しいagentkイメージは新しい場所からシームレスにデプロイを開始します。

kptベースのagentkは非推奨

Kubernetesエージェントのkptベースのインストールに対するサポートを削除します。代わりに、サポートされているいずれかのインストール方法でエージェントをインストールする必要があります:

• Helm（推奨）
• GitLab CLI
• Flux

kptからHelmに移行するには、エージェントのインストールに関するドキュメントに従って、kptでデプロイされたagentkインスタンスを上書きしてください。

mergeTrainIndexおよびmergeTrainsCount GraphQLフィールドは非推奨

MergeRequestのGraphQLフィールドmergeTrainIndexとmergeTrainsCountは非推奨です。マージトレインでのマージリクエストの位置を判断するには、代わりにMergeTrainCarのindexフィールドを使用します。マージトレイン内のMRの数を取得するには、代わりにMergeTrains::TrainTypeのcarsからcountを使用します。

コンテナスキャンのデフォルトの重大度しきい値をmediumに設定

コンテナスキャンのセキュリティ機能は多くのセキュリティ検出結果を生成するため、エンジニアリングチームがその量を管理するのは困難なことが多いです。重大度しきい値をmediumに変更することで、medium未満の重大度を持つ検出が報告されない、より妥当なデフォルトの検出量をユーザーに提供します。GitLab 18.0以降、CS_SEVERITY_THRESHOLD環境変数のデフォルト値は、unknownではなくmediumに設定されます。その結果、重大度レベルがlowおよびunknownのセキュリティ検出結果は、デフォルトでは報告されなくなります。そのため、デフォルトブランチで以前は報告されていたこれらの重大度を持つ脆弱性は、コンテナスキャンの次回の実行時に、検出されなくなったものとしてマークされます。これらの検出を引き続き表示するには、CS_SEVERITY_THRESHOLD変数を目的のレベルに設定する必要があります。

ライセンススキャンCI/CDアーティファクトレポートタイプを非推奨化

CI/CDアーティファクトレポートタイプはGitLab 16.9で非推奨となり、GitLab 18.0で削除されます。このキーワードを使用するCI/CD設定は、GitLab 18.0では機能しなくなります。

GitLab 16.3で従来のライセンススキャンCI/CDジョブが削除されたため、アーティファクトレポートタイプは使用されなくなりました。代わりに、CycloneDXファイルのライセンススキャンを使用する必要があります。

サポートが終了したSASTジョブはCI/CDテンプレートから削除されます

GitLab 18.0では、SAST CI/CDテンプレートを更新して、以前のリリースでサポート終了になったアナライザージョブを削除します。次のジョブは、SAST.gitlab-ci.ymlおよびSAST.latest.gitlab-ci.ymlから削除されます:

• bandit-sast（15.4でサポート終了）
• brakeman-sast（17.0でサポート終了）
• eslint-sast（15.4でサポート終了）
• flawfinder-sast（17.0でサポート終了）
• gosec-sast（15.4でサポート終了）
• mobsf-android-sast（17.0でサポート終了）
• mobsf-ios-sast（17.0でサポート終了）
• nodejs-scan-sast（17.0でサポート終了）
• phpcs-security-audit-sast（17.0でサポート終了）
• security-code-scan-sast（16.0でサポート終了）

各アナライザーがサポート終了になった時点で、ジョブのrulesを更新してデフォルトで実行されないようにし、更新のリリースを停止しました。ただし、ユーザーは、テンプレートをカスタマイズして、これらのジョブを引き続き使用するか、パイプラインに存在するジョブに依存している可能性があります。上記のジョブに依存するカスタマイズがある場合は、CI/CDパイプラインの混乱を回避するために、18.0にアップグレードする前に必要なアクションを実行してください。

セキュアコンテナレジストリのパブリック使用は非推奨

GitLab 18.0では、registry.gitlab.com/gitlab-org/security-products/配下のコンテナレジストリにアクセスできなくなります。GitLab 14.8以降、正しい場所はregistry.gitlab.com/security-productsの下です（アドレスにgitlab-orgがないことに注意してください）。

この変更により、GitLab脆弱性スキャナーのリリースプロセスのセキュリティが向上します。

registry.gitlab.com/security-products/配下の同等のレジストリを使用することをおすすめします。これは、GitLabセキュリティスキャナーイメージの標準的な場所です。関連するGitLab CIテンプレートはすでにこの場所を使用しているため、変更されていないテンプレートを使用しているユーザーは変更する必要はありません。

オフラインでのデプロイでは、特定のスキャナーの指示を見直して、正しい場所が使用されていて、必要なスキャナーイメージがミラーされていることを確認する必要があります。

SASTジョブでグローバルキャッシュ設定の使用を停止

GitLab 18.0では、SASTおよびIaCスキャンを更新して、デフォルトでCI/CDジョブキャッシュの使用を明示的に無効にします。

この変更は、次のCI/CDテンプレートに影響します:

• SAST: SAST.gitlab-ci.yml。
• IaCスキャン: SAST-IaC.gitlab-ci.yml。

すでにlatestテンプレートSAST.latest.gitlab-ci.ymlとSAST-IaC.latest.gitlab-ci.ymlを更新しました。これらのテンプレートバージョンの詳細については、安定版と最新版のテンプレートを参照してください。

キャッシュディレクトリはほとんどのプロジェクトでスキャンの対象外であるため、キャッシュを取得するとタイムアウトまたは誤検知の結果が発生する可能性があります。

プロジェクトのスキャン時にキャッシュを使用する必要がある場合は、プロジェクトのCI設定でcacheプロパティをオーバーライドして、以前の動作を復元できます。