バージョンによる非推奨と削除

### Openstack SwiftとRackspace APIを使った自動バックアップアップロード {: #automatic-backup-upload-using-openstack-swift-and-rackspace-apis} Openstack SwiftとRackspace APIを使った[リモートストレージへのバックアップアップロードの](https://docs.gitlab.com/ee/raketasks/backup_gitlab.html#upload-backups-to-a-remote-cloud-storage)サポートを廃止します。これらのAPIのサポートはサードパーティのライブラリに依存しており、これらのライブラリはもはやアクティブにメンテナーされておらず、Ruby 3用にアップデートされていません。GitLabはセキュリティパッチを最新の状態に保つため、Ruby 2のサポート終了前にRuby 3に切り替えています。 - OpenStackを使用している場合は、Swiftの代わりにS3 APIを使用するように設定を変更する必要があります。 - Rackspace ストレージを使用している場合は、別のプロバイダに切り替えるか、バックアップタスクの完了後にバックアップファイルを手動でアップロードする必要があります。

### Web IDE でライブプレビューが利用できなくなりました。 {: #live-preview-no-longer-available-in-the-web-ide} Web IDEのライブプレビュー機能は、静的なWebアプリケーションのクライアントサイドプレビューを提供することを目的としていました。しかし、複雑な設定手順とサポートされているプロジェクト タイプの範囲が狭いため、その有用性は限られていました。GitLab 15.7 の Web IDE Beta の導入により、完全なサーバーサイド実行環境に接続できるようになりました。Web IDEにエクステンションをインストールするための今後のサポートにより、Live Previewで利用できるものよりも高度なワークフローもサポートする予定です。GitLab 15.9では、Web IDEでLive Previewは利用できなくなりました。

### SaaS証明書ベースのKubernetesインテグレーション {: #saas-certificate-based-integration-with-kubernetes} Kubernetesとの証明書ベースのインテグレーションは[非推奨となり、削除](https://about.gitlab.com/blog/2021/11/15/deprecating-the-cert-based-kubernetes-integration/)されます。GitLab SaaSの顧客として、新しいネームスペースでは、GitLab 15.0から証明書ベースのアプローチを使ってGitLabとクラスターをインテグレーションすることができなくなります。現在のユーザーのインテグレーションはネームスペースごとに有効になります。 Kubernetesとのより堅牢で、セキュリティが高く、近日中にリリースされ、信頼性の高いインテグレーションを実現するには、[Kubernetes用エージェントを](https://docs.gitlab.com/ee/user/clusters/agent/)使用してKubernetesクラスタとGitLabを接続することをお勧めします。[マイグレーションするには？](https://docs.gitlab.com/ee/user/infrastructure/clusters/migrate_to_gitlab_agent.html) 明確な削除日が設定されていますが、新しいソリューションが機能を同等にするまでこの機能を削除する予定はありません。削除の障害に関する詳細については、[このイシューを](https://gitlab.com/gitlab-org/configure/general/-/issues/199)ご覧ください。 この非推奨化に関する更新と詳細については、[このエピックに従って](https://gitlab.com/groups/gitlab-org/configure/-/epics/8)ください。 GitLabセルフマネージドユーザーの方は、[機能フラグを](https://docs.gitlab.com/ee/update/deprecations.html#self-managed-certificate-based-integration-with-kubernetes)つけることで引き続きこの機能を利用することができます。

### のファイルタイプ変数の展開`.gitlab-ci.yml` {: #file-type-variable-expansion-in-gitlab-ciyml} 以前は、ファイル変数のエイリアスを参照または適用する変数は、`File` 型変数の `File`値を拡張していました。`File` 例えば、ファイルの内容です。この動作は典型的な Shell 変数展開規則に準拠していないため、正しくありませんでした。 `File`型`File` 変数に格納されているシークレット情報や機密情報を漏らすために `File`、ユーザーは変数を入力パラメーターとして $echo コマンドを実行することができました。 今回の変更により、このイシューは修正されましたが、この動作を回避するユーザーのワークフローが中断される可能性があります。この変更により、エイリアスファイル変数を参照または適用するジョブ変数の展開は、ファイルの内容などの値の代わりに、`File` 型変数のファイル名またはパスに展開されます。

### SASTアナライザーの統合とCI/CDテンプレートの変更 {: #sast-analyzer-consolidation-and-cicd-template-changes} GitLab SASTは様々な[アナライザーを使って](https://docs.gitlab.com/ee/user/application_security/sast/analyzers/)コードの脆弱性をスキャンします。 より良い一貫したユーザー体験を提供するための長期的な戦略の一環として、GitLab SASTで使用するアナライザの数を減らしています。また、アナライザーのセットを合理化することで、より迅速な[反復](https://about.gitlab.com/handbook/values/#iteration)、より良い[結果](https://about.gitlab.com/handbook/values/#results)、より高い[効率性](https://about.gitlab.com/handbook/values/#efficiency)（ほとんどの場合CI Runnerの使用量の削減を含む）を実現します。 GitLab 15.4では、GitLab SASTは以下のアナライザーを使用しなくなります： - [ESLint](https://gitlab.com/gitlab-org/security-products/analyzers/eslint)(JavaScript, TypeScript, React) - [Gosec](https://gitlab.com/gitlab-org/security-products/analyzers/gosec)(Go) - [バンディット](https://gitlab.com/gitlab-org/security-products/analyzers/bandit)（Python） NOTE: この変更は当初 GitLab 15.0 で予定されていましたが、GitLab 15.4 に延期されました。 これらのアナライザは[GitLab が管理する SAST CI/CD テンプレートから](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml)削除され、[Semgrep ベースのアナライザに](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep)置き換えられます。即座に、これらのアナライザはセキュリティアップデートのみを受け取ることになり、その他の日常的な改善やアップデートは保証されません。これらのアナライザーがサポート終了に達した後、これ以上のアップデートは提供されません。これらのアナライザ用に以前に公開されたコンテナイメージを削除することはありません。そのような変更は、[非推奨、削除、またはブレークチェンジのアナウンスとして](https://about.gitlab.com/handbook/marketing/blog/release-posts/#deprecations-removals-and-breaking-changes)発表されます。 また、[SpotBugs](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs)アナライザの対象からJavaを削除し、[Semgrepベースのアナライザに](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep)置き換えます。この変更により、Javaコードのスキャンがよりシンプルになります。この変更は、[GitLabが管理するSAST CI/CD](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml)テンプレートの自動言語検出部分に反映されます。なお、SpotBugsベースのアナライザは引き続きGroovy、Kotlin、Scalaをカバーします。 非推奨のアナライザから脆弱性の発見をすでに却下している場合、代替アナライザは前回の却下を尊重しようとします。システムの動作は以下に依存します： - 過去に Semgrep ベースの解析ツールを実行しないようにしたかどうか。 - プロジェクトの脆弱性レポートに示されている脆弱性を、どのアナライザが最初に発見したか。 詳細は[脆弱性翻訳ドキュメントを](https://docs.gitlab.com/ee/user/application_security/sast/analyzers.html#vulnerability-translation)参照してください。 影響を受けるアナライザにカスタマイズを適用している場合、または現在パイプラインでSemgrepアナライザを無効にしている場合は、[この変更の非推奨イシューに](https://gitlab.com/gitlab-org/gitlab/-/issues/352554#breaking-change)記載されているアクションを実行する必要があります。

### リポジトリプッシュイベントの監査イベント {: #audit-events-for-repository-push-events} [リポジトリイベントの](https://docs.gitlab.com/ee/administration/audit_events.html#removed-events)監査イベントは非推奨となり、GitLab 15.0で削除されます。 これらのイベントはデフォルトでは常に無効になっており、機能フラグを使って手動で有効にする必要がありました。有効にすると、イベントが大量に発生し、GitLabインスタンスが劇的に遅くなる可能性があります。このため、削除されることになりました。

### オブジェクトストレージのバックグラウンドアップロード {: #background-upload-for-object-storage} GitLabの[オブジェクトストレージ](https://docs.gitlab.com/ee/administration/object_storage.html)機能の全体的な複雑さとメンテナンスの負担を減らすため、`background_upload` を使ってファイルをアップロードするサポートは非推奨となり、GitLab 15.0 で完全に削除されます。[オブジェクトストレージで削除されたバックグラウンドアップロードの](https://docs.gitlab.com/omnibus/update/gitlab_15_changes.html#removed-background-uploads-settings-for-object-storage)設定については、[15.0特有の変更](https://docs.gitlab.com/omnibus/update/gitlab_15_changes.html)点をレビューしてください。 これはオブジェクトストレージプロバイダーの一部に影響します： - **OpenStackを**使用している顧客は、Swiftの代わりにS3 APIを使用するように設定を変更する必要があります。 - **RackSpace**RackSpaceベースのオブジェクトストレージを使用しているお客様は、データを別のプロバイダーにマイグレーションする必要があります。 GitLabは、影響を受けるお客様のマイグレーションを支援するため、追加のガイダンスを公開する予定です。

### CI/CD ジョブ名の長さ制限 {: #cicd-job-name-length-limit} GitLab 15.0ではCI/CDジョブ名の文字数を255文字に制限する予定です。255文字の制限を超えるジョブ名を持つパイプラインは、15.0リリース後に動作しなくなります。

### インスタンス(共有)ランナーをプロジェクト(特定)ランナーに変更する場合 {: #changing-an-instance-shared-runner-to-a-project-specific-runner} GitLab 15.0では、インスタンス（共有）ランナーをプロジェクト（特定）ランナーに変更することができなくなりました。 ユーザーが誤ってインスタンスランナーをプロジェクトランナーに変更してしまい、元に戻せなくなってしまうことがよくあります。GitLab では、セキュリティの観点からプロジェクトランナーを共有ランナーに変更することはできません。あるプロジェクト用のランナーがインスタンス全体のジョブを実行するように設定されてしまう可能性があるからです。 複数のプロジェクトにランナーを追加する必要がある管理者は、一つのプロジェクトにランナーを登録し、管理者ビューで追加のプロジェクトを選択します。

### コンテナネットワークとホストのセキュリティ {: #container-network-and-host-security} GitLabのコンテナネットワークセキュリティとコンテナホストセキュリティカテゴリに関連するすべての機能は、GitLab 14.8で非推奨となり、GitLab 15.0で削除される予定です。この機能の代替が必要なユーザーは、GitLabの外にインストールして管理できるソリューションとして、以下のオープンソースプロジェクトを評価することをお勧めします：[AppArmor](https://gitlab.com/apparmor/apparmor)、[Cilium](https://github.com/cilium/cilium)、[Falco](https://github.com/falcosecurity/falco)、[FluentD](https://github.com/fluent/fluentd)、[ポッドセキュリティアドミッション](https://kubernetes.io/docs/concepts/security/pod-security-admission/)。これらのテクノロジーをGitLabにインテグレーションするには、必要なHelmチャートを[クラスター管理プロジェクトテンプレートの](https://docs.gitlab.com/ee/user/clusters/management_project_template.html)コピーに追加します。GitLab[CI/CDを通して](https://docs.gitlab.com/ee/user/clusters/agent/ci_cd_workflow.html)コマンドを呼び出し、これらのHelmチャートを本番環境にデプロイします。 この変更の一環として、GitLab内の以下の特定の機能は非推奨となり、GitLab 15.0で削除される予定です： - **セキュリティとコンプライアンス > 脅威モニタリング**ページ。 - セキュリティとコンプライアンス**] > [ポリシー]**ページの`Network Policy` セキュリティポリシータイプ。 - GitLabを通して以下のテクノロジーとのインテグレーションを管理する機能：AppArmor、Cilium、Falco、FluentD、ポッドセキュリティポリシー。 - 上記の機能に関連するすべてのAPI。 この変更に関する追加情報やフィードバックは、私たちのオープンな[非推奨のイシューを](https://gitlab.com/groups/gitlab-org/-/epics/7476)参照してください。

### Python 3.9と3.6イメージの非推奨依存性のスキャン {: #dependency-scanning-python-39-and-36-image-deprecation} Python プロジェクトの Dependency Scanning を使っている人のために、Python 3.6 を使うデフォルトの`gemnasium-python:2` イメージと Python 3.9 を使うカスタムの`gemnasium-python:2-python-3.9` イメージを廃止します。GitLab 15.0の新しいデフォルトイメージはPython 3.9になります。Python 3.9は[サポートされているバージョン](https://endoflife.date/python)であり、3.6は[サポートされて](https://endoflife.date/python)いません。 Python 3.9または3.9互換のプロジェクトを使用しているユーザーは、アクションを起こす必要はなく、依存関係スキャンはGitLab 15.0で機能し始めるはずです。今すぐ新しいコンテナをテストしたい場合は、このコンテナを使ってプロジェクトでテストパイプラインを実行してください（15.0 では削除されます）。Python 3.9 イメージを使ってください： ```yaml 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` アナライザーイメージを使うように切り替える必要があります。もしこの影響を受ける場合は、[このイシューに](https://gitlab.com/gitlab-org/gitlab/-/issues/351503)コメントしてください。 3.9の特別な例外イメージを使用しているユーザーは、代わりにデフォルト値を使用し、コンテナを上書きしないようにする必要があります。3.9の特別な例外イメージを使用しているかどうかを確認するには、`.gitlab-ci.yml` ファイルをチェックしてください： ```yaml gemnasium-python-dependency_scanning: image: name: registry.gitlab.com/gitlab-org/security-products/analyzers/gemnasium-python:2-python-3.9 ```

### 依存関係スキャンのデフォルトの Java バージョンが 17 に変更されました。 {: #dependency-scanning-default-java-version-changed-to-17} GitLab 15.0では、依存関係スキャンのために、スキャナが期待するJavaのデフォルトのバージョンが11から17に更新されます。Java 17は[最新のLong Term Support(LTS) バージョン](https://en.wikipedia.org/wiki/Java_version_history)です。依存関係スキャンでは、引き続き同じ[範囲のバージョン（8、11、13、14、15、16、17](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#supported-languages-and-package-managers)）がサポートされますが、デフォルトのバージョンだけが変更されます。プロジェクトで以前のデフォルトであるJava 11を使用している場合は、[`DS_Java_Version` 変数を一致するように設定して](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#configuring-specific-analyzers-used-by-dependency-scanning)ください。

### 機能フラグPUSH_RULES_SUPERSEDE_CODE_OWNERSの廃止 {: #deprecate-feature-flag-pushrulessupersedecodeowners} 機能フラグ`PUSH_RULES_SUPERSEDE_CODE_OWNERS` は GitLab 15.0 で削除されます。このフラグが削除されると、プッシュルールがコードオーナーに優先します。コードオーナーの承認が必要な場合でも、特定のユーザーに明示的にコードのプッシュを許可するプッシュルールは、コードオーナーの設定に優先します。

### Elasticsearch 6.8 {: #elasticsearch-68} 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でサポートを予定して](https://gitlab.com/gitlab-org/gitlab/-/issues/327560)いるAmazon OpenSearchとも互換性がありません。

### 外部ステータスチェックAPIの変更 {: #external-status-check-api-breaking-changes} [外部ステータスチェックAPIは](https://docs.gitlab.com/ee/api/status_checks.html)元々、ステータスチェックを通過とマークするpass-by-defaultリクエストをサポートするために実装されました。Pass-by-default リクエストは非推奨となりました。具体的には、以下は非推奨です： - `status` フィールドを含まないリクエスト。 - `status` フィールドが`approved` に設定されているリクエスト。 GitLab 15.0 以降では、`status` フィールドが存在し、かつ`passed` に設定されている場合にのみ、ステータスチェックは通過状態に更新されます。リクエスト - `status` フィールドが含まれていないリクエストは`422` エラーで拒否されます。詳細は[関連イシューを](https://gitlab.com/gitlab-org/gitlab/-/issues/338827)参照してください。 - `passed` 以外の値をコンテナに含めると、ステータス・チェックに失敗します。詳細は関連[するイシューを](https://gitlab.com/gitlab-org/gitlab/-/issues/339039)参照してください。 この変更に合わせて、外部ステータス・チェックの一覧を表示する API 呼び出しも、合格したステータス・チェックに対して`approved` ではなく`passed` の値を返します。

### GitLab サーバーレス {: #gitlab-serverless} GitLab ServerlessはKnativeベースのサーバーレス開発を自動デプロイとモニタリングでサポートする機能セットです。 私たちはGitLab Serverlessの機能がユーザーの心に響かなかったため、削除することにしました。その上、KubernetesとKnativeの継続的な開発を考えると、私たちの現在の実装は最近のバージョンでさえ動作しません。

### GraphQL IDとGlobalIDの互換性 {: #graphql-id-and-globalid-compatibility} 後方互換性のために追加した GraphQL プロセッサーの非標準拡張機能を削除します。この拡張機能は、GraphQL クエリの検証を変更し、`ID` 通常は拒否される引数の型の `ID`使用を許可します。`ID` 一部の引数はもともと .NET 型 `ID`でした。これらは、特定の種類の`ID` に変更されました。 この変更は、以下のような場合、変更になる可能性があります： - GraphQL を使用している場合。 - クエリシグネチャの引数には`ID` 型を使用します。 いくつかのフィールド引数はまだ`ID` 型を持っています。これらは一般的にIID値や名前空間パスのためのものです。例えば、`Query.project(fullPath: ID!)` です。 影響を受けるフィールド引数と受けないフィールド引数の一覧は、[非推奨の](https://gitlab.com/gitlab-org/gitlab/-/issues/352832)イシューを参照してください。 この変更が影響するかどうかは、GitLabサーバーから取得したスキーマデータを使ってクエリをローカルで検証することで試すことができます。これを行うには、関連するGitLabインスタンスのGraphQLエクスプローラツールを使用します。例：`https://gitlab.com/-/graphql-explorer`. 例えば、以下のクエリはこの変更を示しています： ```graphql # 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 } } ``` 上記のクエリは GitLab 15.0 がリリースされた後は動作しません。`Query.issue(id:)` の型が実際には`IssueID!` になっているからです。 代わりに、次の二つの形式のどちらかを使う必要があります： ```graphql # 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` を使う）のクエリは、他の二つの形式（シグネチャで適切な型を使うか、インライン引数式を使う）のいずれかに変換してください。

### パッケージ設定のGraphQL権限変更 {: #graphql-permissions-change-for-package-settings} GitLabパッケージステージでは、パッケージレジストリ、コンテナレジストリ、依存プロキシを提供し、GitLabを使用したすべての依存関係の管理を支援します。これらの製品カテゴリのそれぞれには、APIを使って調整できる様々な設定があります。 GraphQL の権限モデルが更新されます。15.0 以降、ゲスト、レポーター、開発者ロールのユーザーはこれらの設定を更新できなくなりました： - [パッケージ レジストリ設定](https://docs.gitlab.com/ee/api/graphql/reference/#packagesettings) - [コンテナ レジストリのクリーンアップ ポリシー](https://docs.gitlab.com/ee/api/graphql/reference/#containerexpirationpolicy) - [依存プロキシの有効期限ポリシー](https://docs.gitlab.com/ee/api/graphql/reference/#dependencyproxyimagettlgrouppolicy) - [グループでの依存プロキシの有効化](https://docs.gitlab.com/ee/api/graphql/reference/#dependencyproxysetting)

### GitLab Runner SSH Executor に必要な既知のホスト {: #known-host-required-for-gitlab-runner-ssh-executor} [GitLab 14.3では](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/3074)、GitLab Runner`config.toml` ファイルに設定を追加しました。この設定[`[runners.ssh.disable_strict_host_key_checking]`](https://docs.gitlab.com/runner/executors/ssh.html#security)、SSH Executorで厳密なホスト鍵チェックを使うかどうかを制御します。 GitLab 15.0以降では、この設定オプションのデフォルト値が`true` から`false` に変更されます。これは、GitLab Runner SSH Executorを使用する際に厳密なホスト鍵チェックが強制されることを意味します。

### License Compliance API からのレガシー承認者ステータス名 {: #legacy-approval-status-names-from-license-compliance-api} `managed_licenses` API において、ライセンスポリシーの承認状況（blacklisted, approved）を表すレガシーな名前を非推奨としましたが、API のクエリやレスポンスではまだ使われています。これらは15.0で削除される予定です。 当社の License Compliance API を使用している場合、`approved` と`blacklisted` クエリパラメータの使用を停止する必要があります。`allowed` と`denied`になります。15.0 では、レスポンスでも`approved` と`blacklisted` の使用を停止するため、15.0 リリースで壊れないように、新旧の値を使用するようにカスタムツールを調整する必要があります。

### レガシーデータベースの設定 {: #legacy-database-configuration} `database.yml` にある[GitLab データベース](https://docs.gitlab.com/omnibus/settings/database.html)設定の構文が変更され、従来の形式は廃止されました。レガシーフォーマットでは単一の PostgreSQL アダプタをサポートしていましたが、新しいフォーマットでは複数のデータベースをサポートするようになります。`main:` データベースを最初の設定項目として定義する必要があります。 Omnibusはこの設定を自動的に処理するので、この非推奨化は主にGitLabをソースからコンパイルするユーザーに影響を与えます。

### GitLabでのログ記録 {: #logging-in-gitlab} GitLabのロギング機能により、ユーザーはELKスタック（Elasticsearch、Logstash、Kibana）をインストールして、アプリケーションのログを集約・管理することができます。ユーザーはGitLabで関連するログを検索することができます。しかし、KubernetesクラスターやGitLab Managed Appsとの証明書ベースのインテグレーションを非推奨としているため、GitLab内でのログの推奨ソリューションはありません。詳しくは、[OpstraceとGitLabのインテグレーションに関する](https://gitlab.com/groups/gitlab-org/-/epics/6976)イシューをご覧ください。

### OAuth 暗黙のグラント {: #oauth-implicit-grant} OAuth implicit grantの作成者フローは、次のメジャーリリースであるGitLab 15.0で削除されます。OAuth implicit grantを使用しているアプリケーションは、[サポートされている](https://docs.gitlab.com/ee/api/oauth2.html)別の[OAuthフローに切り替えて](https://docs.gitlab.com/ee/api/oauth2.html)ください。

### 有効期限のないOAuthトークン {: #oauth-tokens-without-expiration} デフォルトでは、すべての新しいアプリケーションのアクセストークンは2時間後に失効します。GitLab 14.2以前では、OAuthアクセストークンには有効期限がありませんでした。GitLab 15.0では、既存のトークンでまだ有効期限がないものは、自動的に有効期限が生成されます。 GitLab 15.0がリリースされる前に、トークンの有効期限を[設定](https://docs.gitlab.com/ee/integration/oauth_provider.html#access-token-expiration)する必要があります： 1. アプリケーションを編集します。 1. **アクセストークンを**有効にするには、[**アクセストークンを失効させる**] を選択します。トークンは失効させないと有効期限が切れません。

### OmniAuth Kerberos gem {: #omniauth-kerberos-gem} `omniauth-kerberos` gemは次のメジャーリリースであるGitLab 15.0で削除される予定です。 このgemはメンテナーされておらず、ほとんど使われていません。そのため、この認証方法のサポートを削除し、代わりにKerberos[SPNEGO](https://en.wikipedia.org/wiki/SPNEGO)インテグレーションを使うことを推奨する予定です。[アップグレード](https://docs.gitlab.com/ee/integration/kerberos.html#upgrading-from-password-based-to-ticket-based-kerberos-sign-ins)手順に従って、`omniauth-kerberos` のインテグレーションからサポートされるものにアップグレードすることができます。 私たちは Kerberos SPNEGO インテグレーションを廃止するのではなく、古いパスワードベースの Kerberos インテグレーションのみを廃止することに注意してください。

### PAT期限切れのオプション実施 {: #optional-enforcement-of-pat-expiration} PATの期限切れを無効にする機能は、セキュリティの観点からは珍しいものです。私たちは、この異常な機能がユーザーに予期しない振る舞いを引き起こす可能性があることを懸念しています。セキュリティ機能における予期せぬ動作は本質的に危険ですので、この機能を削除することにしました。

### SSHの有効期限切れのオプション設定 {: #optional-enforcement-of-ssh-expiration} SSHの期限切れを無効にする機能は、セキュリティの観点からは異例です。私たちは、この普通でない機能がユーザーにとって予期しない動作を引き起こすことを懸念しています。セキュリティ機能における予期せぬ動作は本質的に危険なので、私たちはこの機能を削除することにしました。

### Java 8のSASTのアウトオブボックス・サポート {: #out-of-the-box-sast-support-for-java-8} [GitLab SAST SpotBugs アナライザは](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs)、[Java、Scala、Groovy、Kotlin のコードの](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks)セキュリティ脆弱性をスキャンします。技術的な理由から、アナライザはスキャンする前にまずコードをコンパイルしなければなりません。[プリコンパイル戦略を](https://docs.gitlab.com/ee/user/application_security/sast/#pre-compilation)使わない限り、アナライザはプロジェクトのコードを自動的にコンパイルしようとします。 GitLabの15.0より前のバージョンでは、アナライザーイメージにはコンパイルを容易にするためにJava 8とJava 11のランタイムが含まれています。 GitLab 15.0では、以下のようになります： - アナライザー・イメージからJava 8を削除し、イメージのサイズを縮小します。 - Java 17でのコンパイルを容易にするため、アナライザー・イメージにJava 17を追加します。 アナライザ環境にJava 8が存在することに依存している場合は、[この変更に関する非推奨イシューに](https://gitlab.com/gitlab-org/gitlab/-/issues/352549#breaking-change)記載されているアクションを実行する必要があります。

### 高度な検索マイグレーションの古いインデックス {: #outdated-indices-of-advanced-search-migrations} アドバンストサーチのマイグレーションでは、通常、長期間にわたって複数のコードパスをサポートする必要があるため、安全にできるときにそれらをクリーンアップすることが重要です。GitLab のメジャーバージョンアップグレードは、完全にマイグレーションされていないインデックスの下位互換性を削除する安全なタイミングです。詳しくは[アップグレードドキュメントを](https://docs.gitlab.com/ee/update/index.html#upgrading-to-a-new-major-version)ご覧ください。

### `instanceStatisticsMeasurements` GraphQL ノードによる利用傾向のクエリ {: #querying-usage-trends-via-the-instancestatisticsmeasurements-graphql-node} `instanceStatisticsMeasurements` GraphQLノードは13.10で`usageTrendsMeasurements` に名前が変更され、古いフィールド名は非推奨としてマークされました。既存のGraphQLクエリを修正するには、`instanceStatisticsMeasurements` を`usageTrendsMeasurements`に置き換えてください。

### リクエストのプロファイリング {: #request-profiling} [リクエストプロファイリングは](https://docs.gitlab.com/ee/administration/monitoring/performance/index.html)GitLab 14.8で非推奨となり、GitLab 15.0で削除される予定です。 私たちは[プロファイリングツールを統合](https://gitlab.com/groups/gitlab-org/-/epics/7327)し、より簡単にアクセスできるように取り組んでいます。この機能の利用を[評価した](https://gitlab.com/gitlab-org/gitlab/-/issues/350152)ところ、あまり利用されていないことがわかりました。また、いくつかのサードパーティのgemに依存しており、それらはもうアクティブにメンテナーされていなかったり、Rubyの最新バージョンにアップデートされていなかったり、重いページロードをプロファイリングすると頻繁にクラッシュしたりします。 詳細については、[非推奨化イシューの概要セクションを](https://gitlab.com/gitlab-org/gitlab/-/issues/352488#deprecation-summary)確認してください。

### Premium階層で必要なパイプライン設定 {: #required-pipeline-configurations-in-premium-tier} [必須パイプライン設定](https://docs.gitlab.com/ee/administration/settings/continuous_integration.html#required-pipeline-configuration)機能はGitLab 14.8でPremiumのお客様には非推奨となり、GitLab 15.0で削除される予定です。この機能はGitLab Ultimateのお客様には廃止されません。 この機能をGitLabのUltimate階層に移動させる今回の変更は、この機能に対する需要が主にエグゼクティブに由来するものであることを考慮し、私たちの機能を私たちの[価格哲学により](https://about.gitlab.com/company/pricing/#three-tiers)合致させることを意図したものです。 この変更はまた、GitLabが他の関連するUltimate階層の機能との一貫した階層化戦略を維持するためにも役立ちます：[セキュリティポリシーと](https://docs.gitlab.com/ee/user/application_security/policies/) [コンプライアンスフレームワークのパイプライン](https://docs.gitlab.com/ee/user/project/settings/index.html#compliance-pipeline-configuration)。

### Retire-JS依存性スキャンツール {: #retire-js-dependency-scanning-tool} 14.8で、retire.jsジョブは依存性スキャンから廃止されました。非推奨となっても CI/CD テンプレートには含まれ続けます。2022年5月22日にGitLab 15.0で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サポート {: #sast-support-for-net-21} GitLab SAST Security Code Scan アナライザーは .NET コードのセキュリティ脆弱性をスキャンします。技術的な理由から、アナライザはまずコードをスキャンするためにビルドする必要があります。 GitLabの15.0より前のバージョンでは、デフォルトのアナライザーイメージ（バージョン2）は以下をサポートしています： - .NET 2.1 - .NET 3.0と.NET Core 3.0 - .NET Core 3.1 - .NET 5.0 GitLab 15.0では、このアナライザーのデフォルトのメジャーバージョンをバージョン2からバージョン3に変更します。この変更は - [他の新機能や改善とともに](https://gitlab.com/gitlab-org/security-products/analyzers/security-code-scan/-/blob/master/CHANGELOG.md)、[脆弱性の深刻度の](https://gitlab.com/gitlab-org/gitlab/-/issues/350408)値を追加します。 - .NET 2.1のサポートを削除しました。 - .NET 6.0、Visual Studio 2019、Visual Studio 2022のサポートを追加しました。 バージョン3は[GitLab 14.6で発表さ](https://about.gitlab.com/releases/2021/12/22/gitlab-14-6-released/#sast-support-for-net-6)れ、オプションのアップグレードとして利用可能になりました。 デフォルトでアナライザーイメージに.NET 2.1サポートが存在することに依存している場合、[この変更に関するdeprecation issueの](https://gitlab.com/gitlab-org/gitlab/-/issues/352553#breaking-change)詳細に従ってアクションを取る必要があります。

### Secure and Protect アナライザーイメージを新しい場所に公開しました。 {: #secure-and-protect-analyzer-images-published-in-new-location} GitLabは[セキュリティの脆弱性をスキャン](https://docs.gitlab.com/ee/user/application_security/)するために様々な[アナライザーを](https://docs.gitlab.com/ee/user/application_security/terminology/#analyzer)使います。それぞれのアナライザーはコンテナイメージとしてディストリビューションされています。 GitLab 14.8から、GitLab SecureとProtectアナライザの新しいバージョンは、`registry.gitlab.com/security-products` の新しいレジストリに公開されます。 この変更に合わせて、[GitLab が管理する CI/CD テンプレートの](https://gitlab.com/gitlab-org/gitlab/-/tree/master/lib/gitlab/ci/templates/Security)デフォルト値を更新します： - コンテナスキャンを除くすべてのアナライザで、変数`SECURE_ANALYZERS_PREFIX` を新しいイメージレジストリの場所に更新します。 - コンテナスキャンでは、デフォルトのイメージアドレスはすでに更新されています。コンテナスキャンには、`SECURE_ANALYZERS_PREFIX` 変数はありません。 将来のリリースでは、`registry.gitlab.com/gitlab-org/security-products/analyzers` へのイメージの公開を停止する予定です。この場合、手動でイメージを取得し、別のレジストリにプッシュする場合は、アクションを実行する必要があります。これは[オフラインデプロイの](https://docs.gitlab.com/ee/user/application_security/offline_deployments/index.html)場合によくあることです。そうしないと、今後のアップデートを受け取ることができなくなります。 詳細は[非推奨のイシュー](https://gitlab.com/gitlab-org/gitlab/-/issues/352564)を参照してください。

### セキュア＆プロテクト・アナライザー・メジャーバージョンアップデート {: #secure-and-protect-analyzer-major-version-update} SecureステージとProtectステージは、GitLab 15.0のリリースに合わせてアナライザーのメジャーバージョンをバンプする予定です。このメジャーバンプによって、アナライザーの明確な区別が可能になります： - 2022年5月22日以前にリリースされ、厳格なスキーマ検証の対象と_ならない_レポーターを生成するもの。 - 2022年5月22日以降にリリースされたもので、厳格なスキーマ検証の対象と_なる_レポーターを生成するもの。 デフォルトのインクルードテンプレートを使用していない場合、またはアナライザーのバージョンをピン留めしている場合は、CI/CDジョブ定義を更新してピン留めしたバージョンを削除するか、最新のメジャーバージョンを更新する必要があります。GitLab 12.0-14.10のユーザーは、GitLab 15.0のリリースまで通常通りアナライザーのアップデートを体験することができます。その後、新しいメジャーバージョンのアナライザーで新しく修正されたバグや新しくリリースされた機能は、非推奨バージョンでは利用できません。必要なセキュリティパッチは、最新の3つのマイナーリリース内でバックポートされます。具体的には、以下が非推奨となり、15.0 GitLabリリース以降は更新されません： - APIセキュリティ: バージョン1 - コンテナスキャン：バージョン4 - カバレッジガイドファズテスト: バージョン 2 - 依存関係のスキャン：バージョン2 - 動的アプリケーションセキュリティテスト(DAST): version 2 - Infrastructure as Code (IaC) スキャニング：バージョン 1 - ライセンススキャン：バージョン3 - シークレット検出: バージョン 3 - 静的アプリケーションセキュリティテスト(SAST): 現在バージョン3の`gosec` を除く、[すべてのアナライザの](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks)バージョン2。 - `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-metrics-and-health-checks-configuration} 単一のプロセスとポートを使用したSidekiqメトリクスとヘルスチェックのエクスポートは非推奨です。サポートは15.0で削除されます。 安定性と可用性を向上させ、エッジケースでのデータ損失を防ぐために、[2つの別々のプロセスからメトリクスとヘルスチェックを](https://gitlab.com/groups/gitlab-org/-/epics/6409)エクスポートするようにSidekiqを更新しました。これらは2つの別個のサーバーであるため、15.0では、メトリクスとヘルスチェックのための別個のポートを明示的に設定するための設定変更が必要になります。新しく導入された`sidekiq['health_checks_*']` の設定は、常に`gitlab.rb` で設定する必要があります。詳細については、[Sidekiqを設定する](https://docs.gitlab.com/ee/administration/sidekiq/index.html)ためのドキュメントを確認してください。 これらの変更はまた、Prometheusが新しいエンドポイントをスクレイピングするか、k8s health-checksが新しいhealth-checkポートをターゲットにして正しく動作するように更新する必要があります。 非推奨期間中、これらの設定はオプションであり、GitLabはSidekiq health-checksポートを`sidekiq_exporter` と同じポートにデフォルト設定し、1つのサーバーのみを実行します（現在の動作は変更しません）。両方が設定され、異なるポートが提供された場合のみ、Sidekiq 15.0でのSidekiqの動作と同様に、Sidekiqメトリクスを提供するために別のメトリクスサーバーが立ち上がります。

### SLES 12 SP2のサポート {: #support-for-sles-12-sp2} SUSE Linux Enterprise Server(SLES) 12 SP2 の長期サービスおよびサポート(LTSS) は[2021 年 3 月 31 日に終了](https://www.suse.com/lifecycle/)しました。SP2のCA証明書には期限切れのDSTルート証明書が含まれているため、新しいCA証明書パッケージの更新が行われません。いくつかの[回避策を](https://gitlab.com/gitlab-org/gitlab-omnibus-builder/-/merge_requests/191)実施しましたが、ビルドを正常に実行し続けることはできません。

### Gitalyと残りのGitLabの間にデプロイされたgRPC対応プロキシをサポートしました。 {: #support-for-grpc-aware-proxy-deployed-between-gitaly-and-rest-of-gitlab} 推奨されていませんし、文書化もされていませんが、GitalyとGitLabの他の部分との間にgRPC対応のプロキシをデプロイすることは可能でした。例えば、NGINXやEnvoyなどです。gRPC対応プロキシのデプロイは[非推奨](https://gitlab.com/gitlab-org/gitlab/-/issues/352517)です。現在Gitaly接続にgRPC対応プロキシを使用している場合は、代わりにTCPまたはTLSプロキシ（OSIレイヤ4）を使用するようにプロキシの設定を変更する必要があります。 Gitaly ClusterはGitLab 13.12でgRPC対応プロキシと互換性がなくなりました。Gitaly Clusterがなくても、すべてのGitLabインストールはgRPC対応プロキシと非互換になります。 内部 RPC トラフィックの一部を (gRPC ではなく) カスタム・プロトコルで送信することにより、スループットを向上させ、Go ガベージ・コレクションの待ち時間を短縮します。詳細については、[関連するエピックを](https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/463)参照してください。

### テストカバレッジプロジェクトの CI/CD 設定 {: #test-coverage-project-cicd-setting} テストカバレッジパターンの設定を簡単にするため、GitLab 15.0では[テストカバレッジ解析のプロジェクト](https://docs.gitlab.com/ee/ci/pipelines/settings.html#add-test-coverage-results-using-project-settings-removed)設定が削除されます。 その代わりに、プロジェクトの`.gitlab-ci.yml` を使って、`coverage` キーワードで正規表現を指定することで、マージリクエストでテストカバレッジの結果を設定することができます。

### GitLab でのトレース {: #tracing-in-gitlab} GitLabのトレースは、オープンソースのエンドツーエンドの分散トレースシステムであるJaegerとのインテグレーションです。GitLabユーザーはデプロイされたアプリケーションのパフォーマンスをインサイトするためにJaegerインスタンスに移動し、与えられたリクエストを処理する各関数やマイクロサービスを追跡することができます。GitLabのトレースはGitLab 14.7で非推奨となり、15.0で削除される予定です。代替となる可能性のある作業を追跡するには、[OpstraceとGitLabのインテグレーション](https://gitlab.com/groups/gitlab-org/-/epics/6976)に関するイシューをご覧ください。

### コンテナレジストリグループレベルAPIの更新 {: #update-to-the-container-registry-group-level-api} マイルストーン 15.0 では、[グループからレジストリリポジトリを取得](../api/container_registry.md#within-a-group)するコンテナレジストリ API から`tags` と`tags_count` パラメータのサポートが削除されます。 `GET /groups/:id/registry/repositories` エンドポイントは残りますが、タグに関する情報は返されません。タグに関する情報を取得するには、既存の`GET /registry/repositories/:id` エンドポイントを使用します。 エンドポイントは、現在と同様に`tags` と`tag_count` オプションをサポートしています。後者は画像リポジトリごとに一度だけ呼び出す必要があります。

### バリューストリームアナリティクスのフィルタリング計算の変更 {: #value-stream-analytics-filtering-calculation-change} Value Stream Analyticsの日付フィルターの動作を変更します。イシューまたはマージリクエストが作成された時間でフィルタリングする代わりに、日付フィルタは指定されたステージの終了イベント時間でフィルタリングします。この変更により、ロールアウト後の数値はまったく異なるものになります。 Value Stream Analyticsメトリクスを監視し、日付フィルタに依存している場合は、データの損失を避けるために、この変更の前にデータを保存する必要があります。

### 脆弱性チェック {: #vulnerability-check} 脆弱性チェック機能はGitLab 14.8で非推奨となり、GitLab 15.0で削除される予定です。代わりに新しいセキュリティ承認者機能にマイグレーションすることをお勧めします。**セキュリティとコンプライアンス > ポリシーに**移動し、新しいスキャン結果ポリシーを作成することで移行できます。 新しいセキュリティ承認機能は、脆弱性チェックと似ています。例えば、どちらもセキュリティ脆弱性を含む MR に対して承認者を要求できます。しかし、セキュリティ承認者は、いくつかの点で、以前のエクスペリエンスを改善します： - ユーザーは、セキュリティ承認ルールの編集を許可する人を選択できます。そのため、独立したセキュリティまたはコンプライアンスチームは、開発プロジェクトのメンテナーがルールを変更できないように、ルールを管理することができます。 - 複数のルールを作成して連結し、スキャナの種類ごとに異なる重大度のしきい値でフィルタリングすることができます。 - セキュリティ承認ルールの変更には、2段階の承認プロセスを実施できます。 - 単一のセキュリティポリシーセットを複数の開発プロジェクトに適用し、一元化されたルールセットを容易にメンテナーすることができます。

### `Versions` ベース`PackageType` {: #versions-on-base-packagetype} [Package Registry GraphQL APIを](https://gitlab.com/groups/gitlab-org/-/epics/6318)作成する作業の一環として、Packageグループは基本`PackageType` 型の`Version` 型を非推奨とし、[`PackageDetailsType`](https://docs.gitlab.com/ee/api/graphql/reference/index.html#packagedetailstype)型に移動しました。 マイルストーン15.0では、`PackageType` から`Version` を完全に削除します。

### `artifacts:reports:cobertura` キーワード {: #artifactsreportscobertura-keyword} 現在、GitLabのテストカバレッジの可視化はCoberturaレポートのみをサポートしています。15.0 から、`artifacts:reports:cobertura` キーワードは[`artifacts:reports:coverage_report`](https://gitlab.com/gitlab-org/gitlab/-/issues/344533) に置き換えられます。Coberturaは15.0でサポートされる唯一のレポートファイルですが、これはGitLabが他のレポートタイプをサポートするための第一歩です。

### `defaultMergeCommitMessageWithDescription` GraphQL API フィールド {: #defaultmergecommitmessagewithdescription-graphql-api-field} GraphQL API フィールド`defaultMergeCommitMessageWithDescription` は非推奨となり、GitLab 15.0 で削除されます。コミットメッセージテンプレートが設定されているプロジェクトでは、テンプレートを無視します。

### `dependency_proxy_for_private_groups` 機能フラグ {: #dependencyproxyforprivategroups-feature-flag} [GitLab-#11582](https://gitlab.com/gitlab-org/gitlab/-/issues/11582)で公開グループが依存プロキシを使う方法が変更されたため、機能フラグを追加しました。この変更前は、認証なしで依存プロキシを使うことができました。この変更により、依存プロキシを利用するには認証が必要になりました。 マイルストーン 15.0 では、機能フラグを完全に削除します。今後、依存プロキシを使用する場合は認証が必要です。

### `pipelines` フィールドを`version` フィールドから削除します。 {: #pipelines-field-from-the-version-field} GraphQL では、[`PackageDetailsType`](https://docs.gitlab.com/ee/api/graphql/reference/#packagedetailstype) でパッケージバージョンのパイプラインを取得するために使える`pipelines` フィールドが2つあります： - `versions` フィールドの`pipelines` フィールドです。これは、すべてのパッケージのバージョンに関連するすべてのパイプラインを返しますが、メモリ内のオブジェクト数が無制限に引き出され、パフォーマンスに懸念が生じる可能性があります。 - 特定の`version` の`pipelines` フィールド。これは、その単一のパッケージバージョンに関連するパイプラインのみを返します。 考えられるパフォーマンス問題を軽減するため、`pipelines` マイルストーン 15.0 では `pipelines` `versions` フィールドの`pipelines` フィールドを `pipelines`削除します。`pipelines` パッケージの全バージョンのパイプラインを取得することはできなくなりますが、残りの `pipelines`フィールド`pipelines` から単一バージョンのパイプラインを取得 `pipelines`することはできます。

### `projectFingerprint` in`PipelineSecurityReportFinding` GraphQL {: #projectfingerprint-in-pipelinesecurityreportfinding-graphql} [PipelineSecurityReportFinding](https://docs.gitlab.com/ee/api/graphql/reference/index.html#pipelinesecurityreportfinding)GraphQL オブジェクトの`projectFingerprint` フィールドは非推奨となります。このフィールドには、一意性を判断するために使用されるセキュリティ発見の「フィンガープリント」がコンテナされています。フィンガープリントの計算方法が変更されたため、異なる値が得られました。今後、新しい値は UUID フィールドで公開されます。以前 projectFingerprint フィールドで利用可能であったデータは、最終的に完全に削除されます。

### `promote-db` コマンド`gitlab-ctl` {: #promote-db-command-from-gitlab-ctl} GitLab 14.5では、`gitlab-ctl promote` フェイルオーバー中に任意のGeoセカンダリノードをプライマリに昇格 `gitlab-ctl promote`させるコマンドを導入しました。`gitlab-ctl promote` このコマンドは、`gitlab-ctl promote-db` マルチノードのGeoセカンダリノードサイトでデータベースノードを昇格 `gitlab-ctl promote-db`させるために使われるコマンドを置き換えるもので、GitLab 15.0までそのまま機能し、利用可能です。Geo のお客様には `gitlab-ctl promote`、ステージング環境で`gitlab-ctl promote` 新しい `gitlab-ctl promote`コマンドの`gitlab-ctl promote` テストを開始 `gitlab-ctl promote`し、フェイルオーバー手順に新しいコマンドを組み込むことを`gitlab-ctl promote` お勧めします `gitlab-ctl promote`。

### `promote-to-primary-node` コマンド`gitlab-ctl` {: #promote-to-primary-node-command-from-gitlab-ctl} GitLab 14.5では、`gitlab-ctl promote` フェイルオーバー中に任意のGeoセカンダリノードをプライマリに昇格 `gitlab-ctl promote`させるコマンドを導入しました。`gitlab-ctl promote` このコマンドは`gitlab-ctl promote-to-primary-node` シングルノードのGeoサイトでのみ使用可能 `gitlab-ctl promote-to-primary-node`でしたが、GitLab 15.0までそのまま機能し、使用可能です。Geo のお客様には、 `gitlab-ctl promote`ステージング環境で`gitlab-ctl promote` 新しい `gitlab-ctl promote`コマンドの`gitlab-ctl promote` テストを開始 `gitlab-ctl promote`し、フェイルオーバー手順に新しいコマンドを組み込むことを`gitlab-ctl promote` お勧めします `gitlab-ctl promote`。

### `type` と`types` キーワードを CI/CD 設定に追加しました。 {: #type-and-types-keyword-in-cicd-configuration} `type` と`types` CI/CD キーワードは GitLab 15.0 で削除されます。これらのキーワードを使用したパイプラインは動作しなくなるため、同じ動作をする`stage` と`stages`に切り替える必要があります。

### apiFuzzingCiConfigurationCreate GraphQL ミューテーション {: #apifuzzingciconfigurationcreate-graphql-mutation} API Fuzzingの設定スニペットはクライアントサイドで生成されるようになり、APIリクエストを必要としなくなりました。そのため、GitLabではもう使われていない`apiFuzzingCiConfigurationCreate` 変異を非推奨とします。

### bundler-audit 依存関係スキャンツール {: #bundler-audit-dependency-scanning-tool} 14.6でbundler-auditは依存性スキャンから廃止されました。非推奨となっても CI/CD テンプレートには引き続き含まれます。2022年5月22日の 15.0 で、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専用にテンプレートをカスタマイズしていない場合は、アクションを起こす必要はありません。

### コンテナレジストリの htpasswd 認証 {: #htpasswd-authentication-for-the-container-registry} コンテナレジストリでは、`htpasswd` を使った[認証を](https://gitlab.com/gitlab-org/container-registry/-/blob/master/docs/configuration.md#auth)サポートしています。[Apache`htpasswd` ファイル](https://httpd.apache.org/docs/2.4/programs/htpasswd.html)に依存し、パスワードは`bcrypt`を使ってハッシュ化されます。 GitLab（製品）の文脈では使われていないので、`htpasswd` 認証はGitLab 14.9で非推奨となり、GitLab 15.0で削除される予定です。

### user_email_lookup_limit API フィールド {: #useremaillookuplimit-api-field} この`user_email_lookup_limit` [APIフィールドは](https://docs.gitlab.com/ee/api/settings.html)非推奨となり、GitLab 15.0で `user_email_lookup_limit`削除されます。`user_email_lookup_limit` GitLab 15.0までは `user_email_lookup_limit`、`search_rate_limit` にエイリアスされ、既存のワークフローは引き続き動作します。 `user_email_lookup_limit` のレート制限を変更しようとするAPIコールは、代わりに`search_rate_limit` を使用してください。

### Composer の依存関係をダウンロードする権限の変更 {: #permissions-change-for-downloading-composer-dependencies} GitLab Composer リポジトリでは、PHP の依存関係のプッシュ、検索、メタデータの取得、ダウンロードを行うことができます。これらのアクションには、依存関係のダウンロードを除き、すべて認証が必要です。 認証なしで Composer の依存関係をダウンロードすることは GitLab 14.9 で非推奨となり、GitLab 15.0 で削除される予定です。GitLab 15.0からは、Composerの依存関係をダウンロードするには認証が必要です。