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

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

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

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

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

Helmチャートインストールに関する追加情報については、Helmチャート6.0アップグレードノートを参照してください。

15.11.1

15.11.0

  • パッチリリース15.11.3以降にアップグレードしてください。これにより、15.5.0以前のバージョンからアップグレードする際のイシュー408304を回避できます。

  • 通常、PgBouncerを使用している環境では、バックアップ時にGITLAB_BACKUP_をプレフィックスとする変数を設定してPgBouncerを回避する必要があります。ただし、イシューにより、gitlab-backupは、オーバーライドで定義された直接接続ではなく、PgBouncerを介して標準のデータベース接続を使用するため、データベースのバックアップは失敗します。回避策は、pg_dumpを直接使用することです。

    影響を受けるリリース:

    影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
    15.11すべてなし
    16.0すべてなし
    16.1すべてなし
    16.2すべてなし
    16.3すべてなし
    16.4すべてなし
    16.5すべてなし
    16.6すべてなし
    16.716.7.0 - 16.7.616.7.7
    16.816.8.0 - 16.8.316.8.4

Linuxパッケージインストール

GitLab 15.11では、次の場合を除き、PostgreSQLは自動的に13.xにアップグレードされます:

  • Patroniを使用して高可用性でデータベースを実行している。
  • データベースノードがGitLab Geo構成の一部である。
  • PostgreSQLの自動アップグレードを明示的にオプトアウトしている。
  • /etc/gitlab/gitlab.rbでpostgresql['version'] = 12を設定している。

耐障害性およびGeoインストールは、PostgreSQL 13への手動アップグレードをサポートしています。詳しくは、HA/GeoクラスターにデプロイされたパッケージPostgreSQLを参照してください。

Geoインストール

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

pg_upgradeが、バンドルされているPostregSQLデータベースをバージョン13にアップグレードできない

影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
15.2 - 15.10すべてなし
15.1115.11.0 - 15.11.1115.11.12 以降

組み込みのpg-upgradeツールにバグがあり、バンドルされているPostgreSQLデータベースをバージョン13にアップグレードできません。この結果、セカンダリサイトが破損状態となり、GeoインストールをGitLab 16.xにアップグレードできなくなります（PostgreSQL 12のサポートは16.0以降のリリースで削除されています）。この問題は、バンドルされているPostgreSQLソフトウェアを使用しており、セカンダリのメインRailsデータベースとトラッキングデータベースの両方を同じノードで実行しているセカンダリサイトで発生します。15.11.12以降にアップグレードできない場合は、手動による回避策があります。

15.11.x

  • バグにより、新しいLDAPユーザーが初めてサインインする際に、LDAPのユーザー名属性ではなく、メールアドレスに基づいたユーザー名が割り当てられることがあります。手動での回避策は、gitlab_rails['omniauth_auto_link_ldap_user'] = trueを設定するか、バグが修正されたGitLab 16.1以降にアップグレードすることです。

15.10.5

  • Elastic IndexerのCronワーカーのバグにより、Sidekiqが飽和状態になる可能性があります。
    • この問題が発生すると、マージリクエストのマージ、パイプライン、Slack通知などのイベントが作成されなかったり、発生するまでに長い時間がかかったりすることがあります。
    • Sidekiqが飽和状態に達するまでに最大で1週間かかることがあるため、この問題がすぐに表面化するとは限りません。
    • この問題は、Elasticsearchを有効にしていない場合でも発生する可能性があります。
    • この問題を解決するには、15.11にアップグレードするか、問題の回避策を使用してください。
  • 多くのプロジェクトインポーターおよびグループインポーターで、これまでのデベロッパーロールに加えて、メンテナーロールが必要になりました。詳細については、お使いの各インポーターのドキュメントを参照してください。

15.10.0

  • Elastic IndexerのCronワーカーのバグにより、Sidekiqが飽和状態になる可能性があります。

    • この問題が発生すると、マージリクエストのマージ、パイプライン、Slack通知などのイベントが作成されなかったり、発生するまでに長い時間がかかったりすることがあります。
    • Sidekiqが飽和状態に達するまでに最大で1週間かかることがあるため、この問題がすぐに表面化するとは限りません。
    • この問題は、Elasticsearchを有効にしていない場合でも発生する可能性があります。
    • この問題を解決するには、15.11にアップグレードするか、問題の回避策を使用してください。

  • ゼロダウンタイムインデックス再作成のバグにより、インデックス再作成の際にCouldn't load task statusエラーが発生する場合があります。また、ElasticsearchホストでsliceId must be greater than 0 but was [-1]エラーが発生する場合もあります。回避策として、インデックスをゼロから再作成するか、GitLab 16.3にアップグレードすることを検討してください。

  • GitLab 16.0では、LinuxパッケージインスタンスにおけるGitaly設定が大幅に変更されています。GitLab 16.0に向けて下位互換性が維持されている間に、GitLab 15.10で新しい構造への移行を開始できます。この変更の詳細についてはこちらを参照してください。

  • GitLab 15.10以降にアップグレードする際に、次のエラーが発生する可能性があります:

    STDOUT: rake aborted!
StandardError: An error has occurred, all later migrations canceled:
PG::CheckViolation: ERROR:  check constraint "check_70f294ef54" is violated by some row

    このエラーは、GitLab 15.8で導入されたバッチバックグラウンド移行が、GitLab 15.10にアップグレードする前に完了していないことが原因です。このエラーを解決するには:

    1. データベースコンソール（Linuxパッケージインストールの場合はsudo gitlab-psql）を使用して、次のSQLステートメントを実行します:

      UPDATE oauth_access_tokens SET expires_in = '7200' WHERE expires_in IS NULL;

    2. データベースの移行を再実行します。

  • GitLab 15.10以降にアップグレードする際に、次のエラーが発生する可能性もあります:

    "exception.class": "ActiveRecord::StatementInvalid",
"exception.message": "PG::SyntaxError: ERROR:  zero-length delimited identifier at or near \"\"\"\"\nLINE 1: ...COALESCE(\"lock_version\", 0) + 1 WHERE \"ci_builds\".\"\" IN (SEL...\n

    このエラーは、GitLab 14.9で導入されたバッチバックグラウンド移行が、GitLab 15.10以降にアップグレードする前に完了していないことが原因です。このエラーを解決するには、移行を完了としてマークするのが安全な方法です:

    # Start the rails console

connection = Ci::ApplicationRecord.connection

Gitlab::Database::SharedModel.using_connection(connection) do
  migration = Gitlab::Database::BackgroundMigration::BatchedMigration.find_for_configuration(
    Gitlab::Database.gitlab_schemas_for_connection(connection), 'NullifyOrphanRunnerIdOnCiBuilds', :ci_builds, :id, [])

  # mark all jobs completed
  migration.batched_jobs.update_all(status: Gitlab::Database::BackgroundMigration::BatchedJob.state_machine.states[:succeeded].value)
  migration.update_attribute(:status, Gitlab::Database::BackgroundMigration::BatchedMigration.state_machine.states[:finished].value)
end

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

  • Terraformの設定に関するバグが原因で、gitlab.rb設定ファイルでgitlab_rails['terraform_state_enabled']がfalseに設定されていても、Terraformステートが有効なままになる問題が発生していました。このバグはGitLab 15.10で修正されたため、gitlab.rb設定でTerraformステート機能が無効になっている場合、GitLab 15.10にアップグレードすると、Terraformステート機能を使用しているプロジェクトが動作しなくなる可能性があります。そのため、gitlab.rbでgitlab_rails['terraform_state_enabled'] = falseを設定している場合は、Terraformステート機能を使用しているプロジェクトが存在しないか確認してください。これを確認するには、次の手順に従います:

    1. Railsコンソールの警告を確認します。
    2. Railsコンソールセッションを開始します。
    3. コマンドTerraform::State.pluck(:project_id)を実行します。このコマンドは、Terraformステートを持つすべてのプロジェクトIDの配列を返します。
    4. 各プロジェクトに移動し、必要に応じて関係者と協力して、Terraformステート機能が現在も使用されているかどうかを判断します。Terraformステートが不要な場合は、ステートファイルを削除する手順に従います。

Geoインストール

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed
  • pg_upgradeが、バンドルされているPostregSQLデータベースをバージョン13にアップグレードできません。詳細と回避策については、こちらを参照してください。
  • セカンダリサイトからのLFSオブジェクトのクローン作成では、セカンダリが完全に同期されている場合でも、プライマリサイトからダウンロードされます。詳細と回避策については、こちらを参照してください。

15.9.0

  • Elastic IndexerのCronワーカーのバグにより、Sidekiqが飽和状態になる可能性があります。

    • この問題が発生すると、マージリクエストのマージ、パイプライン、Slack通知などのイベントが作成されなかったり、発生するまでに長い時間がかかったりすることがあります。
    • Sidekiqが飽和状態に達するまでに最大で1週間かかることがあるため、この問題がすぐに表面化するとは限りません。
    • この問題は、Elasticsearchを有効にしていない場合でも発生する可能性があります。
    • この問題を解決するには、15.11にアップグレードするか、問題の回避策を使用してください。

  • BackfillTraversalIdsToBlobsAndWikiBlobs高度検索の移行に関するバグにより、Elasticsearchクラスターが飽和状態になる可能性があります。

    • この問題が発生すると、検索の速度が低下し、Elasticsearchクラスターの更新が完了するまでに時間がかかることがあります。
    • この問題を解決するには、GitLab 15.10にアップグレードして、移行のバッチサイズを縮小してください。

  • パッチリリース15.9.3以降にアップグレードしてください。これには、次の2つのデータベース移行のバグ修正が含まれています:

    • パッチリリース15.9.0、15.9.1、15.9.2には、ユーザープロファイルフィールドlinkedin、twitter、skype、website_url、location、organizationのデータが失われる可能性があるバグが存在します。詳細については、イシュー393216を参照してください。
    • 2つ目のバグの修正により、15.4.xから直接アップグレードできるようになります。

  • CIパーティショニング作業の一環として、新しい外部キーがci_builds_needsに追加されました。CIテーブルが大きいGitLabインスタンスでは、この制約の追加に通常よりも時間がかかることがあります。

  • Praefectのメタデータ検証機能において無効なメタデータの削除動作がデフォルトで有効になりました。

    メタデータ検証機能は、Praefectデータベース内のレプリカレコードを処理し、そのレプリカがGitalyノードに実際に存在することを確認します。レプリカが存在しない場合、そのメタデータレコードは削除されます。これにより、Praefectは、メタデータレコード上ではレプリカに問題がないことが示されているものの、実際にはディスク上に存在しない状況を修正できます。メタデータレコードが削除されると、Praefect reconcilerがそのレプリカを再作成するためのレプリケーションジョブをスケジュールします。

    過去にステート管理ロジックに関する問題があったため、データベース内に無効なメタデータレコードが存在する可能性があります。これは、たとえばリポジトリの削除が不完全だった場合や、名前の変更が中断された場合などに発生します。検証機能は、影響を受けたリポジトリの古いレプリカレコードを削除します。レプリカレコードが削除されるため、これらのリポジトリはメトリクスおよびpraefect datalossサブコマンドで、利用できないリポジトリとして表示される場合があります。このようなリポジトリが確認された場合は、praefect remove-repositoryを使用して、そのリポジトリおよびリポジトリに残っているレコードを削除してください。

    GitLab 15.0以降では、検証機能が出力したログレコードを検索することで、無効なメタデータレコードを持つリポジトリを特定できます。リポジトリの検証の詳細、およびログエントリの例については、こちらを参照してください。

  • GitLab 16.0のLinuxパッケージインスタンスで、Praefect設定が大幅に変更されました。GitLab 16.0に向けて下位互換性が維持されている間に、GitLab 15.9で新しい構造への移行を開始できます。この変更の詳細についてはこちらを参照してください。

自己コンパイルによるインストール

  • 自己コンパイル（ソース）によるインストールの場合、gitlab-sshdの追加に伴い、GitLab ShellをビルドするにはKerberosヘッダーが必要になります。

    sudo apt install libkrb5-dev

Geoインストール

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed
  • pg_upgradeが、バンドルされているPostregSQLデータベースをバージョン13にアップグレードできません。詳細と回避策については、こちらを参照してください。
  • セカンダリサイトからのLFSオブジェクトのクローン作成では、セカンダリが完全に同期されている場合でも、プライマリサイトからダウンロードされます。詳細と回避策については、こちらを参照してください。

15.8.2

Geoインストール

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed
  • 一部のGeoインストールで、プロジェクトおよびWikiのレプリケーションと検証が追いついていない問題が見つかりました。検証処理で一部のプロジェクトやWikiが長時間にわたって「キューに入っている」状態のままの場合、そのインストールがこの問題の影響を受けている可能性があります。この問題により、フェイルオーバー後にデータが失われる可能性があります。
    • 影響を受けるバージョン: GitLabバージョン15.6.x、15.7.x、および15.8.0 - 15.8.2。
    • 修正を含むバージョン: GitLab 15.8.3以降。

15.8.1

Geoインストール

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed
  • 一部のGeoインストールで、プロジェクトおよびWikiのレプリケーションと検証が追いついていない問題が見つかりました。検証処理で一部のプロジェクトやWikiが長時間にわたって「キューに入っている」状態のままの場合、そのインストールがこの問題の影響を受けている可能性があります。この問題により、フェイルオーバー後にデータが失われる可能性があります。
    • 影響を受けるバージョン: GitLabバージョン15.6.x、15.7.x、および15.8.0 - 15.8.2。
    • 修正を含むバージョン: GitLab 15.8.3以降。

15.8.0

Geoインストール

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed
  • pg_upgradeが、バンドルされているPostregSQLデータベースをバージョン13にアップグレードできません。詳細と回避策については、こちらを参照してください。
  • 一部のGeoインストールで、プロジェクトおよびWikiのレプリケーションと検証が追いついていない問題が見つかりました。検証処理で一部のプロジェクトやWikiが長時間にわたって「キューに入っている」状態のままの場合、そのインストールがこの問題の影響を受けている可能性があります。この問題により、フェイルオーバー後にデータが失われる可能性があります。
    • 影響を受けるバージョン: GitLabバージョン15.6.x、15.7.x、および15.8.0 - 15.8.2。
    • 修正を含むバージョン: GitLab 15.8.3以降。
  • セカンダリサイトからのLFSオブジェクトのクローン作成では、セカンダリが完全に同期されている場合でも、プライマリサイトからダウンロードされます。詳細と回避策については、こちらを参照してください。

15.7.6

Geoインストール

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed
  • 一部のGeoインストールで、プロジェクトおよびWikiのレプリケーションと検証が追いついていない問題が見つかりました。検証処理で一部のプロジェクトやWikiが長時間にわたって「キューに入っている」状態のままの場合、そのインストールがこの問題の影響を受けている可能性があります。この問題により、フェイルオーバー後にデータが失われる可能性があります。
    • 影響を受けるバージョン: GitLabバージョン15.6.x、15.7.x、および15.8.0 - 15.8.2。
    • 修正を含むバージョン: GitLab 15.8.3以降。

15.7.5

Geoインストール

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed
  • 一部のGeoインストールで、プロジェクトおよびWikiのレプリケーションと検証が追いついていない問題が見つかりました。検証処理で一部のプロジェクトやWikiが長時間にわたって「キューに入っている」状態のままの場合、そのインストールがこの問題の影響を受けている可能性があります。この問題により、フェイルオーバー後にデータが失われる可能性があります。
    • 影響を受けるバージョン: GitLabバージョン15.6.x、15.7.x、および15.8.0 - 15.8.2。
    • 修正を含むバージョン: GitLab 15.8.3以降。

15.7.4

Geoインストール

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed
  • 一部のGeoインストールで、プロジェクトおよびWikiのレプリケーションと検証が追いついていない問題が見つかりました。検証処理で一部のプロジェクトやWikiが長時間にわたって「キューに入っている」状態のままの場合、そのインストールがこの問題の影響を受けている可能性があります。この問題により、フェイルオーバー後にデータが失われる可能性があります。
    • 影響を受けるバージョン: GitLabバージョン15.6.x、15.7.x、および15.8.0 - 15.8.2。
    • 修正を含むバージョン: GitLab 15.8.3以降。

15.7.3

Geoインストール

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed
  • 一部のGeoインストールで、プロジェクトおよびWikiのレプリケーションと検証が追いついていない問題が見つかりました。検証処理で一部のプロジェクトやWikiが長時間にわたって「キューに入っている」状態のままの場合、そのインストールがこの問題の影響を受けている可能性があります。この問題により、フェイルオーバー後にデータが失われる可能性があります。
    • 影響を受けるバージョン: GitLabバージョン15.6.x、15.7.x、および15.8.0 - 15.8.2。
    • 修正を含むバージョン: GitLab 15.8.3以降。

15.7.2

Geoインストール

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed
  • /api/v4/container_registry_event/eventsエンドポイントによってコンテナレジストリプッシュイベントが拒否されるため、Geoセカンダリサイトがコンテナレジストリイメージの更新を検知できず、アップグレードをレプリケートしません。その結果、フェイルオーバー後にセカンダリサイト上に古いコンテナイメージが含まれている可能性があります。この問題は、バージョン15.6.0 - 15.6.6および15.7.0 - 15.7.2に影響します。コンテナリポジトリでGeoを使用している場合は、フェイルオーバー後の潜在的なデータ損失を回避するために、この問題の修正が含まれているGitLab 15.6.7、15.7.3、または15.8.0にアップグレードすることをおすすめします。
  • 一部のGeoインストールで、プロジェクトおよびWikiのレプリケーションと検証が追いついていない問題が見つかりました。検証処理で一部のプロジェクトやWikiが長時間にわたって「キューに入っている」状態のままの場合、そのインストールがこの問題の影響を受けている可能性があります。この問題により、フェイルオーバー後にデータが失われる可能性があります。
    • 影響を受けるバージョン: GitLabバージョン15.6.x、15.7.x、および15.8.0 - 15.8.2。
    • 修正を含むバージョン: GitLab 15.8.3以降。

15.7.1

Geoインストール

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed
  • /api/v4/container_registry_event/eventsエンドポイントによってコンテナレジストリプッシュイベントが拒否されるため、Geoセカンダリサイトがコンテナレジストリイメージの更新を検知できず、アップデートをレプリケートしません。その結果、フェイルオーバー後にセカンダリサイト上に古いコンテナイメージが含まれている可能性があります。この問題は、バージョン15.6.0 - 15.6.6および15.7.0 - 15.7.2に影響します。コンテナリポジトリでGeoを使用している場合は、フェイルオーバー後の潜在的なデータ損失を回避するために、この問題の修正が含まれているGitLab 15.6.7、15.7.3、または15.8.0にアップグレードすることをおすすめします。
  • 一部のGeoインストールで、プロジェクトおよびWikiのレプリケーションと検証が追いついていない問題が見つかりました。検証処理で一部のプロジェクトやWikiが長時間にわたって「キューに入っている」状態のままの場合、そのインストールがこの問題の影響を受けている可能性があります。この問題により、フェイルオーバー後にデータが失われる可能性があります。
    • 影響を受けるバージョン: GitLabバージョン15.6.x、15.7.x、および15.8.0 - 15.8.2。
    • 修正を含むバージョン: GitLab 15.8.3以降。

15.7.0

  • このバージョンは、issues.work_item_type_id列に対してNOT NULL DB制約を検証します。このバージョンにアップグレードするには、issuesテーブルにwork_item_type_idがNULLのレコードが存在してはいけません。複数のBackfillWorkItemTypeIdForIssuesバックグラウンド移行が存在し、それらはEnsureWorkItemTypeBackfillMigrationFinishedデプロイ後移行によって完了します。

  • GitLab 15.4.0では、イシューテーブルのnamespace_id値をバックフィルするバッチバックグラウンド移行が導入されました。大規模なGitLabインスタンスでは、この移行が完了するまで数時間から数日かかる場合があります。15.7.0にアップグレードする前に、移行が正常に完了していることを確認してください。

  • データベース制約が追加され、イシューテーブルのnamespace_id列にNULL値が存在しないことが指定されます。

    • 15.4で実行されたnamespace_idのバッチバックグラウンド移行が失敗している場合（前の項目を参照）、15.7へのアップグレードはデータベース移行エラーで失敗します。

    • イシューテーブルが大きいGitLabインスタンスでは、この制約の検証により、アップグレードに通常よりも時間がかかります。すべてのデータベースの変更は、1時間以内に完了する必要があります:

      FATAL: Mixlib::ShellOut::CommandTimeout: rails_migration[gitlab-rails]
[..]
Mixlib::ShellOut::CommandTimeout: Command timed out after 3600s:

      データ変更とアップグレードを手動で完了するための回避策があります。

  • デフォルトのSidekiqのmax_concurrencyが20に変更されました。これにより、ドキュメントと製品のデフォルト設定で値が統一されました。

    以前の例:

    • Linuxパッケージインストールのデフォルト（sidekiq['max_concurrency']）: 50
    • 自己コンパイルによるインストールのデフォルト: 50
    • Helmチャートのデフォルト（gitlab.sidekiq.concurrency）: 25

    リファレンスアーキテクチャでは、デフォルトとして引き続き10を使用します。これは、それぞれの構成に合わせて個別に設定されているためです。

    max_concurrencyをすでに設定しているサイトには、この変更の影響はありません。Sidekiqの並行処理設定の詳細については、こちらを参照してください。

  • GitLab Runner 15.7.0では、CI/CDジョブに影響を与える破壊的な変更が導入されました: ジョブファイル変数の展開を正しく処理するようになっています。以前は、ジョブ定義変数がファイルタイプ変数を参照している場合、その変数はファイル変数の値（ファイルの内容）に展開されていました。この動作は、通常のShell変数の展開ルールに従っていませんでした。また、ファイル変数とその内容が出力された場合、シークレットや機密情報が漏洩する可能性もありました。たとえば、echoコマンドで出力した場合などです。詳細については、Understanding the file type variable expansion change in GitLab 15.7を参照してください。

  • GitLab 15.4で導入されたバグが原因で、Gitaly Cluster (Praefect)内の1つ以上のGitリポジトリが利用できない場合、影響を受けるGitaly Cluster (Praefect)内のすべてのプロジェクトまたはプロジェクトWikiリポジトリに対して、リポジトリチェックとGeoのレプリケーションおよび検証が停止します。このバグは、GitLab 15.9.0で変更をリバートすることにより修正されました。このバージョンにアップグレードする前に、「利用できない」リポジトリが存在しないか確認してください。詳細については、このバグのイシューを参照してください。

  • セカンダリサイトからのLFSオブジェクトのクローン作成では、セカンダリが完全に同期されている場合でも、プライマリサイトからダウンロードされます。詳細と回避策については、こちらを参照してください。

Geoインストール

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed
  • pg_upgradeが、バンドルされているPostregSQLデータベースをバージョン13にアップグレードできません。詳細と回避策については、こちらを参照してください。
  • /api/v4/container_registry_event/eventsエンドポイントによってコンテナレジストリプッシュイベントが拒否されるため、Geoセカンダリサイトがコンテナレジストリイメージの更新を検知できず、アップデートをレプリケートしません。その結果、フェイルオーバー後にセカンダリサイト上に古いコンテナイメージが含まれている可能性があります。この問題は、バージョン15.6.0 - 15.6.6および15.7.0 - 15.7.2に影響します。コンテナリポジトリでGeoを使用している場合は、フェイルオーバー後の潜在的なデータ損失を回避するために、この問題の修正が含まれているGitLab 15.6.7、15.7.3、または15.8.0にアップグレードすることをおすすめします。
  • 一部のGeoインストールで、プロジェクトおよびWikiのレプリケーションと検証が追いついていない問題が見つかりました。検証処理で一部のプロジェクトやWikiが長時間にわたって「キューに入っている」状態のままの場合、そのインストールがこの問題の影響を受けている可能性があります。この問題により、フェイルオーバー後にデータが失われる可能性があります。
    • 影響を受けるバージョン: GitLabバージョン15.6.x、15.7.x、および15.8.0 - 15.8.2。
    • 修正を含むバージョン: GitLab 15.8.3以降。

15.6.7

Geoインストール

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed
  • 一部のGeoインストールで、プロジェクトおよびWikiのレプリケーションと検証が追いついていない問題が見つかりました。検証処理で一部のプロジェクトやWikiが長時間にわたって「キューに入っている」状態のままの場合、そのインストールがこの問題の影響を受けている可能性があります。この問題により、フェイルオーバー後にデータが失われる可能性があります。
    • 影響を受けるバージョン: GitLabバージョン15.6.x、15.7.x、および15.8.0 - 15.8.2。
    • 修正を含むバージョン: GitLab 15.8.3以降。

15.6.6

Geoインストール

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed
  • /api/v4/container_registry_event/eventsエンドポイントによってコンテナレジストリプッシュイベントが拒否されるため、Geoセカンダリサイトがコンテナレジストリイメージの更新を検知できず、アップデートをレプリケートしません。その結果、フェイルオーバー後にセカンダリサイト上に古いコンテナイメージが含まれている可能性があります。この問題は、バージョン15.6.0 - 15.6.6および15.7.0 - 15.7.2に影響します。コンテナリポジトリでGeoを使用している場合は、フェイルオーバー後の潜在的なデータ損失を回避するために、この問題の修正が含まれているGitLab 15.6.7、15.7.3、または15.8.0にアップグレードすることをおすすめします。
  • 一部のGeoインストールで、プロジェクトおよびWikiのレプリケーションと検証が追いついていない問題が見つかりました。検証処理で一部のプロジェクトやWikiが長時間にわたって「キューに入っている」状態のままの場合、そのインストールがこの問題の影響を受けている可能性があります。この問題により、フェイルオーバー後にデータが失われる可能性があります。
    • 影響を受けるバージョン: GitLabバージョン15.6.x、15.7.x、および15.8.0 - 15.8.2。
    • 修正を含むバージョン: GitLab 15.8.3以降。

15.6.5

Geoインストール

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed
  • /api/v4/container_registry_event/eventsエンドポイントによってコンテナレジストリプッシュイベントが拒否されるため、Geoセカンダリサイトがコンテナレジストリイメージの更新を検知できず、アップデートをレプリケートしません。その結果、フェイルオーバー後にセカンダリサイト上に古いコンテナイメージが含まれている可能性があります。この問題は、バージョン15.6.0 - 15.6.6および15.7.0 - 15.7.2に影響します。コンテナリポジトリでGeoを使用している場合は、フェイルオーバー後の潜在的なデータ損失を回避するために、この問題の修正が含まれているGitLab 15.6.7、15.7.3、または15.8.0にアップグレードすることをおすすめします。
  • 一部のGeoインストールで、プロジェクトおよびWikiのレプリケーションと検証が追いついていない問題が見つかりました。検証処理で一部のプロジェクトやWikiが長時間にわたって「キューに入っている」状態のままの場合、そのインストールがこの問題の影響を受けている可能性があります。この問題により、フェイルオーバー後にデータが失われる可能性があります。
    • 影響を受けるバージョン: GitLabバージョン15.6.x、15.7.x、および15.8.0 - 15.8.2。
    • 修正を含むバージョン: GitLab 15.8.3以降。
  • GitLab 15.4で導入されたバグが原因で、Gitaly Cluster (Praefect)内の1つ以上のGitリポジトリが利用できない場合、影響を受けるGitaly Cluster (Praefect)内のすべてのプロジェクトまたはプロジェクトWikiリポジトリに対して、リポジトリチェックとGeoのレプリケーションおよび検証が停止します。このバグは、GitLab 15.9.0で変更をリバートすることにより修正されました。このバージョンにアップグレードする前に、「利用できない」リポジトリが存在しないか確認してください。詳細については、このバグのイシューを参照してください。

15.6.4

Geoインストール

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed
  • /api/v4/container_registry_event/eventsエンドポイントによってコンテナレジストリプッシュイベントが拒否されるため、Geoセカンダリサイトがコンテナレジストリイメージの更新を検知できず、アップデートをレプリケートしません。その結果、フェイルオーバー後にセカンダリサイト上に古いコンテナイメージが含まれている可能性があります。この問題は、バージョン15.6.0 - 15.6.6および15.7.0 - 15.7.2に影響します。コンテナリポジトリでGeoを使用している場合は、フェイルオーバー後の潜在的なデータ損失を回避するために、この問題の修正が含まれているGitLab 15.6.7、15.7.3、または15.8.0にアップグレードすることをおすすめします。
  • 一部のGeoインストールで、プロジェクトおよびWikiのレプリケーションと検証が追いついていない問題が見つかりました。検証処理で一部のプロジェクトやWikiが長時間にわたって「キューに入っている」状態のままの場合、そのインストールがこの問題の影響を受けている可能性があります。この問題により、フェイルオーバー後にデータが失われる可能性があります。
    • 影響を受けるバージョン: GitLabバージョン15.6.x、15.7.x、および15.8.0 - 15.8.2。
    • 修正を含むバージョン: GitLab 15.8.3以降。
  • GitLab 15.4で導入されたバグが原因で、Gitaly Cluster (Praefect)内の1つ以上のGitリポジトリが利用できない場合、影響を受けるGitaly Cluster (Praefect)内のすべてのプロジェクトまたはプロジェクトWikiリポジトリに対して、リポジトリチェックとGeoのレプリケーションおよび検証が停止します。このバグは、GitLab 15.9.0で変更をリバートすることにより修正されました。このバージョンにアップグレードする前に、「利用できない」リポジトリが存在しないか確認してください。詳細については、このバグのイシューを参照してください。

15.6.3

Geoインストール

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed
  • /api/v4/container_registry_event/eventsエンドポイントによってコンテナレジストリプッシュイベントが拒否されるため、Geoセカンダリサイトがコンテナレジストリイメージの更新を検知できず、アップデートをレプリケートしません。その結果、フェイルオーバー後にセカンダリサイト上に古いコンテナイメージが含まれている可能性があります。この問題は、バージョン15.6.0 - 15.6.6および15.7.0 - 15.7.2に影響します。コンテナリポジトリでGeoを使用している場合は、フェイルオーバー後の潜在的なデータ損失を回避するために、この問題の修正が含まれているGitLab 15.6.7、15.7.3、または15.8.0にアップグレードすることをおすすめします。
  • 一部のGeoインストールで、プロジェクトおよびWikiのレプリケーションと検証が追いついていない問題が見つかりました。検証処理で一部のプロジェクトやWikiが長時間にわたって「キューに入っている」状態のままの場合、そのインストールがこの問題の影響を受けている可能性があります。この問題により、フェイルオーバー後にデータが失われる可能性があります。
    • 影響を受けるバージョン: GitLabバージョン15.6.x、15.7.x、および15.8.0 - 15.8.2。
    • 修正を含むバージョン: GitLab 15.8.3以降。
  • GitLab 15.4で導入されたバグが原因で、Gitaly Cluster (Praefect)内の1つ以上のGitリポジトリが利用できない場合、影響を受けるGitaly Cluster (Praefect)内のすべてのプロジェクトまたはプロジェクトWikiリポジトリに対して、リポジトリチェックとGeoのレプリケーションおよび検証が停止します。このバグは、GitLab 15.9.0で変更をリバートすることにより修正されました。このバージョンにアップグレードする前に、「利用できない」リポジトリが存在しないか確認してください。詳細については、このバグのイシューを参照してください。

15.6.2

Geoインストール

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed
  • /api/v4/container_registry_event/eventsエンドポイントによってコンテナレジストリプッシュイベントが拒否されるため、Geoセカンダリサイトがコンテナレジストリイメージの更新を検知できず、アップデートをレプリケートしません。その結果、フェイルオーバー後にセカンダリサイト上に古いコンテナイメージが含まれている可能性があります。この問題は、バージョン15.6.0 - 15.6.6および15.7.0 - 15.7.2に影響します。コンテナリポジトリでGeoを使用している場合は、フェイルオーバー後の潜在的なデータ損失を回避するために、この問題の修正が含まれているGitLab 15.6.7、15.7.3、または15.8.0にアップグレードすることをおすすめします。
  • 一部のGeoインストールで、プロジェクトおよびWikiのレプリケーションと検証が追いついていない問題が見つかりました。検証処理で一部のプロジェクトやWikiが長時間にわたって「キューに入っている」状態のままの場合、そのインストールがこの問題の影響を受けている可能性があります。この問題により、フェイルオーバー後にデータが失われる可能性があります。
    • 影響を受けるバージョン: GitLabバージョン15.6.x、15.7.x、および15.8.0 - 15.8.2。
    • 修正を含むバージョン: GitLab 15.8.3以降。
  • GitLab 15.4で導入されたバグが原因で、Gitaly Cluster (Praefect)内の1つ以上のGitリポジトリが利用できない場合、影響を受けるGitaly Cluster (Praefect)内のすべてのプロジェクトまたはプロジェクトWikiリポジトリに対して、リポジトリチェックとGeoのレプリケーションおよび検証が停止します。このバグは、GitLab 15.9.0で変更をリバートすることにより修正されました。このバージョンにアップグレードする前に、「利用できない」リポジトリが存在しないか確認してください。詳細については、このバグのイシューを参照してください。

15.6.1

Geoインストール

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed
  • /api/v4/container_registry_event/eventsエンドポイントによってコンテナレジストリプッシュイベントが拒否されるため、Geoセカンダリサイトがコンテナレジストリイメージの更新を検知できず、アップデートをレプリケートしません。その結果、フェイルオーバー後にセカンダリサイト上に古いコンテナイメージが含まれている可能性があります。この問題は、バージョン15.6.0 - 15.6.6および15.7.0 - 15.7.2に影響します。コンテナリポジトリでGeoを使用している場合は、フェイルオーバー後の潜在的なデータ損失を回避するために、この問題の修正が含まれているGitLab 15.6.7、15.7.3、または15.8.0にアップグレードすることをおすすめします。
  • 一部のGeoインストールで、プロジェクトおよびWikiのレプリケーションと検証が追いついていない問題が見つかりました。検証処理で一部のプロジェクトやWikiが長時間にわたって「キューに入っている」状態のままの場合、そのインストールがこの問題の影響を受けている可能性があります。この問題により、フェイルオーバー後にデータが失われる可能性があります。
    • 影響を受けるバージョン: GitLabバージョン15.6.x、15.7.x、および15.8.0 - 15.8.2。
    • 修正を含むバージョン: GitLab 15.8.3以降。
  • GitLab 15.4で導入されたバグが原因で、Gitaly Cluster (Praefect)内の1つ以上のGitリポジトリが利用できない場合、影響を受けるGitaly Cluster (Praefect)内のすべてのプロジェクトまたはプロジェクトWikiリポジトリに対して、リポジトリチェックとGeoのレプリケーションおよび検証が停止します。このバグは、GitLab 15.9.0で変更をリバートすることにより修正されました。このバージョンにアップグレードする前に、「利用できない」リポジトリが存在しないか確認してください。詳細については、このバグのイシューを参照してください。

15.6.0

  • 公式にサポートされているPostgreSQLバージョンのいずれかを使用する必要があります。一部のデータベース移行は、古いPostgreSQLバージョンで安定性とパフォーマンスの問題を引き起こす可能性があります。

  • Gitalyでは、Git 2.37.0以降が必須です。自己コンパイルによるインストールでは、Gitalyが提供するGitバージョンを使用する必要があります。

  • 4つのインデックスの動作を変更するためのデータベースの変更が、これらのインデックスが存在しないインスタンスでは失敗します:

    Caused by:
PG::UndefinedTable: ERROR:  relation "index_issues_on_title_trigram" does not exist

    その他の3つのインデックスは、index_merge_requests_on_title_trigram、index_merge_requests_on_description_trigram、index_issues_on_description_trigramです。

    この問題はGitLab 15.7で修正され、GitLab 15.6.2にバックポートされました。この問題には回避策もあります: これらのインデックスを作成する方法を参照してください。

Linuxパッケージインストール

GitLab 15.6では、omnibus-gitlabパッケージに同梱されているPostgreSQLのバージョンが12.12および13.8にアップグレードされました。明示的にオプトアウトしない限り、これによりPostgreSQLサービスが自動的に再起動され、ダウンタイムが発生する可能性があります。

Geoインストール

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed
  • pg_upgradeが、バンドルされているPostregSQLデータベースをバージョン13にアップグレードできません。詳細と回避策については、こちらを参照してください。
  • /api/v4/container_registry_event/eventsエンドポイントによってコンテナレジストリプッシュイベントが拒否されるため、Geoセカンダリサイトがコンテナレジストリイメージの更新を検知できず、アップデートをレプリケートしません。その結果、フェイルオーバー後にセカンダリサイト上に古いコンテナイメージが含まれている可能性があります。この問題は、バージョン15.6.0 - 15.6.6および15.7.0 - 15.7.2に影響します。コンテナリポジトリでGeoを使用している場合は、フェイルオーバー後の潜在的なデータ損失を回避するために、この問題の修正が含まれているGitLab 15.6.7、15.7.3、または15.8.0にアップグレードすることをおすすめします。
  • 一部のGeoインストールで、プロジェクトおよびWikiのレプリケーションと検証が追いついていない問題が見つかりました。検証処理で一部のプロジェクトやWikiが長時間にわたって「キューに入っている」状態のままの場合、そのインストールがこの問題の影響を受けている可能性があります。この問題により、フェイルオーバー後にデータが失われる可能性があります。
    • 影響を受けるバージョン: GitLabバージョン15.6.x、15.7.x、および15.8.0 - 15.8.2。
    • 修正を含むバージョン: GitLab 15.8.3以降。
  • GitLab 15.4で導入されたバグが原因で、Gitaly Cluster (Praefect)内の1つ以上のGitリポジトリが利用できない場合、影響を受けるGitaly Cluster (Praefect)内のすべてのプロジェクトまたはプロジェクトWikiリポジトリに対して、リポジトリチェックとGeoのレプリケーションおよび検証が停止します。このバグは、GitLab 15.9.0で変更をリバートすることにより修正されました。このバージョンにアップグレードする前に、「利用できない」リポジトリが存在しないか確認してください。詳細については、このバグのイシューを参照してください。
  • セカンダリサイトからのLFSオブジェクトのクローン作成では、セカンダリが完全に同期されている場合でも、プライマリサイトからダウンロードされます。詳細と回避策については、こちらを参照してください。

15.5.5

15.5.4

15.5.3

  • GitLab 15.4.0で、すべてのジョブをdefaultキューにルーティングするデフォルトのSidekiqルーティングルールが導入されました。キューセレクターを使用しているインスタンスでは、一部のSidekiqプロセスがアイドル状態になるため、このルールによってパフォーマンスの問題が発生します。

    • デフォルトのルーティングルールは15.5.4でリバートされたため、そのバージョン以降にアップグレードすると以前の動作に戻ります。

    • GitLabインスタンスがdefaultキューのみをリッスンしている場合（これは現在推奨されていません）、このルーティングルールを/etc/gitlab/gitlab.rbに追加する必要があります:

      sidekiq['routing_rules'] = [['*', 'default']]

  • GitLab 15.4で導入されたバグが原因で、Gitaly Cluster (Praefect)内の1つ以上のGitリポジトリが利用できない場合、影響を受けるGitaly Cluster (Praefect)内のすべてのプロジェクトまたはプロジェクトWikiリポジトリに対して、リポジトリチェックとGeoのレプリケーションおよび検証が停止します。このバグは、GitLab 15.9.0で変更をリバートすることにより修正されました。このバージョンにアップグレードする前に、「利用できない」リポジトリが存在しないか確認してください。詳細については、このバグのイシューを参照してください。

15.5.2

  • GitLab 15.4.0で、すべてのジョブをdefaultキューにルーティングするデフォルトのSidekiqルーティングルールが導入されました。キューセレクターを使用しているインスタンスでは、一部のSidekiqプロセスがアイドル状態になるため、このルールによってパフォーマンスの問題が発生します。

    • デフォルトのルーティングルールは15.5.4でリバートされたため、そのバージョン以降にアップグレードすると以前の動作に戻ります。

    • GitLabインスタンスがdefaultキューのみをリッスンしている場合（これは現在推奨されていません）、このルーティングルールを/etc/gitlab/gitlab.rbに追加する必要があります:

      sidekiq['routing_rules'] = [['*', 'default']]

  • GitLab 15.4で導入されたバグが原因で、Gitaly Cluster (Praefect)内の1つ以上のGitリポジトリが利用できない場合、影響を受けるGitaly Cluster (Praefect)内のすべてのプロジェクトまたはプロジェクトWikiリポジトリに対して、リポジトリチェックとGeoのレプリケーションおよび検証が停止します。このバグは、GitLab 15.9.0で変更をリバートすることにより修正されました。このバージョンにアップグレードする前に、「利用できない」リポジトリが存在しないか確認してください。詳細については、このバグのイシューを参照してください。

15.5.1

  • GitLab 15.4.0で、すべてのジョブをdefaultキューにルーティングするデフォルトのSidekiqルーティングルールが導入されました。キューセレクターを使用しているインスタンスでは、一部のSidekiqプロセスがアイドル状態になるため、このルールによってパフォーマンスの問題が発生します。

    • デフォルトのルーティングルールは15.5.4でリバートされたため、そのバージョン以降にアップグレードすると以前の動作に戻ります。

    • GitLabインスタンスがdefaultキューのみをリッスンしている場合（これは現在推奨されていません）、このルーティングルールを/etc/gitlab/gitlab.rbに追加する必要があります:

      sidekiq['routing_rules'] = [['*', 'default']]

  • GitLab 15.4で導入されたバグが原因で、Gitaly Cluster (Praefect)内の1つ以上のGitリポジトリが利用できない場合、影響を受けるGitaly Cluster (Praefect)内のすべてのプロジェクトまたはプロジェクトWikiリポジトリに対して、リポジトリチェックとGeoのレプリケーションおよび検証が停止します。このバグは、GitLab 15.9.0で変更をリバートすることにより修正されました。このバージョンにアップグレードする前に、「利用できない」リポジトリが存在しないか確認してください。詳細については、このバグのイシューを参照してください。

15.5.0

  • GitLab 15.4.0で、すべてのジョブをdefaultキューにルーティングするデフォルトのSidekiqルーティングルールが導入されました。キューセレクターを使用しているインスタンスでは、一部のSidekiqプロセスがアイドル状態になるため、このルールによってパフォーマンスの問題が発生します。

    • デフォルトのルーティングルールは15.5.4でリバートされたため、そのバージョン以降にアップグレードすると以前の動作に戻ります。

    • GitLabインスタンスがdefaultキューのみをリッスンしている場合（これは現在推奨されていません）、このルーティングルールを/etc/gitlab/gitlab.rbに追加する必要があります:

      sidekiq['routing_rules'] = [['*', 'default']]

  • GitLab 15.4で導入されたバグが原因で、Gitaly Cluster (Praefect)内の1つ以上のGitリポジトリが利用できない場合、影響を受けるGitaly Cluster (Praefect)内のすべてのプロジェクトまたはプロジェクトWikiリポジトリに対して、リポジトリチェックとGeoのレプリケーションおよび検証が停止します。このバグは、GitLab 15.9.0で変更をリバートすることにより修正されました。このバージョンにアップグレードする前に、「利用できない」リポジトリが存在しないか確認してください。詳細については、このバグのイシューを参照してください。

Geoインストール

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed
  • pg_upgradeが、バンドルされているPostregSQLデータベースをバージョン13にアップグレードできません。詳細と回避策については、こちらを参照してください。
  • セカンダリサイトからのLFSオブジェクトのクローン作成では、セカンダリが完全に同期されている場合でも、プライマリサイトからダウンロードされます。詳細と回避策については、こちらを参照してください。

15.4.6

15.4.5

15.4.4

15.4.3

15.4.2

  • ライセンスのキャッシュの問題により、新しいライセンスを追加した場合に、GitLabのPremium機能の一部が正しく動作しなくなることがあります。この問題の回避策は次のとおりです:
    • 新しいライセンスを適用した後、すべてのRails、Sidekiq、Gitalyノードを再起動します。これにより、関連するライセンスキャッシュがクリアされ、すべてのPremium機能が正しく動作するようになります。
    • この問題の影響を受けないバージョンにアップグレードします。影響を受けるバージョンからのアップグレードパスは次のとおりです:
      • 15.2.5 –> 15.3.5
      • 15.3.0 - 15.3.4 –> 15.3.5
      • 15.4.1 –> 15.4.3
  • GitLab 15.4で導入されたバグが原因で、Gitaly Cluster (Praefect)内の1つ以上のGitリポジトリが利用できない場合、影響を受けるGitaly Cluster (Praefect)内のすべてのプロジェクトまたはプロジェクトWikiリポジトリに対して、リポジトリチェックとGeoのレプリケーションおよび検証が停止します。このバグは、GitLab 15.9.0で変更をリバートすることにより修正されました。このバージョンにアップグレードする前に、「利用できない」リポジトリが存在しないか確認してください。詳細については、このバグのイシューを参照してください。

15.4.1

  • ライセンスのキャッシュの問題により、新しいライセンスを追加した場合に、GitLabのPremium機能の一部が正しく動作しなくなることがあります。この問題の回避策は次のとおりです:
    • 新しいライセンスを適用した後、すべてのRails、Sidekiq、Gitalyノードを再起動します。これにより、関連するライセンスキャッシュがクリアされ、すべてのPremium機能が正しく動作するようになります。
    • この問題の影響を受けないバージョンにアップグレードします。影響を受けるバージョンからのアップグレードパスは次のとおりです:
      • 15.2.5 –> 15.3.5
      • 15.3.0 - 15.3.4 –> 15.3.5
      • 15.4.1 –> 15.4.3
  • GitLab 15.4で導入されたバグが原因で、Gitaly Cluster (Praefect)内の1つ以上のGitリポジトリが利用できない場合、影響を受けるGitaly Cluster (Praefect)内のすべてのプロジェクトまたはプロジェクトWikiリポジトリに対して、リポジトリチェックとGeoのレプリケーションおよび検証が停止します。このバグは、GitLab 15.9.0で変更をリバートすることにより修正されました。このバージョンにアップグレードする前に、「利用できない」リポジトリが存在しないか確認してください。詳細については、このバグのイシューを参照してください。

15.4.0

  • GitLab 15.4.0には、ci_job_artifactsテーブルのexpire_atにある誤った値を削除するためのバッチバックグラウンド移行が含まれています。大規模なGitLabインスタンスでは、この移行が完了するまで数時間から数日かかる場合があります。

  • デフォルトでは、GitalyノードとPraefectノードは、pool.ntp.orgのタイムサーバーを使用します。インスタンスがpool.ntp.orgに接続できない場合は、NTP_HOST変数を設定してください。そうしないと、ログやgitlab-rake gitlab:gitaly:checkの出力にntp: read udp ... i/o timeoutエラーが記録される可能性があります。ただし、Gitalyホストの時刻が同期している場合は、これらのエラーは無視できます。

  • GitLab 15.4.0で、すべてのジョブをdefaultキューにルーティングするデフォルトのSidekiqルーティングルールが導入されました。キューセレクターを使用しているインスタンスでは、一部のSidekiqプロセスがアイドル状態になるため、このルールによってパフォーマンスの問題が発生します。

    • デフォルトのルーティングルールは15.4.5でリバートされたため、そのバージョン以降にアップグレードすると以前の動作に戻ります。

    • GitLabインスタンスがdefaultキューのみをリッスンしている場合（これは現在推奨されていません）、このルーティングルールを/etc/gitlab/gitlab.rbに追加する必要があります:

      sidekiq['routing_rules'] = [['*', 'default']]

  • GitLab 15.4で/etc/gitlab/gitlab-secrets.jsonの構造が変更され、gitlab_pages、grafana、mattermostセクションに新しい設定が追加されました。高可用性環境またはGitLab Geo環境では、すべてのノードでシークレットが同一である必要があります。シークレットファイルをノード間で手動同期している場合、または/etc/gitlab/gitlab.rbでシークレットを手動で指定している場合は、すべてのノードで/etc/gitlab/gitlab-secrets.jsonが同じであることを確認してください。

  • GitLab 15.4.0では、イシューテーブルのnamespace_id値をバックフィルするバッチバックグラウンド移行が導入されました。大規模なGitLabインスタンスでは、この移行が完了するまで数時間から数日かかる場合があります。15.7.0以降にアップグレードする前に、移行が正常に完了していることを確認してください。

  • GitLab 15.4で導入されたバグが原因で、Gitaly Cluster (Praefect)内の1つ以上のGitリポジトリが利用できない場合、影響を受けるGitaly Cluster (Praefect)内のすべてのプロジェクトまたはプロジェクトWikiリポジトリに対して、リポジトリチェックとGeoのレプリケーションおよび検証が停止します。このバグは、GitLab 15.9.0で変更をリバートすることにより修正されました。このバージョンにアップグレードする前に、「利用できない」リポジトリが存在しないか確認してください。詳細については、このバグのイシューを参照してください。

  • GitLab 15.4以降では、再設計されたサインインページがデフォルトで有効になっており、今後のリリースでさらに改善される予定です。詳細については、エピック8557を参照してください。この変更は、機能フラグで無効にできます。Railsコンソールを起動し、次のコマンドを実行します:

    Feature.disable(:restyle_login_page)

Geoインストール

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed
  • pg_upgradeが、バンドルされているPostregSQLデータベースをバージョン13にアップグレードできません。詳細と回避策については、こちらを参照してください。
  • セカンダリサイトからのLFSオブジェクトのクローン作成では、セカンダリが完全に同期されている場合でも、プライマリサイトからダウンロードされます。詳細と回避策については、こちらを参照してください。

15.3.4

ライセンスのキャッシュの問題により、新しいライセンスを追加した場合に、GitLabのPremium機能の一部が正しく動作しなくなることがあります。この問題の回避策は次のとおりです:

  • 新しいライセンスを適用した後、すべてのRails、Sidekiq、Gitalyノードを再起動します。これにより、関連するライセンスキャッシュがクリアされ、すべてのPremium機能が正しく動作するようになります。
  • この問題の影響を受けないバージョンにアップグレードします。影響を受けるバージョンからのアップグレードパスは次のとおりです:
    • 15.2.5 –> 15.3.5
    • 15.3.0 - 15.3.4 –> 15.3.5
    • 15.4.1 –> 15.4.3

15.3.3

  • GitLab 15.3.3では、SAMLグループリンクAPIのaccess_level属性の型がintegerに変更されました。APIドキュメントを参照してください。

  • ライセンスのキャッシュの問題により、新しいライセンスを追加した場合に、GitLabのPremium機能の一部が正しく動作しなくなることがあります。この問題の回避策は次のとおりです:

    • 新しいライセンスを適用した後、すべてのRails、Sidekiq、Gitalyノードを再起動します。これにより、関連するライセンスキャッシュがクリアされ、すべてのPremium機能が正しく動作するようになります。
    • この問題の影響を受けないバージョンにアップグレードします。影響を受けるバージョンからのアップグレードパスは次のとおりです:
      • 15.2.5 –> 15.3.5
      • 15.3.0 - 15.3.4 –> 15.3.5
      • 15.4.1 –> 15.4.3

15.3.2

ライセンスのキャッシュの問題により、新しいライセンスを追加した場合に、GitLabのPremium機能の一部が正しく動作しなくなることがあります。この問題の回避策は次のとおりです:

  • 新しいライセンスを適用した後、すべてのRails、Sidekiq、Gitalyノードを再起動します。これにより、関連するライセンスキャッシュがクリアされ、すべてのPremium機能が正しく動作するようになります。
  • この問題の影響を受けないバージョンにアップグレードします。影響を受けるバージョンからのアップグレードパスは次のとおりです:
    • 15.2.5 –> 15.3.5
    • 15.3.0 - 15.3.4 –> 15.3.5
    • 15.4.1 –> 15.4.3

15.3.1

ライセンスのキャッシュの問題により、新しいライセンスを追加した場合に、GitLabのPremium機能の一部が正しく動作しなくなることがあります。この問題の回避策は次のとおりです:

  • 新しいライセンスを適用した後、すべてのRails、Sidekiq、Gitalyノードを再起動します。これにより、関連するライセンスキャッシュがクリアされ、すべてのPremium機能が正しく動作するようになります。
  • この問題の影響を受けないバージョンにアップグレードします。影響を受けるバージョンからのアップグレードパスは次のとおりです:
    • 15.2.5 –> 15.3.5
    • 15.3.0 - 15.3.4 –> 15.3.5
    • 15.4.1 –> 15.4.3

15.3.0

  • Gitaly Cluster (Praefect)で新しく作成されたGitリポジトリは、@hashedストレージパスを使用しなくなりました。新しいリポジトリのサーバーフックは、別の場所にコピーする必要があります。Praefectは、Gitaly Clusterで使用するためのレプリカパスを生成するようになりました。この変更は、Gitaly Cluster (Praefect)がGitリポジトリをアトミックに作成、削除、名前変更できるようにするための前提条件です。

    レプリカパスを特定するには、Praefectリポジトリメタデータをクエリして、@hashedストレージパスを-relative-pathに渡します。

    この情報を使用すると、サーバーフックを正しくインストールできます。

  • ライセンスのキャッシュの問題により、新しいライセンスを追加した場合に、GitLabのPremium機能の一部が正しく動作しなくなることがあります。この問題の回避策は次のとおりです:

    • 新しいライセンスを適用した後、すべてのRails、Sidekiq、Gitalyノードを再起動します。これにより、関連するライセンスキャッシュがクリアされ、すべてのPremium機能が正しく動作するようになります。
    • この問題の影響を受けないバージョンにアップグレードします。影響を受けるバージョンからのアップグレードパスは次のとおりです:
      • 15.2.5 –> 15.3.5
      • 15.3.0 - 15.3.4 –> 15.3.5
      • 15.4.1 –> 15.4.3

Geoインストール

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

LFS転送がセッションの途中でセカンダリサイトからプライマリサイトにリダイレクトされる

影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
15.1すべてなし
15.2すべてなし
15.315.3.0 - 15.3.215.3.3以降

Geoプロキシが有効になっている場合、GitLab 15.1.0から15.3.2において、LFS転送がセッションの途中でセカンダリサイトからプライマリサイトにリダイレクトされ、プルリクエストやクローンリクエストが失敗することがあります。GitLab 15.1以降で、Geoプロキシはデフォルトで有効になっています。

この問題はGitLab 15.3.3で解決されているため、次の設定を使用している場合は15.3.3以降にアップグレードする必要があります:

  • LFSが有効になっている。
  • LFSオブジェクトがGeoサイト間でレプリケートされている。
  • リポジトリがGeoセカンダリサイト経由でプルされている。
  • セカンダリサイトからのLFSオブジェクトのクローン作成では、セカンダリが完全に同期されている場合でも、プライマリサイトからダウンロードされます。詳細と回避策については、こちらを参照してください。

セカンダリサイトでオブジェクトストレージ内のLFSファイルが誤って削除される

影響を受けるマイナーリリース影響を受けるパッチリリース修正リリース
15.0すべてなし
15.1すべてなし
15.2すべてなし
15.315.3.0 - 15.3.215.3.3以降

Geoセカンダリサイトでオブジェクトストレージファイルが誤って削除される問題は、GitLab 15.0.0から15.3.2において、次の状況で発生する可能性があります:

  • GitLab管理のオブジェクトストレージレプリケーションが無効になっており、オブジェクトストレージを有効にした状態でプロジェクトをインポートする際にLFSオブジェクトストレージが作成される場合。
  • オブジェクトストレージを同期するためのGitLab管理のレプリケーションを有効にした後、再び無効にした場合。

この問題は15.3.3で解決されました。LFSが有効になっており、LFSオブジェクトがGeoサイト間でレプリケートされている場合は、セカンダリサイトでのデータ損失リスクを軽減するために、15.3.3に直接アップグレードする必要があります。

15.2.5

ライセンスのキャッシュの問題により、新しいライセンスを追加した場合に、GitLabのPremium機能の一部が正しく動作しなくなることがあります。この問題の回避策は次のとおりです:

  • 新しいライセンスを適用した後、すべてのRails、Sidekiq、Gitalyノードを再起動します。これにより、関連するライセンスキャッシュがクリアされ、すべてのPremium機能が正しく動作するようになります。
  • この問題の影響を受けないバージョンにアップグレードします。影響を受けるバージョンからのアップグレードパスは次のとおりです:
    • 15.2.5 –> 15.3.5
    • 15.3.0 - 15.3.4 –> 15.3.5
    • 15.4.1 –> 15.4.3

15.2.0

  • ETagキーの生成に不整合を引き起こす可能性があるRailsの設定変更により、複数のWebノードがあるGitLabインストールでは、15.2（以降）にアップグレードする前に15.1にアップグレードする必要があります。

  • このリリースでは、一部のSidekiqワーカーの名前が変更されました。中断を避けるため、GitLab 15.2.0へのアップグレードを開始する前に、保留中のジョブを移行するためのRakeタスクを実行してください。

  • Gitalyはランタイムの配置場所でバイナリを実行するようになりました。Linuxパッケージインスタンスのデフォルトでは、このパスは/var/opt/gitlab/gitaly/run/です。noexecが指定されてこの場所がマウントされている場合、マージリクエストの際に次のエラーが発生します:

    fork/exec /var/opt/gitlab/gitaly/run/gitaly-<nnnn>/gitaly-git2go-v15: permission denied

    この問題を解決するには、ファイルシステムマウントからnoexecオプションを削除します。別の方法として、Gitalyのランタイムディレクトリを変更することもできます:

    1. /etc/gitlab/gitlab.rbにgitaly['runtime_dir'] = '<PATH_WITH_EXEC_PERM>'を追加し、noexecが設定されていない場所を指定します。
    2. sudo gitlab-ctl reconfigureを実行します。

Geoインストール

  • プラン: Premium、Ultimate
  • 提供形態: GitLab Self-Managed
  • pg_upgradeが、バンドルされているPostregSQLデータベースをバージョン13にアップグレードできません。詳細と回避策については、こちらを参照してください。
  • LFS転送がセッションの途中でセカンダリサイトからプライマリサイトにリダイレクトされる場合があります。詳細と回避策については、こちらを参照してください。
  • Geoセカンダリサイトで、オブジェクトストレージ内のLFSファイルが誤って削除される場合があります。詳細と回避策については、こちらを参照してください。
  • セカンダリサイトからのLFSオブジェクトのクローン作成では、セカンダリが完全に同期されている場合でも、プライマリサイトからダウンロードされます。詳細と回避策については、こちらを参照してください。

15.1.0

  • GitLab 15.1.0では、RailsのActiveSupport::DigestがMD5ではなくSHA256を使用するように切り替えました。この変更は、スニペットのrawファイルダウンロードなど、リソースに対するETagキーの生成に影響します。アップグレード時に複数のWebノード間で一貫したETagキーが生成されるようにするには、すべてのサーバーをまず15.1.6にアップグレードしてから、15.2.0以降にアップグレードする必要があります:

    1. すべてのGitLab WebノードがGitLab 15.1.6を実行していることを確認します。

    2. クラウドネイティブのGitLab Helmチャートを使用してKubernetes上でGitLabを実行している場合は、すべてのWebserviceポッドがGitLab 15.1.Zを実行していることを確認してください:

      kubectl get pods -l app=webservice -o custom-columns=webservice-image:{.spec.containers[0].image},workhorse-image:{.spec.containers[1].image}

    3. SHA256を使用するようにActiveSupport::Digestを切り替えるには、active_support_hash_digest_sha256機能フラグを有効にします:

      1. Railsコンソールを起動します

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

        Feature.enable(:active_support_hash_digest_sha256)

    4. これらの手順を完了した後にのみ、GitLabの後続バージョンへのアップグレードを続行します。

  • ciConfig GraphQLフィールドへの認証されていないリクエストはサポートされなくなりました。GitLab 15.1にアップグレードする前に、リクエストにアクセストークンを追加してください。トークンを作成するユーザーには、プロジェクトでパイプラインを作成する権限が必要です。

Geoインストール

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

15.0.0

  • Elasticsearch 6.8はサポートされなくなりました。GitLab 15.0にアップグレードする前に、Elasticsearchを7.xバージョンに更新してください。

  • 外部PostgreSQL、特にAWS RDSを使用してGitLabを実行している場合は、GitLab 14.8以降にアップグレードする前に、PostgreSQLを少なくとも12.7または13.3のパッチレベルにアップグレードしてください。

    GitLab Enterprise Editionの14.8およびGitLab Community Editionの15.0で、緩い外部キーというGitLabの機能フラグが有効になりました。

    この機能を有効にした後、セグメンテーションフォールトを引き起こすデータベースエンジンのバグが原因で、予期しないPostgreSQLの再起動が発生したという報告がありました。

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

  • background_uploadの使用のサポートが削除されたことに伴い、ストレージ固有の設定を使用する暗号化されたS3バケットの使用はサポートされなくなりました。

  • 証明書ベースのKubernetesインテグレーション（非推奨）はデフォルトで無効になっていますが、GitLab 16.0まではcertificate_based_clusters機能フラグを使用して再度有効にできます。

  • GitLab HelmチャートプロジェクトでカスタムのserviceAccountを使用する場合は、そのアカウントにserviceAccountおよびsecretリソースに対するgetおよびlist権限が付与されていることを確認してください。

  • FF_GITLAB_REGISTRY_HELPER_IMAGE機能フラグが削除され、ヘルパーイメージは常にGitLabレジストリからプルされるようになりました。

Linuxパッケージインストール

  • グローバルサーバーフックを設定するためのcustom_hooks_dir設定は、Gitalyで設定されるようになりました。これまでGitLab Shellで実装されていた設定は、GitLab 15.0で削除されました。この変更により、グローバルサーバーフックは、フックタイプにちなんで名付けられたサブディレクトリ内にのみ保存されるようになりました。グローバルサーバーフックを、カスタムフックディレクトリのルートに単一のフックファイルとして配置することはできなくなりました。たとえば、<custom_hooks_dir>/<hook_name>.d/*ではなく<custom_hooks_dir>/<hook_name>を使用する必要があります。

    • Linuxパッケージインスタンスの場合は、gitlab.rbでgitaly['custom_hooks_dir']を使用します。これは、gitlab_shell['custom_hooks_dir']を置き換えるものです。

  • PostgreSQL 13.6は、新規インストール時のデフォルトバージョンとして提供され、アップグレード時には12.10が使用されます。アップグレードドキュメントに従って、PostgreSQL 13.6に手動でアップグレードできます:

    sudo gitlab-ctl pg-upgrade -V 13

    PostgreSQL 12が削除されるまでは、互換性またはテスト環境の理由に応じて、PostgreSQLのバージョンを固定できます。

    耐障害性およびGeoインストールには、追加の手順と計画が必要です。

    基盤となる構造の変更により、PostgreSQLをアップグレードする際には、データベースの移行を実行する前に、実行中のPostgreSQLプロセスを再起動する必要があります。自動再起動をスキップした場合は、移行を実行する前に次のコマンドを実行する必要があります:

    # If using PostgreSQL
sudo gitlab-ctl restart postgresql

# If using Patroni for Database replication
sudo gitlab-ctl restart patroni

    PostgreSQLを再起動しないと、ライブラリの読み込みに関連するエラーが発生する可能性があります。

  • GitLab 15.0以降、PostgreSQLのバージョンが変更されると、postgresqlおよびgeo-postgresqlサービスが自動的に再起動されます。PostgreSQLサービスを再起動すると、データベース操作が一時的に利用できなくなるため、ダウンタイムが発生します。この再起動はデータベースサービスを正常に動作させるために必須ですが、PostgreSQLの再起動のタイミングをより細かく制御したい場合があります。その場合は、gitlab-ctl reconfigureに含まれる自動再起動をスキップし、サービスを手動で再起動できます。

    GitLab 15.0へのアップグレード時に自動再起動をスキップするには、アップグレードの前に次の手順を実行します:

    1. /etc/gitlab/gitlab.rbを編集し、次の行を追加します:

      # For PostgreSQL/Patroni
postgresql['auto_restart_on_version_change'] = false

# For Geo PostgreSQL
geo_postgresql['auto_restart_on_version_change'] = false

    2. GitLabを再設定します:

      sudo gitlab-ctl reconfigure

    基盤となるPostgreSQLのバージョンを変更した場合は、必要なライブラリの読み込みに関するエラーなど、ダウンタイムを引き起こす可能性のある問題を回避するために、PostgreSQLの再起動は必須です。そのため、前述の方法で自動再起動をスキップする場合は、GitLab 15.0にアップグレードする前にサービスを手動で再起動してください。

  • GitLab 15.0以降、NGINXにおいてAES256-GCM-SHA384 SSL暗号がデフォルトで許可されなくなります。AWS Classic Load Balancerを使用しており、この暗号が必要な場合は、許可リストに追加できます。SSL暗号を許可リストに追加するには、次の手順に従います。

    1. /etc/gitlab/gitlab.rbを編集し、次の行を追加します:

      nginx['ssl_ciphers'] = "ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:AES256-GCM-SHA384"

    2. GitLabを再設定します:

      sudo gitlab-ctl reconfigure

  • Gitalyの内部ソケットパスのサポートは削除されました。GitLab 14.10では、Gitalyが正しく動作するために必要なすべてのランタイムデータを保持する新しいディレクトリが導入されました。この新しいディレクトリは、従来の内部ソケットディレクトリを置き換えるものです。それに伴い、gitaly['internal_socket_dir']の使用は非推奨となり、代わりにgitaly['runtime_dir']が使用されるようになりました。

    今回のリリースで、古いgitaly['internal_socket_dir']設定が削除されました。

  • オブジェクトストレージに関するバックグラウンドアップロード設定が削除されました。オブジェクトストレージは今後、直接アップロードを優先的に使用します。

    /etc/gitlab/gitlab.rbで、次のキーはサポートされなくなりました:

    • gitlab_rails['artifacts_object_store_direct_upload']
    • gitlab_rails['artifacts_object_store_background_upload']
    • gitlab_rails['external_diffs_object_store_direct_upload']
    • gitlab_rails['external_diffs_object_store_background_upload']
    • gitlab_rails['lfs_object_store_direct_upload']
    • gitlab_rails['lfs_object_store_background_upload']
    • gitlab_rails['uploads_object_store_direct_upload']
    • gitlab_rails['uploads_object_store_background_upload']
    • gitlab_rails['packages_object_store_direct_upload']
    • gitlab_rails['packages_object_store_background_upload']
    • gitlab_rails['dependency_proxy_object_store_direct_upload']
    • gitlab_rails['dependency_proxy_object_store_background_upload']

自己コンパイルによるインストール

  • GitLabでは、複数のデータベースをサポートするようになりました。自己コンパイル（ソース）によるインストールの場合、config/database.ymlのデータベース設定にデータベース名を含める必要があります。main: databaseを最初に定義しなくてはなりません。無効または非推奨の構文を使用すると、アプリケーションの起動時にエラーが発生します:

    ERROR: This installation of GitLab uses unsupported 'config/database.yml'.
The main: database needs to be defined as a first configuration item instead of primary. (RuntimeError)

    以前のconfig/database.ymlファイルは次のようになっていました:

    production:
  adapter: postgresql
  encoding: unicode
  database: gitlabhq_production
  ...

    GitLab 15.0以降では、まずmainデータベースを定義する必要があります:

    production:
  main:
    adapter: postgresql
    encoding: unicode
    database: gitlabhq_production
    ...

Geoインストール

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