正式なドキュメントは英語版であり、この日本語訳は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パッケージ)のようにインストール方法が明記されている項目は、その方法にのみ該当します。それ以外の項目はすべてのインストール方法に該当します。

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に設定します。

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

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

ファイルストレージでlog_error NoMethodErrorが発生してGeo blobの同期が失敗する

  • プラン: 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すべてのパッチリリース未修正

blobをファイルストレージ(オブジェクトストレージではなく)に保存しているGeoセカンダリサイトで、 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に、RPMヘッダーデータサイズが16 MiBまでという制限(HEADER_DATA_MAX)があることです。 GitLabパッケージに含まれるファイル数が増加したことで、シリアライズされたRPMヘッダーがこの制限を超え、 インストール中にRPMデータベースのトランザクションが通知なく失敗していました。

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

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

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

SLES 12.5パッケージからMattermostとSpamcheckを削除

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

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

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

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

  • デフォルト: 28800(8時間)。
  • 最大値: 86400(24時間)。

Geo blobダウンロードの失敗

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

すべてのGeo blobタイプ(アップロード、LFSオブジェクト、ジョブアーティファクトなど)が、セカンダリで 継続的に同期に失敗することがあります。一時的なネットワークエラーとは異なり、 この失敗はすべてのblobレコードに影響し、再試行しても回復しません。 影響を受けるセカンダリでは、blobが「failed」状態になり、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では、競合するシンボルを含まない1.7.2にruggedがダウングレードされています。 アップグレード後に必要な操作はありません。

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. 機能フラグを有効にします。

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

  2. Sidekiqを再起動します。

    shell
    sudo gitlab-ctl restart sidekiq

この機能フラグによる回避策には、既知の制限事項があります。

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

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

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

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

GitLab 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を参照)。

ただし、このバグにより、レコードが1件のみの場合のバグが原因で、バッチ処理のバックグラウンド移行が通知なくスキップされることがあります。v18.8へのアップグレード時に、レコードが1件のみのテーブルを対象とするバッチ処理のバックグラウンド移行が、実行されないまま誤ってfinishedとしてマークされていました。その結果、データがバックフィルされず、GitLab Self-Managedインスタンスでアップグレードの失敗が発生していました。

修正案(マージリクエスト225461を参照)では、影響を受けるバッチ処理のバックグラウンド移行をfinished/finalizedからpausedに戻し、スケジューラーが再実行するようにします。対象は、queued_migration_versionが18.5から18.8の間で、かつmin_value = max_valueまたはmin_cursor = max_cursorである移行に限定されます。

次の2つの選択肢があります。

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

次のナレッジベース記事では、既知の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日以内に少なくとも1回使用されたデプロイキーをすべて特定できます。

sql
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

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

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

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

CIビルドのメタデータ移行で導入されたバッチ処理のバックグラウンド移行は、 データ構造のエッジケースに対処し、確実に完了するようにするため、 再導入されました。

引用符のないプレースホルダーを含むカスタム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

デプロイ後の移行により、 CIビルドのメタデータを新しい最適化されたテーブル(p_ci_job_definitions)にコピーする、バッチ処理の バックグラウンド移行がスケジュールされます。この移行は、 最終的にCIデータベースのサイズを削減する取り組みの一環です(エピック13886を参照)。 数百万件のジョブがあるインスタンスで移行を高速化したい場合は、 移行するデータを選択できます。

Geo ActionCableの許可オリジン設定

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

ActionCableのWebSocketリクエストで許可するオリジンを設定するための、新しいaction_cable_allowed_origins設定が追加されました。 サイト間のWebSocket接続を正しく機能させるため、プライマリサイトを設定する際に許可するURLを指定してください。

Geo VerificationStateBackfillWorkerの低速クエリの修正

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

Geo::VerificationStateBackfillWorkerがmerge_request_diff_detailsテーブルに対して大規模な低速クエリを生成するGeoのイシュー587407を修正しました。

コミットAPIおよびファイル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の制限を参照してください。

Duo Agent PlatformのRunner制限

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

Duo Agent Platformで使用できるRunnerに関する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のWebインターフェースに404エラーページが表示される。
  • GitLab Pagesが、他のサービス宛てのトラフィックを受信する可能性がある。
  • 以前は機能していた、別のホスト名を使用するあらゆるリクエストで問題が発生する。

この問題はLinuxパッケージでマージリクエスト8805により解決されており、修正は 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

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

GeoレプリケーションのTypeError

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

セカンダリのGeoサイトでは、バグにより、レプリケーションイベントがno implicit conversion of String into Array (TypeError)というエラーメッセージで失敗します。再検証などの冗長化の仕組みにより最終的な整合性は確保されますが、RPOが大幅に増加します。

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

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

GitLab 18.4.1、18.3.3、18.2.7では、サービス拒否攻撃を防止するために、JSON入力に対する制限が導入されました。 これらの制限を超えるHTTPリクエストに対して、GitLabは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 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以降には、長いファイル名を持つPagesデプロイでGeoの検証が失敗することがあるイシュー559196の修正が含まれています。この修正により、レプリケーションと検証の間で一貫性を保つため、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. データベースコンソールを起動します。

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

    sql
    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バージョンには、セカンダリのGeoサイトからプロキシされるGit操作がHTTP 500エラーで失敗する既知のイシューがあります。解決するには、修正済みパッチレベルのリリースにアップグレードしてください。

PostgreSQL 14はサポート対象外

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

PostgreSQL 14は、GitLab 18以降サポートされません。 GitLab 18.0以降にアップグレードする前に、PostgreSQLを少なくともバージョン16.5にアップグレードしてください。詳細については、 インストール要件を参照してください。

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

pg_dumpバイナリの互換性

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

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

BitnamiのPostgreSQLおよびRedisイメージの非推奨化

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

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

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

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

機能フラグci_only_one_persistent_ref_creationにより、Railsはアップグレードされたものの、Sidekiqがバージョン17.11のままになっているゼロダウンタイムアップグレード中に、パイプラインが失敗します(詳細はイシュー558808を参照)。

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

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

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

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

Gitaly設定をgit_data_dirsからstorageに移行する

  • 影響: 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ジョブの総数に正比例します。 最新のデータを優先するため、ジョブは新しいパーティションから古いパーティションの順に処理されます。

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

この移行では、次の2種類のデータをコピーします。

  • ジョブ処理データ: .gitlab-ci.ymlのジョブ実行設定(scriptやvariablesなど)。 ジョブの実行時にRunnerでのみ必要で、UIやAPIでは必要ありません。
  • ユーザーに表示されるジョブデータ: すべてのジョブデータのうち、この移行の影響を受けるのは、ジョブのタイムアウト値、 ジョブの終了コード、公開されているアーティファクト、 環境の関連付けのみです。

大規模なCIデータセットを持つGitLab Self-ManagedおよびGitLab Dedicatedインスタンスでは、 移行するデータの範囲を絞ることで、移行を高速化できます。範囲を制御するには、以下で説明する設定を使用します。

ジョブ処理データの範囲の制御

デフォルトでは、この移行はすべての既存ジョブの処理データをコピーします。 以下の設定のいずれかを使用して、範囲を絞り込めます。

設定の値で、保持するジョブ処理データの量を制御します。 たとえば、直近6か月以内に作成されたジョブのみが実行されると見込まれる場合は、6moに設定します (再試行、 手動ジョブの実行、 環境の自動停止による実行)。

GitLabは、次の優先順位で設定を参照します。

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

    後でパイプラインのアーカイブ範囲を拡大した場合、 処理データのないジョブは実行できないままになります。

  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日)のような期間文字列を指定できます。 ユーザーに表示されるジョブデータの範囲の制御を参照してください。

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

ユーザーに表示されるジョブデータの範囲の制御

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

たとえば、GITLAB_DB_CI_JOBS_MIGRATION_CUTOFF=1yを指定すると、直近1年間のジョブについて、 影響を受ける表示データ(タイムアウト値、環境、終了コード、公開されているアーティファクトのメタデータ)が コピーされます。

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

移行の影響の見積もり

参考として、GitLab.comでは、4億行を約2か月で移行する見込みです。

お使いのインスタンスへの移行の影響を見積もるには、 PostgreSQLコンソールで次のクエリを実行します。

sql
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の統計テーブルからの推定値です。

sql
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;

特定の期間に作成されたジョブの数を調べるには、テーブルに対してクエリを実行する必要があります。

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

クエリがタイムアウトする場合は、Railsコンソールを使用して データをバッチ処理します。

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

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

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

バッチ処理のバックグラウンド移行により、マージリクエストのマージ関連データが、 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クエリ:

sql
-- 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コンソール:

ruby
# 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のアップグレードは意図的にスケジュールし、計画する必要があります。 その結果、想定よりも長いダウンタイムが発生する可能性があります。

HelmチャートおよびOperatorのデプロイで、Sidekiqの並行処理リミッターがジョブのバックログを引き起こす

  • 影響: 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)などのワーカーへの影響。

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

  • 機能フラグを有効にして、特定のワーカーの並行処理リミッターを無効にします。 Sidekiqポッドでexecを実行して、Railsコンソールを開きます。

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

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

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

    <WorkerClass>を、影響を受けるワーカー名(たとえばWebHookWorker)に置き換えます。

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

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

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

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

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

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

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

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

シークレットの誤検出判定の基本フローをグループに対して許可する前に、そのグループ内のプロジェクトの設定を 確認することをおすすめします。

コンパイルされたジョブごとの設定に1 MiBのサイズ制限が適用される

  • 影響: すべてのインストール方法
  • 影響を受けるバージョン:
    リリース影響を受けるパッチリリース修正済みパッチレベル
    18.1118.11.x未修正
    19.019.0.0から19.0.519.0.6
    19.119.1.0から19.1.319.1.4
    19.219.2.0から19.2.119.2.2

JSONスキーマ検証を強制する変更により、コンパイルされたジョブごとの設定に1 MiBのサイズ制限も適用されるようになりました。ジョブのコンパイル済み設定(オプション、YAML変数、トークン、シークレットなど)がこの制限を超えると、パイプラインの作成は次のエラーで失敗します。Failed to persist the pipeline: Validation failed: Config is too large. Maximum size allowed is 1 MiB。回避策は、ジョブの設定のサイズを1 MiB未満に減らすことです。

修正済みバージョンにアップグレードすると、ci_max_total_yaml_size_bytesアプリケーション設定を使用して、サイズ制限を設定できるようになります。