正式なドキュメントは英語版であり、この日本語訳は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.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の特定のアップグレードノート。

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時間）。

Ubuntu 24.04とカーネル6.8+でのGeo blobダウンロードの失敗

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

Ubuntu 24.04でカーネル6.8以降を実行しているLinuxパッケージのインストールでは、Geo blob同期失敗（アップロード、LFSオブジェクト、ジョブアーティファクト）が発生する可能性があります。影響を受けるセカンダリは、「started」または「pending」状態のままのblobを表示し、Sidekiqログにはセグメンテーション違反またはHPE_USER Span callback error in on_header_fieldエラーが含まれる場合があります。

このイシューは、rugged 1.9.0（GitLab 18.10でアップグレード）とLinuxパッケージにバンドルされているlibffi 3.2.1との間の相互作用によって発生します。これにより、より厳格なメモリ保護を備えた新しいカーネルでllhttp-ffi HTTPパーサーによって使用されるFFIコールバックが破損します。

GitLab 18.11.0およびGitLab 18.10.4では、機能フラグを使用してこのイシューの回避策を適用できます:

  1. geo_blob_download_with_gitlab_http機能フラグを有効にすると、blobダウンロードがFFIに依存するhttpgemの代わりにGitlab::HTTP（Net::HTTP）を使用するように切り替わります:

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

  2. Sidekiqを再起動します:

    sudo gitlab-ctl restart sidekiq

詳細については、イシュー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 integrationが有効になっている場合、権限の不足（DB::Exception: gitlab: Not enough privileges）により、アップグレードプロセス中にClickHouseデータベースの移行エラーが発生する可能性があります。このエラーを解決するには、database dictionary read support troubleshooting documentationを参照してください。

CIデータに対するバッチバックグラウンド移行が再導入されました

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

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

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.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リクエスト制限を参照してください。

GeoレプリケーションTypeErrorバグ

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

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

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.218.2.0 - 18.2.618.2.7
    18.118.1.0以降18.1では修正されず

GitLab 18.2.7以降には、イシュー559196の修正が含まれています。このイシューでは、Geo検証が長いファイル名を持つGitLab Pagesのデプロイで失敗する可能性がありました。この修正により、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

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