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

GitLab 18アップグレードノート

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

このページでは、GitLab 18のマイナーバージョンとパッチバージョンのアップグレード情報を提供します。以下の条件を考慮して、各手順を確認してください:

  • お使いのインストールタイプ。
  • 現在のバージョンから移行先バージョンまでのすべてのバージョン。

Helmチャートのインストールの詳細については、Helmチャート9.0のアップグレードノートを参照してください。

必須アップグレードストップ

インスタンス管理者に予測可能なアップグレードスケジュールを提供するために、必須アップグレードストップは、以下のバージョンで発生します:

  • 18.2
  • 18.5
  • 18.8
  • 18.11

アップグレードノートの参照

以下は、GitLabのマイナーバージョンごとのアップグレードノートの参照リストです。各リスト項目は、詳細情報が記載されている特定のセクションを指します。

インストール方法を示す項目（(Geo)や(Linux package)など）は、その方法にのみ適用されます。その他のすべての項目は、すべてのインストール方法に適用されます。

18.11へのアップグレード

GitLab 18.11にアップグレードする前に、以下を確認してください:

18.10へのアップグレード

GitLab 18.10へのアップグレード前に、以下を確認してください:

18.9へのアップグレード

GitLab 18.9へのアップグレード前に、以下を確認してください:

18.8へのアップグレード

GitLab 18.8へのアップグレード前に、以下を確認してください:

18.7へのアップグレード

GitLab 18.7へのアップグレード前に、以下を確認してください:

18.6へのアップグレード

GitLab 18.6へのアップグレード前に、以下を確認してください:

18.5へのアップグレード

GitLab 18.5へのアップグレード前に、以下を確認してください:

18.4へのアップグレード

GitLab 18.4へのアップグレード前に、以下を確認してください:

18.3へのアップグレード

GitLab 18.3へのアップグレード前に、以下を確認してください:

18.2へのアップグレード

GitLab 18.2へのアップグレード前に、以下を確認してください:

18.1へのアップグレード

GitLab 18.1へのアップグレード前に、以下を確認してください:

18.0へのアップグレード

GitLab 18.0へのアップグレード前に、以下を確認してください:

アップグレードノート

GitLab 18の特定のアップグレードノート。

パイプライン実行ポリシーでのdotenv変数はvariables_overrideを尊重する

  • プラン: Ultimate
  • 影響: パイプライン実行ポリシー
  • 影響を受けるバージョン:
    リリース影響を受けるパッチリリース
    18.1018.10.0以降

GitLab 18.10以降では、dotenv変数アーティファクト (artifacts:reports:dotenv) からの変数は、パイプライン実行ポリシーの他の変数と同じvariables_overrideルールに従います（デフォルトで安全）。以前は、dotenv変数がvariables_overrideの制限をバイパスでき、ポリシーのセキュリティ制御を損ねていました。

もしパイプラインが、ポリシーで定義された変数を上書きするためにdotenv変数に依存していた場合、variables_override.allowed: falseが設定されていると、その動作は機能しなくなります。以前の動作を復元するには、新しいdotenvオプションをallow_overrideに設定します:

variables_override:
  allowed: false
  exceptions: []
  dotenv: allow_override

詳細については、パイプライン実行ポリシーおよびマージリクエスト214991を参照してください。

Geo blob同期の失敗: ファイルストレージでのlog_error NoMethodError

  • プラン: Premium、Ultimate
  • 影響: Geo (ファイルストレージのみ)
  • 影響を受けるバージョン:
    リリース影響を受けるパッチリリース修正パッチレベル
    18.1118.11.0 - 18.11.218.11.3
    18.1018.10.0 - 18.10.518.10.6
    18.0 - 18.9すべてのパッチリリース未修正

Geoセカンダリサイトで、blobをオブジェクトストレージではなくfile storageに保存している場合、blobのレプリケーション（パイプラインアーティファクト、LFSオブジェクト、アップロード、ジョブのアーティファクトなど）が誤解を招くエラーで失敗する可能性があります:

Error while attempting to sync: undefined method `log_error' for an instance of Gitlab::Geo::Replication::BlobDownloader

詳細については、イシュー598565を参照してください。

Geoコンテナリポジトリの同期がOCIイメージのインデックスタグをサイレントスキップする

  • プラン: Premium、Ultimate
  • 影響: Geo (コンテナレジストリ)
  • 影響を受けるバージョン:
    リリース影響を受けるパッチリリース修正パッチレベル
    18.1118.11.0 - 18.11.418.11.5
    18.1018.10.0 - 18.10.718.10.8
    18.0 - 18.9すべてのパッチリリース未修正

Geoセカンダリサイトでは、マニフェストがOCIイメージのインデックス (application/vnd.oci.image.index.v1+json) であるタグが、コンテナリポジトリの同期によってサイレントにスキップされていました。マルチアーキテクチャイメージやBuildKitキャッシュタグは、一般的にこのマニフェストタイプを使用します。エラーは発生せず、タグのカウントは一致しましたが、セカンダリからの影響を受けるタグのdocker pullはmanifest unknownを返しました。同じ根本原因により、同期できなかった孤立したタグがセカンダリに残されました。

プライマリおよびセカンダリのサイトの両方を修正済みのバージョンにアップグレードすると、新しく同期されたタグは正しくなります。以前に影響を受けたリポジトリは、次回の検証サイクルで収束します。これには、再検証間隔（デフォルトで90日）までかかる場合があります。影響を受けたリポジトリをすぐに修復するには、セカンダリサイト上のコンテナリポジトリを再同期してください。

詳細については、イシュー600486を参照してください。

内部および公開プロジェクトからコンテナイメージをプルする際のCIジョブトークンのリグレッション

  • 影響: すべてのインストール方法
  • 影響を受けるバージョン:
    リリース影響を受けるパッチリリース修正パッチレベル
    18.1118.11.0 - 18.11.118.11.2

CIジョブがCI_JOB_TOKENを使用して内部または公開プロジェクトからコンテナイメージをプルする場合、GitLab 18.11.0または18.11.1にアップグレードしないでください。

GitLab 18.11.0のリグレッションにより、CIジョブがCI_JOB_TOKENを使用して内部または公開プロジェクトからコンテナイメージをプルするのを妨げます。影響を受けたパイプラインはdenied: requested access to the resource is deniedで失敗します。この修正は18-11-stable-eeにバックポートされましたが、18.11.1タグがカットされた後に含まれたため、18.11.0と18.11.1の両方が影響を受けます。

すでにアップグレード済みのオペレーター向けの利用可能な回避策:

  1. 各消費プロジェクトをソースプロジェクトのCIジョブトークン許可リストに追加します。CI/CDジョブトークンのセキュリティを参照してください。
  2. CI_JOB_TOKENの代わりに、個人、グループ、またはプロジェクトアクセストークンを使用してコンテナのプルを認証します。
  3. バックポートコミットe3c0f308をGitLabインスタンスに適用します。

詳細については、イシュー597223を参照してください。

SLES 12.5 RPMパッケージのインストール失敗

  • 影響: Linuxパッケージ
  • 影響を受けるバージョン:
    リリース影響を受けるパッチリリースインストール可能なパッチレベル
    18.1018.10.0 - 18.10.318.10.4 - 18.10.5
    18.918.9.1 - 18.9.518.9.0, 18.9.6

SLES 12.5では、GitLab 18.9.0、18.10.4、および18.11.2のみが正常にインストールできます。影響を受ける範囲の他のすべてのパッチリリースはインストールに失敗します。

SLES 12.5向けのGitLab Linuxパッケージは、rpmまたはzypperコマンドを使用するとerror: install failedエラーでインストールに失敗します。根本原因は、SLES 12 SP5に付属しているバージョンであるRPM 4.11.2における16 MiBのRPMヘッダーデータサイズ制限 (HEADER_DATA_MAX) です。GitLabパッケージ内のファイル数が増加したため、シリアル化されたRPMヘッダーがこの制限を超え、RPMデータベーストランザクションがインストール中にサイレントに失敗しました。

このイシューは、Linuxパッケージのファイル数を減らすことで、特定のパッチリリースで解決されました（マージリクエスト9215を参照）。しかし、ファイル数が増加すると、その後のパッチリリースでリグレッションが発生する可能性があります。SLES 12.5にGitLabをインストールするには、上記のインストール可能なパッチレベルのみを使用してください。

SUSEディストリビューションは、GitLab 18.9で非推奨となり、GitLab 19.0で削除される予定です。サポートされているオペレーティングシステムへの移行を検討してください。

詳細については、イシュー9647を参照してください。

MattermostおよびSpamcheckがSLES 12.5パッケージから削除される

  • 影響: Linuxパッケージ
  • 影響を受けるバージョン: 18.11.0以降

RPMパッケージサイズの制約により、MattermostとSpamcheckはSLES 12.5 Linuxパッケージから削除されました。

SUSEディストリビューションは、GitLab 18.9で非推奨となり、GitLab 19.0で削除される予定であり、MattermostとSpamcheckの両方は、GitLab 19.0ですべてのディストリビューションから削除される予定です。

SLES 12.5でMattermostを使用している場合は、Mattermostをスタンドアロンデプロイに移行できます。SLES 12.5でSpamcheckを使用している場合は、Dockerを使用してデプロイできます。

Geoセカンダリでスロットルされたジョブがドレインされない

  • プラン: Premium、Ultimate
  • 影響: Geo
  • 影響を受けるバージョン:
    リリース影響を受けるパッチリリース修正パッチレベル
    18.1018.10.0 - 18.10.318.10.4
    18.918.9.0 - 18.9.518.9.6

GeoセカンダリサイトではConcurrencyLimit::ResumeWorkerが無効になっていたため、スロットルされたGeo::EventWorkerおよびGeo::SyncWorkerのジョブがRedisに蓄積され、ドレインされませんでした。これにより、Geoのレプリケーションが停止し、Redisのメモリ使用量が増加する可能性があります。

詳細については、イシュー595824を参照してください。

送信フィルタリング使用時にGeoサイトURLがブロックされる

  • プラン: Premium、Ultimate
  • 影響: Geo
  • 影響を受けるバージョン:
    リリース影響を受けるパッチリリース修正パッチレベル
    18.1018.10.0 - 18.10.318.10.4
    18.918.9.0 - 18.9.518.9.6

送信リクエストフィルタリングが有効になっている場合、GeoサイトのURLが誤ってブロックされます。これにより、Geoサイトの保存時にUrl is blocked: Requests to hosts and IP addresses not on the Allow List are deniedのようなメッセージとともに検証エラーが発生します。

このイシューは、送信フィルタリングが設定されている場合、GeoサイトのURLが送信ローカルリクエスト許可リストに自動的に追加されないために発生します。

詳細については、イシュー544821を参照してください。

Geo blobダウンロードタイムアウト設定

  • プラン: Premium、Ultimate
  • 影響: Geo
  • 影響を受けるバージョン: 18.10.0

現在の8時間（28,800秒）ハードコードされたGeo blobダウンロードタイムアウトは、転送時間が長くかかる非常に大きなLFSオブジェクト（5GB以上）の失敗を引き起こし、「started」状態のままになります。新しいblob_download_timeout設定は、blobレプリケーション（LFSオブジェクト、アップロード、ジョブアーティファクトなど）のサイトごとのタイムアウト（秒単位）を制御します。GeoサイトAPIを通じて設定可能です。

  • デフォルト: 28800（8時間）。
  • 最大: 86400（24時間）。

Geo blobダウンロードの失敗

  • プラン: Premium、Ultimate
  • 影響: Geo
  • 影響を受けるバージョン:
    リリース影響を受けるパッチリリース修正パッチレベル
    18.1018.10.0 - 18.10.418.10.5

すべてのGeo blobタイプ（アップロード、LFSオブジェクト、ジョブのアーティファクトなど）は、セカンダリでの同期に永続的に失敗する可能性があります。一時的なネットワークエラーとは異なり、これらの失敗はすべてのblobレコードに影響を与え、再試行しても回復しません。影響を受けたセカンダリは「失敗」ステータスのblobを表示し、Sidekiqログにはセグメンテーション違反、HPE_USER Span callback error in on_header_fieldエラー、または予期しないHTTPステータスコード（たとえば、status_code: 32またはstatus_code: 34）が含まれる可能性があります。

根本原因は、rugged 1.9.0（GitLab 18.10でアップグレード）とllhttp-ffi gem間のシンボル衝突です。rugged.so内の静的にリンクされたllhttpシンボルがllhttp-ffiコールバックを上書きし、HTTPレスポンスの解析を破損させます。詳細については、イシュー598564を参照してください。

GitLab 18.10.5では、ruggedは1.7.2にダウングレードされ、競合するシンボルは含まれていません。アップグレード後に必要なアクションはありません。

GitLab 18.10.4向けの機能フラグ回避策

GitLab 18.10.4を使用しており、GitLab 18.10.5にアップグレードできない場合は、geo_blob_download_with_gitlab_http機能フラグを有効にしてください。この機能フラグは、blobダウンロードをFFIに依存するhttp gemの代わりにGitlab::HTTP (Net::HTTP) を使用するように切り替えます:

  1. 機能フラグを有効にします:

    sudo gitlab-rails console
Feature.enable(:geo_blob_download_with_gitlab_http)
exit

  2. Sidekiqを再起動します:

    sudo gitlab-ctl restart sidekiq

この機能フラグ回避策には既知の制限があります:

  • 60秒を超える大きなblob転送はタイムアウトする可能性があります（イシュー598020）。
  • コンテナレジストリのレプリケーションはこの機能フラグの対象外です。
  • 環境によっては、送信リクエストフィルタリング (deny_all_requests_except_allowed) に追加の設定が必要になる場合があります（イシュー598514）。

詳細については、イシュー595139を参照してください。

PostgreSQL CheckViolationにより18.9へのアップグレードが失敗する

  • 影響: すべてのインストール方法
  • 影響を受けるバージョン: 18.9.0、18.9.1

Self-ManagedインスタンスをGitLab 18.9.0または18.9.1にアップグレードすると、データベース移行中にアップグレードが失敗します:

PG::CheckViolation: ERROR: check constraint "check_xxxxxxxx" of relation "tablename" is violated by some row

このイシューは、GitLab 18.10で修正されたバグによって引き起こされました（マージリクエスト224446を参照）。この修正はバックポートされており、次のGitLab 18.9のパッチリリースに含まれるはずです（マージリクエスト225026を参照）。

しかし、このバグは、単一レコードのバグのために、バッチバックグラウンド移行がサイレントにスキップされる原因となる可能性があります。v18.8へのアップグレード時に、単一レコードのテーブルを対象とするバッチバックグラウンド移行が、一度も実行されることなく誤ってfinishedとマークされました。これによりデータがバックフィルされず、Self-Managedインスタンスでのアップグレードの失敗を引き起こしました。

提案されている修正（マージリクエスト225461を参照）は、影響を受けたバッチバックグラウンド移行をfinished/finalizedからpausedにリセットし、スケジューラがそれらを再実行するようにします。これは、18.5から18.8の間でqueued_migration_versionを持つ移行にスコープされ、min_value = max_valueまたはmin_cursor = max_cursorの場合に適用されます。

次の2つの方法があります。

  • 今すぐ回避策を適用して、すぐにアップグレードを完了してください。
  • 完全な修正がリリースに含まれてからアップグレードするまで待ってください。

以下のKnowledge Base記事では、5つの既知の症状に対する回避策について説明しています:

デプロイキーおよびブロックされたユーザーのパーソナルアクセストークンが無効化されました

  • 影響: すべてのインストール方法
  • 影響を受けるバージョン:
    リリース影響を受けるパッチレベル修正パッチレベル
    18.818.8.2以降該当なし（意図的な変更）
    18.718.7.2以降該当なし（意図的な変更）
    18.618.6.4以降該当なし（意図的な変更）

GitLab 18.8.2、18.7.2、および18.6.4では、ブロックされたユーザーに関連付けられたデプロイキーを使用するAPIリクエストが拒否されるようになりました。ブロックされたユーザーに関連付けられたデプロイキーがある場合、上記のバージョンにアップグレードした以降は機能しなくなります。これは、ブロックされたユーザーがキーとトークンを介してGitLabリソースにアクセスするのを防ぐためのセキュリティ修正です。

これを行うには、次の手順に従います。

  1. ブロックされたユーザーが所有するデプロイキーまたはPATを特定します。
  2. それらを請求対象ユーザーに再割り当てするか、削除して、請求対象ユーザーまたはサービスアカウントを使用して新しいキー/トークンを作成します。

以下のクエリは、ブロックされたアカウントに関連付けられており、過去365日間に少なくとも一度使用されたすべてのデプロイキーを特定するために使用できます:

SELECT
  k.id,
  k.user_id,
  u.username,
  u.state as user_state,
  k.title,
  k.fingerprint,
  k.fingerprint_sha256,
  k.usage_type,
  k.last_used_at,
  k.created_at,
  k.updated_at
FROM keys k
INNER JOIN users u ON k.user_id = u.id
WHERE u.state IN ('blocked', 'ldap_blocked', 'blocked_pending_approval', 'banned')
  AND k.type = 'DeployKey'
  AND k.last_used_at >= NOW() - INTERVAL '365 days'
ORDER BY u.state, u.username, k.last_used_at DESC;

ClickHouse辞書作成エラー

  • 影響: すべてのインストール方法
  • 影響を受けるバージョン: 18.8.0

Self-Managedインスタンスのお客様でClickHouseインテグレーションが有効になっている場合、権限の不足（DB::Exception: gitlab: Not enough privileges）により、アップグレードプロセス中にClickHouseデータベースの移行エラーが発生する可能性があります。このエラーを解決するには、データベースディクショナリの読み取りサポートのドキュメントを参照してください。

CIデータに対するバッチバックグラウンド移行の再導入

  • 影響: すべてのインストール方法
  • 影響を受けるバージョン: 18.8.0

batched background移行がCIビルドmetadata移行に導入されましたが、データ構造のエッジケースを処理し、それらが完了することを保証するために再導入する必要がありました。

引用符なしのプレースホルダーを含むカスタムWebhookテンプレートを保存できない

  • 影響: すべてのインストール方法
  • 影響を受けるバージョン:
    リリース影響を受けるパッチリリース修正パッチレベル
    18.10すべてのパッチリリース未修正
    18.9すべてのパッチリリース未修正
    18.8すべてのパッチリリース未修正

GitLab 18.8から18.10では、引用符なしのペイロードフィールドを含むカスタムWebhookテンプレートを保存できません。このイシューはGitLab 18.11で解決されました。

回避策として、フィールドを引用符で囲んでください。たとえば、{"value": {{id}}}は{"value": "{{id}}"}になります。

引用符で囲まれたフィールドは、数値ではなく文字列値を生成します。これがあなたのWebhookと互換性がない場合、GitLab 18.11以降にアップグレードしてください。

詳細については、Webhookトラブルシューティングドキュメントを参照してください。

CIビルドメタデータ移行

  • 影響: すべてのインストール方法
  • 影響を受けるバージョン: 18.7.0

A post deployment移行は、CIビルドメタデータを新しい最適化されたテーブル（p_ci_job_definitions）にコピーするために、バッチ化されたbackground移行をスケジュールします。この移行は、最終的にCIデータベースサイズを削減するためのイニシアチブの一部です（エピック13886を参照）。数百万のジョブを持つインスタンスがあり、移行を高速化したい場合は、select what data is migratedを実行できます。

Geo ActionCableの許可されたorigin設定

  • プラン: Premium、Ultimate
  • 影響: Geo
  • 影響を受けるバージョン: 18.7.0

ActionCableウェブソケットリクエストの許可されたoriginを設定するための新しいaction_cable_allowed_origins設定が追加されました。適切なクロスサイトWebSocket接続を確保するために、プライマリサイトを設定する際に許可されるURLを指定します:

Geo VerificationStateBackfillWorkerの遅いクエリの修正

  • プラン: Premium、Ultimate
  • 影響: Geo
  • 影響を受けるバージョン: 18.6.5

Geoのイシュー587407を修正しました。このイシューでは、Geo::VerificationStateBackfillWorkerがmerge_request_diff_detailsテーブルに対して大量の遅いクエリを生成していました。

コミットとファイルAPIのサイズとレート制限

  • 影響: すべてのインストール方法
  • 影響を受けるバージョン:
    リリース影響を受けるパッチレベル修正パッチレベル
    18.618.6.2以降該当なし（意図的な変更）
    18.518.5.4以降該当なし（意図的な変更）
    18.418.4.6以降該当なし（意図的な変更）

GitLab 18.6.2、18.5.4、および18.4.6では、以下のエンドポイントへのリクエストに対してサイズおよびレート制限が導入されました:

GitLabは、サイズ制限を超えるリクエストには413 Entity Too largeステータスで応答し、レート制限を超えるリクエストには429 Too Many Requestsステータスで応答します。詳細については、コミットとファイルAPIのAPI制限を参照してください。

GitLab Duo Agent Platform Runnerの制限

  • 影響: すべてのインストール方法
  • 影響を受けるバージョン: 18.6.2

runner restrictionsが導入され、GitLab Duo Agent Platformで使用できるRunnerに関連する制限が設けられました。

Geoログカーソル移行の修正

  • プラン: Premium、Ultimate
  • 影響: Geo
  • 影響を受けるバージョン:
    リリース影響を受けるパッチリリース修正パッチレベル
    18.518.5.0 - 18.5.118.5.2
    18.418.4.0 - 18.4.318.4.4

Geoログカーソルがセカンダリサイトで起動するのを防ぐ、不足しているGeo移行が修正されました。

設計管理デザインバックフィルの完了

  • 影響: すべてのインストール方法
  • 影響を受けるバージョン: 18.5.0

20250922202128_finalize_correct_design_management_designs_backfillは、18.4でスケジュールされたバッチバックグラウンド移行を完了させるデプロイ後の移行です。アップグレードパスで18.4をスキップした場合、この移行はデプロイ後の移行時に完全に実行されます。実行時間は、design_management_designsテーブルのサイズに直接関係します。ほとんどのインスタンスでは移行に2分以上かかることはありませんが、一部の大規模なインスタンスでは、最大で10分ほどかかる場合があります。移行プロセスを中断せず、そのままお待ちください。

NGINXルーティングの変更により404エラーが発生する

  • 影響: Linuxパッケージ
  • 影響を受けるバージョン: 18.5.0

GitLab 18.5.0で導入されたNGINXルーティングの変更により、localhostのような一致しないホスト名や代替ドメイン名を使用すると、サービスにアクセスできなくなる可能性があります。このイシューにより、以下が発生します:

  • /-/healthのようなヘルスチェックエンドポイントが、適切な応答ではなく404エラーを返す。
  • 設定されたFQDN以外のホスト名でアクセスした場合に、GitLabウェブインターフェースに404エラーページが表示される。
  • GitLab Pagesが、他のサービス向けのトラフィックを受信する可能性。
  • 以前は機能していた代替ホスト名を使用するリクエストに関する問題。

このイシューは、マージリクエスト8805によりLinuxパッケージで解決されており、修正はGitLab 18.5.2および18.6.0で利用可能になります。

クローン、プッシュ、プルなどのGit操作は、このイシューの影響を受けません。

バッチバックグラウンド移行nilエラー

  • 影響: すべてのインストール方法
  • 影響を受けるバージョン: 18.4.2、18.4.3

18.4.2または18.4.3へのアップグレードは、これらのバッチバックグラウンド移行でno implicit conversion of nil into Stringエラーにより失敗する可能性があります:

  • FixIncompleteInstanceExternalAuditDestinations
  • FinalizeAuditEventDestinationMigrations

このイシューを解決するには、最新のパッチリリースにアップグレードするか、workaround inイシュー578938を使用してください。

GeoレプリケーションのTypeError

  • プラン: Premium、Ultimate
  • 影響: Geo
  • 影響を受けるバージョン:
    リリース影響を受けるパッチリリース修正パッチレベル
    18.418.4.0 - 18.4.118.4.2

Geoセカンダリサイトで、バグにより、no implicit conversion of String into Array (TypeError)というエラーメッセージが表示され、レプリケーションイベントが失敗します。再検証などの冗長性機能によって最終的な整合性は確保されますが、目標リカバリー時点が大幅に長くなります。

サービス拒否防止のためのJSON入力制限

  • 影響: すべてのインストール方法
  • 影響を受けるバージョン:
    リリース影響を受けるパッチレベル修正パッチレベル
    18.418.4.1以降該当なし（意図的な変更）
    18.318.3.3以降該当なし（意図的な変更）
    18.218.2.7以降該当なし（意図的な変更）

GitLab 18.4.1、18.3.3、18.2.7では、サービス拒否攻撃を防ぐためにJSON入力に対する制限が導入されました。GitLabは、これらの制限を超えるHTTPリクエストに対して400 Bad Requestステータスで応答します。詳細については、HTTPリクエスト制限を参照してください。

LdapAddOnSeatSyncWorkerがDuoシートを削除する

  • 影響: すべてのインストール方法
  • 影響を受けるバージョン: 18.3.0

新しいワーカーLdapAddOnSeatSyncWorkerが導入されました。これにより、LDAPが有効になっている場合、毎晩、GitLab Duoシートからすべてのユーザーが誤って削除される可能性がありました。この問題はGitLab 18.4.0および18.3.2で修正されました。詳細については、イシュー565064を参照してください。

Geo Rakeチェックの修正

  • プラン: Premium、Ultimate
  • 影響: Geo
  • 影響を受けるバージョン: 18.3.0

Geoセカンダリサイトをインストールするに際に、rake gitlab:geo:checkが誤って失敗を報告する原因となっていたイシューが18.3.0で修正されました。

Geo GitLab Pagesファイル名修正

  • プラン: Premium、Ultimate
  • 影響: Geo
  • 影響を受けるバージョン:
    リリース影響を受けるパッチレベル修正パッチレベル
    18.318.3.0 - 18.3.218.3.3
    18.218.2.0 - 18.2.618.2.7
    18.118.1.0以降18.1では修正されず

GitLab 18.3.3および18.2.7以降には、イシュー559196の修正が含まれており、ファイル名が長いPagesデプロイでGeo検証が失敗する可能性がありました。この修正により、Geoセカンダリサイトでのファイル名のトリミングが防止され、レプリケーションおよび検証時の一貫性が維持されます。

18.1と18.2間のゼロダウンタイムアップグレード時のプッシュエラー

  • 影響: すべてのインストール方法
  • 影響を受けるバージョン: 18.2.0

18.1.xから18.2.xへのアップグレードでは、既知のイシュー567543の影響により、アップグレード中に既存プロジェクトへのコードのプッシュでエラーが発生します。バージョン18.1.xから18.2.xへのアップグレード中にダウンタイムを発生させないようにするには、修正を含むバージョン18.2.6に直接アップグレードします。

Geo VerificationStateBackfillService ci_job_artifact_states

  • プラン: Premium、Ultimate
  • 影響: Geo
  • 影響を受けるバージョン:
    リリース影響を受けるパッチレベル修正パッチレベル
    18.218.2.0 - 18.2.118.2.2
    18.118.1.0 - 18.1.318.1.4
    18.018.0.0 - 18.0.518.0.6

影響を受けるバージョンには、ci_job_artifact_statesの主キーの変更によりVerificationStateBackfillServiceが実行されるときに発生する既知のイシューがあります。解決するには、修正されたパッチレベルのリリースにアップグレードしてください。

Elasticsearch strict_dynamic_mapping_exception

  • 影響: すべてのインストール方法
  • 影響を受けるバージョン: 18.1.0

Elasticsearchバージョン7では、Elasticsearchのインデックス作成時にstrict_dynamic_mapping_exceptionエラーが発生して失敗する可能性があります。解決するには、イシュー566413の「Possible fixes」セクションを参照してください。

PostgreSQL ci_job_artifactsエラー

  • 影響: すべてのインストール方法
  • 影響を受けるバージョン: 18.1.0、18.1.1

GitLabバージョン18.1.0および18.1.1では、PostgreSQLログにERROR: relation "ci_job_artifacts" does not exist at ...のようなエラーが表示されることがあります。これらのログ上のエラーは無視しても問題ありませんが、Geoサイトを含め、モニタリングアラートがトリガーされる可能性があります。この問題を解決するには、GitLab 18.1.2以降にアップデートしてください。

マージリクエストがほぼ準備完了バグ

  • 影響: すべてのインストール方法
  • 影響を受けるバージョン: 18.1.0

一部のユーザーによるコミットを含むマージリクエストは進行せず、継続的にYour merge request is almost readyと表示される場合があります。イシュー554613を参照してください。さらに、sidekiq/currentログにはmerge_request_diff_commit.rbのundefined method 'id' for nil:NilClassエラーが表示されます。これを修正するには、次の手順に従います:

  1. database consoleを起動します。

  2. 次のコマンドを実行します:

    REINDEX TABLE CONCURRENTLY public.merge_request_diff_commit_users;

  3. 影響を受けたマージリクエストを閉じて、再度開きます。

Geo HTTP 500プロキシエラー

  • プラン: Premium、Ultimate
  • 影響: Geo
  • 影響を受けるバージョン:
    リリース影響を受けるパッチリリース修正パッチレベル
    18.118.1.018.1.1
    18.018.0.0 - 18.0.218.0.3

上記の表のGitLabバージョンには、セカンダリサイトからプロキシされたGit操作がHTTP 500エラーで失敗する既知のイシューがあります。解決するには、修正されたパッチレベルのリリースにアップグレードしてください。

PostgreSQL 14はサポートされていません

  • 影響: すべてのインストール方法
  • 影響を受けるバージョン: 18.0.0

PostgreSQL 14は、GitLab 18以降ではサポートされていません。GitLab 18.0以降にアップグレードする前に、PostgreSQLをバージョン16.5以降にアップグレードしてください。詳細については、installation requirementsを参照してください。

自動データベースバージョンアップグレードは、Linuxパッケージを使用している場合の単一ノードインスタンスにのみ適用されます。それ以外のケース、たとえばGeoインスタンス、Linuxパッケージを使用した高可用性のPostgreSQLデータベース、または外部PostgreSQLデータベース（Amazon RDSなど）を使用している場合は、PostgreSQLを手動でアップグレードする必要があります。詳細な手順については、Geoインスタンスをアップグレードするを参照してください。

pg_dumpバイナリ互換性

  • 影響: すべてのインストール方法
  • 影響を受けるバージョン: 18.0.0

GitLabはpg_dumpバイナリをバンドルしています。外部のPostgreSQLサーバーを使用する場合は、pg_dumpクライアントバージョンがPostgreSQLサーバーと互換性があることを確認し、GitLabデータベースのバックアップの作成と復元両方に対応していることを確認してください。

Bitnami PostgreSQLおよびRedisイメージの廃止

  • 影響: Helmチャート
  • 影響を受けるバージョン: 17.11.0以前

2025年9月29日以降、Bitnamiはタグ付きのPostgreSQLおよびRedisイメージの提供を終了します。GitLabチャートを使用し、RedisまたはPostgresをバンドルしたGitLab 17.11以前をデプロイしている場合は、予期しないダウンタイムを防ぐために、レガシーリポジトリを使用するように値を手動で更新する必要があります。詳細については、イシュー6089を参照してください。

17.11からのゼロダウンタイムアップグレード中のパイプラインの失敗

  • 影響: すべてのインストール方法
  • 影響を受けるバージョン: 18.0.0

機能フラグci_only_one_persistent_ref_creationにより、RailsがアップグレードされてもSidekiqがバージョン17.11のままの場合、ゼロダウンタイムアップグレード中にパイプラインが失敗することがあります（詳細はイシュー558808を参照してください）。

予防策: アップグレードする前に、Railsコンソールを開き、機能フラグを有効にします:

$ sudo gitlab-rails console
Feature.enable(:ci_only_one_persistent_ref_creation)

すでに影響を受けている場合: 次のコマンドを実行して、失敗したパイプラインを再試行します:

$ sudo gitlab-rails console
Rails.cache.delete_matched("pipeline:*:create_persistent_ref_service")

Gitaly設定をgit_data_dirsからストレージに移行する

  • 影響: Linuxパッケージ
  • 影響を受けるバージョン: 18.0.0

GitLab 18.0以降では、git_data_dirs設定を使用してGitalyストレージの場所を設定できなくなりました。

依然としてgit_data_dirsを使用している場合は、GitLab 18.0にアップグレードする前にGitaly設定を移行する必要があります。

Geo CEからEEへのロールバック移行エラー

  • プラン: Premium、Ultimate
  • 影響: Geo
  • 影響を受けるバージョン: 18.0.0

GitLab Enterprise Editionをデプロイした後にGitLab Community Editionに戻した場合、データベーススキーマがGitLabアプリケーションで想定されているスキーマと異なることがあり、移行エラーが発生する可能性があります。18.0.0へのアップグレード時には、このバージョンで追加された移行によって特定の列のデフォルトが変更されるため、4種類のエラーが発生する可能性があります。

発生するエラーは次のとおりです:

  • No such column: geo_nodes.verification_max_capacity
  • No such column: geo_nodes.minimum_reverification_interval
  • No such column: geo_nodes.repos_max_capacity
  • No such column: geo_nodes.container_repositories_max_capacity

この移行には、これらの列が欠落している場合に追加するためのパッチがGitLab 18.0.2で適用されました。イシュー543146を参照してください。

影響を受けるリリース:

影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
18.018.0.0 - 18.0.118.0.2

DockerインストールでのPRNG is not seededエラー

  • 影響: Docker
  • 影響を受けるバージョン: 18.0.0

FIPSが有効なホスト上でDockerインストール環境のGitLabを実行している場合、SSHキーの生成やOpenSSHサーバー（sshd）の起動が失敗し、次のエラーメッセージが表示されることがあります:

PRNG is not seeded

GitLab 18.0では、ベースイメージをUbuntu 22.04から24.04に更新しました。このエラーは、Ubuntu 24.04でFIPSホストが非FIPS OpenSSLプロバイダーを使用できなくなったことが原因で発生します。

この問題を解決するには、いくつかのオプションがあります:

  • ホストシステムでFIPSを無効にする。
  • GitLab Dockerコンテナ内でFIPSベースのカーネルの自動検出を無効にする。これは、GitLab 18.0.2以降でOPENSSL_FORCE_FIPS_MODE=0環境変数を設定することで実行できます。
  • GitLab Dockerイメージを使用する代わりに、ホスト上にネイティブのFIPSパッケージをインストールする。

最後のオプションが、FIPS要件を満たすための推奨手順です。レガシーインストールの場合は、最初の2つのオプションを一時的な対処方法として使用できます。

CIビルドメタデータ移行の詳細

  • 影響: すべてのインストール方法
  • 影響を受けるバージョン: 18.7.0

GitLab 18.6以降、新しいパイプラインは新しい形式にのみデータを書き込みます（イシュー552065を参照）。この移行は、既存のデータを古いフォーマットから新しいフォーマットにコピーするだけです。データは削除されません。

移行されなかったデータは、将来のリリースで削除されます（エピック18271を参照）。

移行期間は、インスタンス内のCIジョブの総数に正比例します。ジョブは、最新のパーティションから最も古いパーティションまで処理され、最近のデータが優先されます。

大規模なプロジェクトでautomaticパイプラインcleanupを有効にすることで、アップグレード前に古いパイプラインを削除し、移行するジョブの数を減らすことができます。

移行は2種類のデータをコピーします:

  • Jobs processing data: ジョブ実行時にRunnerにのみ必要で、UIやAPIには不要な.gitlab-ci.yml（script、variablesなど）からのジョブ実行設定。
  • Job data visible to users: すべてのジョブデータのうち、この移行はジョブタイムアウト値、ジョブ終了コード値、exposedアーティファクト 、およびenvironment associationsにのみ影響します。

大規模なCIデータセットを持つGitLab Self-ManagedインスタンスおよびGitLab Dedicatedインスタンスの場合、移行するデータのスコープを減らすことで、移行を高速化できます。スコープを制御するには、以下に定義されている設定を使用します。

ジョブ処理データのスコープの制御

デフォルトでは、移行は既存のすべてのジョブの処理データをコピーします。以下のいずれかの設定を使用することで、スコープを削減できます。

設定の値は、保持したいジョブ処理データの量を制御します。例えば、過去6か月以内に作成されたジョブのみが実行されると予想される場合（retries 、execution of manualジョブs 、environment auto-stopを通じて）、6moに設定します。

GitLabは、以下の優先順位で設定を探します:

  1. パイプラインarchival設定（推奨されるベストプラクティス）。アーカイブされたパイプラインは、ジョブを手動で再試行または再実行できないことを示します。この設定が有効になっている場合、アーカイブされたジョブの処理データは移行する必要はありません。

    パイプラインアーカイブ範囲が以降延長された場合、処理データのないジョブは実行不能なままになります。

  2. GITLAB_DB_CI_JOBS_PROCESSING_DATA_CUTOFF 環境変数（パイプラインアーカイブが設定されていない場合、またはこの移行のために上書きする必要がある場合）。1y（1年）、6mo（6ヶ月）、90d（90日）のような期間文字列を受け入れます。

  3. 上記のどちらも設定されていない場合、GITLAB_DB_CI_JOBS_MIGRATION_CUTOFF環境変数。1y（1年）、6mo（6ヶ月）、90d（90日）のような期間文字列を受け入れます。Controlling theスコープforジョブdata visible to usersを参照してください。

  4. 設定が見つからない場合、すべてのデータがコピーされます。

ユーザーに表示されるジョブデータのスコープの制御

環境変数GITLAB_DB_CI_JOBS_MIGRATION_CUTOFFは、どのジョブの可視データを移行するかを制御します。

例えば、GITLAB_DB_CI_JOBS_MIGRATION_CUTOFF=1yは、最も最近の1年間のジョブについて、影響を受ける可視データ（タイムアウト値、環境、終了コード値、および公開されたアーティファクトのメタデータ）をコピーします。

デフォルトでは、カットオフ日付はなく、すべてのジョブのデータが移行されます。

移行の影響の推定

参考として、GitLab.comでは、約2ヶ月で4億行のデータを移行する予定です。

インスタンスへの移行の影響を推定するには、PostgreSQL consoleで以下のクエリを実行できます:

SELECT n.nspname AS schema_name, c.relname AS partition_name,
       pg_size_pretty(pg_total_relation_size(c.oid)) AS total_size
FROM pg_inherits i
JOIN pg_class c ON c.oid = i.inhrelid
JOIN pg_namespace n ON n.oid = c.relnamespace
JOIN pg_class p ON p.oid = i.inhparent
WHERE p.relname = 'p_ci_builds_metadata'
ORDER BY pg_total_relation_size(c.oid) DESC;

新しいテーブルには、このスペースの約20％が必要です。

これはPostgreSQL統計テーブルからの推定です。

SELECT SUM(c.reltuples)::bigint AS estimated_jobs_count
FROM pg_class c
JOIN pg_inherits i ON c.oid = i.inhrelid
WHERE i.inhparent = 'p_ci_builds'::regclass;

特定の期間に作成されたジョブの数を見つけるには、テーブルをクエリする必要があります:

SELECT COUNT(*) FROM p_ci_builds WHERE created_at >= now() - '1 year'::interval;

クエリがタイムアウトした場合は、Rails consoleを使用してデータをバッチ処理します:

counts = []
CommitStatus.each_batch(of: 25000) do |batch|
  counts << batch.where(created_at: 1.year.ago...).count
end
counts.sum

マージリクエストマージデータに対するバッチバックグラウンド移行

  • 影響: すべてのインストール方法
  • 影響を受けるバージョン: 18.8.0

A batched background移行は、merge_requestsテーブルから新しい専用のmerge_requests_merge_dataテーブルに、マージリクエストのマージ関連データをコピーします。

この移行は、マージ固有の属性を別のテーブルに正規化し、クエリパフォーマンスと保守性を向上させるデータベーススキーマ最適化イニシアチブの一部です。

移行されるデータ

移行は、以下の列をmerge_requestsからmerge_requests_merge_dataにコピーします:

  • merge_commit_sha
  • merged_commit_sha
  • merge_ref_sha
  • squash_commit_sha
  • in_progress_merge_commit_sha
  • merge_status
  • auto_merge_enabled
  • squash
  • merge_user_id
  • merge_params
  • merge_error
  • merge_jid

移行はmerge_requestsテーブルを処理し、merge_requests_merge_dataにまだ対応するエントリがないマージリクエストのデータのみをコピーします。

GitLab 18.7以降、新しいマージリクエストは、アプリケーションレベルでのデュアルライトメカニズムを通じて両方のテーブルにデータを書き込みます（イシューを参照）。この移行は、デュアルライトが実装された以降に作成または変更されていない既存のデータのみをコピーします。

この移行中にmerge_requestsテーブルからデータは削除されません。

この移行はGitLab 18.9で完了する予定です。詳細については、イシューを参照してください。

移行期間を見積もる

移行期間は、インスタンス内のマージリクエストの数に正比例します。

影響を推定するには:

PostgreSQL query:

-- Count total merge requests
SELECT COUNT(*) FROM merge_requests;

-- Estimate table size
SELECT pg_size_pretty(pg_total_relation_size('merge_requests')) AS table_size;

Rails console:

# Count total merge requests
MergeRequest.count

# Count remaining merge requests to migrate
MergeRequest.left_joins(:merge_data)
  .where(merge_requests_merge_data: { merge_request_id: nil })
  .count

移行はマージリクエストをバッチで処理し、ほとんどのインスタンスでは数時間から数日以内に完了するはずです。

GitLab 18.11でのPostgreSQLバージョン17.7アップグレード

  • 影響: Linuxパッケージ、Docker、Geo
  • 影響を受けるバージョン: 18.11.0

GitLab 18.11へのアップグレードにより、単一ノードのLinuxパッケージインストールの場合、PostgreSQL 17.7への自動アップグレードがトリガーされます。

自動データベースバージョンアップグレードは、Linuxパッケージを使用している場合の単一ノードインスタンスにのみ適用されます。Geoデプロイの場合、メジャーバージョンのアップグレードにはGeoセカンダリへのPostgreSQLレプリケーションの再初期化が必要となるため、PostgreSQLのアップグレードは意図的にスケジュールおよび計画される必要があります。これにより、予想よりも長いダウンタイムが発生する可能性があります。

Sidekiq並行処理リミッターによりHelmチャートおよびOperatorデプロイでジョブのバックログが発生する

  • 影響: Helmチャート, Operator
  • 影響を受けるバージョン:
    リリース影響を受けるパッチリリース修正パッチレベル
    18.1018.10.0 - 18.10.318.10.4
    18.918.9.0 - 18.9.518.9.6

GitLab 18.9で、GitLab HelmチャートはデフォルトでGITLAB_SIDEKIQ_MAX_REPLICASを設定し始めました（charts/GitLabマージリクエスト4348）。KEDAベースのオートスケールを使用しないGitLab Self-ManagedおよびGitLab Dedicated環境では、これによりSidekiq並行処理リミッターが予期せずアクティブになり、ジョブがRedisをバックエンドとするスロットルされたキューに繰り延べられます。

これにより、以下の結果が生じる可能性があります:

  • Sidekiqジョブのバックログ。
  • Redisメモリの増加。
  • 遅延したジョブの実行。
  • WebHookWorker、AuditEvents::AuditEventStreamingWorker、およびGeoレプリケーションワーカー（Geo::EventWorker、Geo::SyncWorker）などのワーカーへの影響。

影響を受ける場合は、修正済みのバージョンにアップグレードするまで、以下のいずれかの一時的な軽減策を使用できます:

  • 機能フラグを有効にすることで、Disable the concurrency limiter for a specific workerにします。Sidekiqポッドでexecを実行して、Railsコンソールを開きます:

    kubectl exec -it <sidekiq-pod-name> -- gitlab-rails console

    次に、影響を受けるワーカーの機能フラグを有効にします:

    Feature.enable(:"disable_sidekiq_concurrency_limit_middleware_<WorkerClass>")

    <WorkerClass>を影響を受けるワーカー名（例: WebHookWorker）に置き換えます。

  • Sidekiqポッド環境設定でGITLAB_SIDEKIQ_MAX_REPLICAS=0を設定することにより、Disable all default concurrency limitsにします。これにより、デフォルトの並行処理制限の計算が完全に無効になります。

Geoを使用している場合、セカンダリサイトで既にスロットルされたジョブは、ConcurrencyLimit::ResumeWorkerがGeoセカンダリで実行されないため、自動的にドレインされない可能性があります。スロットルされたキューをクリアするために手動で介入する必要がある場合があります。

デフォルトの並行処理制限計算を機能フラグの背後にゲートする修正がマージリクエスト230713でマージされ、18.10.4（マージリクエスト231085）と18.9.6（マージリクエスト231297）にバックポートされました。

すべてのプロジェクトでシークレット検出の誤検出判定がデフォルトで有効化される

  • 影響: すべてのインストール方法
  • 影響を受けるバージョン: 18.10.x

シークレット誤検出判定の基本フローを有効にするには、通常2つのステップが必要です:

  1. グループに対して基本フローを許可します。
  2. 個々のプロジェクトに対して基本フローを有効にします。

しかし、GitLab 18.10のいずれかのバージョンへのアップグレードにより、すべてのプロジェクトに対してシークレット誤検出判定の基本フローが有効になります。グループに対して基本フローが許可されると、そのグループ内のすべてのプロジェクトで既に有効になります。

グループに対してシークレット誤検出判定の基本フローを許可する前に、グループ内のプロジェクトの設定を確認してください。