GitLab 15 の変更点

このPagesにはGitLab 15のマイナーバージョンとパッチバージョンのアップグレード情報が記載されています。現在のバージョンとターゲットバージョンの間にあるすべてのバージョンについて、これらの説明をレビューしてください。

GitLab Helm Chartのアップグレードについては、6.0のリリースノートをご覧ください。

15.11.1

15.11.0

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

Geo インストール

  • 一部のプロジェクトのインポートで、プロジェクト作成時に Wiki リポジトリが初期化されません。詳細と回避策をご覧ください。
  • pg_upgrade バンドルされている PostregSQL データベースをバージョン 13 にアップグレードできませんでした。詳細と回避策を参照してください。

15.11.x

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

15.10.5

  • Elastic Indexer Cron Workersのバグにより、Sidekiqが飽和状態になる可能性があります。
    • このイシューが発生すると、マージリクエストのマージ、パイプライン、Slack通知、その他のイベントが作成されなかったり、発生までに時間がかかったりします。
    • Sidekiqが十分に飽和するまでに1週間かかることもあるため、このイシューはすぐには現れないかもしれません。
    • この問題が発生するためにElasticsearchを有効にする必要はありません。
    • この問題を解決するには、15.11にアップグレードするか、イシューの回避策を使用してください。
  • 多くのプロジェクトインポーターと グループインポーターで、これまで開発者ロールだけが必要だった代わりにメンテナー・ロールが必要になりました。詳細については、使用するインポートのドキュメントを参照してください。

15.10.0

  • Elastic Indexer Cron Workersのバグにより、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にアップグレードすることを検討してください。
  • Gitaly設定はOmnibus GitLab 16.0で大きく変わります。Omnibus GitLab 16.0までの後方互換性が維持されている間は、Omnibus 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をご覧ください。

Geo インストール

  • pg_upgrade バンドルされている PostregSQL データベースをバージョン 13 にアップグレードできませんでした。詳細と回避策を参照してください。

15.9.0

  • Elastic Indexer Cron Workersのバグにより、Sidekiqが飽和状態になる可能性があります。
    • このイシューが発生すると、マージリクエストのマージ、パイプライン、Slack通知、その他のイベントが作成されなかったり、発生までに時間がかかったりします。
    • Sidekiqが十分に飽和するまでに1週間かかることもあるため、このイシューはすぐには現れないかもしれません。
    • この問題が発生するためにElasticsearchを有効にする必要はありません。
    • この問題を解決するには、15.11にアップグレードするか、イシューの回避策を使用してください。
  • パッチリリース 15.9.3 以降にアップグレードしてください。これにより、2つのデータベースマイグレーションに関するバグが修正されました：
  • CI パーティショニングの一環として、ci_builds_needsに新しい外部キーが追加されました。大きなCIテーブルを持つGitLabインスタンスでは、この制約の追加に通常よりも時間がかかることがあります。

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

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

    状態管理ロジックに過去にイシューがあったため、データベースに無効なメタデータレコードが存在する可能性があります。たとえば、リポジトリの削除が不完全であったり、名前の変更が部分的に完了していたりすることが原因です。ベリファイアは、影響を受けるリポジトリの古いレプリカレコードを削除します。これらのリポジトリは、レプリカ・レコードが削除されたために、メトリクスおよびpraefect dataloss サブコマンドで使用できないリポジトリとして表示されることがあります。このようなリポジトリに遭遇した場合は、praefect remove-repository を使用してリポジトリを削除し、リポジトリの残りのレコードを削除してください。

    GitLab 15.0以降では、検証者が出力したログレコードを検索することで、それ以前に無効なメタデータレコードを持つリポジトリを見つけることができます。リポジトリの検証についての詳細と、ログエントリーの例をご覧ください。

  • Omnibus GitLab 16.0では、Praefectの設定が大幅に変更されます。Omnibus GitLab 16.0までの後方互換性を維持しながら、Omnibus GitLab 15.9で新しい構成へのマイグレーションを開始できます。この変更についてもっと読む

セルフコンパイルによるインストール

  • セルフコンパイル（ソース）によるインストールでは、gitlab-sshd 、GitLab ShellをビルドするためにKerberosヘッダーが必要になります。

     sudo apt install libkrb5-dev

Geo インストール

  • pg_upgrade バンドルされている PostregSQL データベースをバージョン 13 にアップグレードできませんでした。詳細と回避策を参照してください。

15.8.2

Geo インストール

  • 少数の Geo インストールにおいて、プロジェクトと Wiki のレプリケーションと検証が追いつかないというイシューが発見されました。いくつかのプロジェクトや Wiki が検証のために “Queued” 状態で持続している場合、インストールに影響が出る可能性があります。これはフェイルオーバー後のデータ損失につながる可能性があります。
    • 影響を受けるバージョンGitLab バージョン 15.6.x、15.7.x、15.8.0 - 15.8.2.
    • 修正を含むバージョン：GitLab 15.8.3 以降。

15.8.1

Geo インストール

  • 少数の Geo インストールにおいて、プロジェクトと Wiki のレプリケーションと検証が追いつかないというイシューが発見されました。いくつかのプロジェクトや Wiki が検証のために “Queued” 状態で持続している場合、インストールに影響が出る可能性があります。これはフェイルオーバー後のデータ損失につながる可能性があります。
    • 影響を受けるバージョンGitLab バージョン 15.6.x、15.7.x、15.8.0 - 15.8.2.
    • 修正を含むバージョン：GitLab 15.8.3 以降。

15.8.0

Geo インストール

  • pg_upgrade バンドルされている PostregSQL データベースをバージョン 13 にアップグレードしようとすると失敗します。詳細と回避策を参照してください。
  • 少数の Geo インストールにおいて、プロジェクトと Wiki のレプリケーションと検証が追いつかないというイシューが発見されました。いくつかのプロジェクトや Wiki が検証のために “Queued” 状態で持続している場合、インストールに影響が出る可能性があります。これはフェイルオーバー後のデータ損失につながる可能性があります。
    • 影響を受けるバージョンGitLab バージョン 15.6.x、15.7.x、15.8.0 - 15.8.2.
    • 修正を含むバージョン：GitLab 15.8.3 以降。

15.7.6

Geo インストール

  • 少数の Geo インストールにおいて、プロジェクトと Wiki のレプリケーションと検証が追いつかないというイシューが発見されました。いくつかのプロジェクトや Wiki が検証のために “Queued” 状態で持続している場合、インストールに影響が出る可能性があります。これはフェイルオーバー後のデータ損失につながる可能性があります。
    • 影響を受けるバージョンGitLab バージョン 15.6.x、15.7.x、15.8.0 - 15.8.2.
    • 修正を含むバージョン：GitLab 15.8.3 以降。

15.7.5

Geo インストール

  • 少数の Geo インストールにおいて、プロジェクトと Wiki のレプリケーションと検証が追いつかないというイシューが発見されました。いくつかのプロジェクトや Wiki が検証のために “Queued” 状態で持続している場合、インストールに影響が出る可能性があります。これはフェイルオーバー後のデータ損失につながる可能性があります。
    • 影響を受けるバージョンGitLab バージョン 15.6.x、15.7.x、15.8.0 - 15.8.2.
    • 修正を含むバージョン：GitLab 15.8.3 以降。

15.7.4

Geo インストール

  • 少数の Geo インストールにおいて、プロジェクトと Wiki のレプリケーションと検証が追いつかないというイシューが発見されました。いくつかのプロジェクトや Wiki が検証のために “Queued” 状態で持続している場合、インストールに影響が出る可能性があります。これはフェイルオーバー後のデータ損失につながる可能性があります。
    • 影響を受けるバージョンGitLab バージョン 15.6.x、15.7.x、15.8.0 - 15.8.2.
    • 修正を含むバージョン：GitLab 15.8.3 以降。

15.7.3

Geo インストール

  • 少数の Geo インストールにおいて、プロジェクトと Wiki のレプリケーションと検証が追いつかないというイシューが発見されました。いくつかのプロジェクトや Wiki が検証のために “Queued” 状態で持続している場合、インストールに影響が出る可能性があります。これはフェイルオーバー後のデータ損失につながる可能性があります。
    • 影響を受けるバージョンGitLab バージョン 15.6.x、15.7.x、15.8.0 - 15.8.2.
    • 修正を含むバージョン：GitLab 15.8.3 以降。

15.7.2

Geo インストール

  • コンテナレジストリのプッシュイベントが/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 が検証のために “Queued” 状態で持続している場合、インストールに影響が出る可能性があります。これはフェイルオーバー後のデータ損失につながる可能性があります。
    • 影響を受けるバージョンGitLab バージョン 15.6.x、15.7.x、15.8.0 - 15.8.2.
    • 修正を含むバージョン：GitLab 15.8.3 以降。

15.7.1

Geo インストール

  • コンテナレジストリのプッシュイベントが/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 が検証のために “Queued” 状態で持続している場合、インストールに影響が出る可能性があります。これはフェイルオーバー後のデータ損失につながる可能性があります。
    • 影響を受けるバージョン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 テーブルにNULL work_item_type_id を持つレコードが存在してはなりません。EnsureWorkItemTypeBackfillMigrationFinished デプロイ後のマイグレーションで最終的に行われるBackfillWorkItemTypeIdForIssues バックグラウンドマイグレーションが複数あります。
  • 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:

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

  • デフォルトのSidekiqmax_concurrency は20に変更されました。これは、当社のドキュメントと製品のデフォルトで一貫しています。

    例えば、以前は

    • Linux パッケージインストールのデフォルト (sidekiq['max_concurrency'])：50
    • セルフコンパイルインストールのデフォルト: 50
    • Helm チャートのデフォルト (gitlab.sidekiq.concurrency)：25

    リファレンスアーキテクチャでは、これらの設定用に特別に設定されているため、デフォルトの10を使用しています。

    max_concurrency を設定しているサイトは、この変更の影響を受けません。Sidekiqの同時実行設定の詳細をお読みください。

  • GitLab Runner 15.7.0はCI/CDジョブに影響するブレークチェンジを導入しました：ジョブファイル変数の展開を正しく扱うようになりました。これまで、ファイル型変数を参照するジョブ定義変数は、ファイル変数の値（その内容）に展開されていました。この動作はシェル変数展開の典型的なルールを尊重していませんでした。また、ファイル変数とその内容が出力されると、シークレット情報や機密情報が漏れる可能性がありました。例えば、エコー出力で表示された場合などです。詳しくは、GitLab 15.7のファイル型変数展開の変更についてを参照してください。
  • GitLab 15.4で導入されたバグのため、Gitaly Clusterの1つ以上のGitリポジトリが利用できない場合、影響を受けるGitaly ClusterのすべてのプロジェクトまたはプロジェクトWikiリポジトリのリポジトリチェックと Geoレプリケーションと検証が実行されなくなります。このバグはGitLab 15.9.0の変更を戻すことで修正されました。このバージョンにアップグレードする前に、「利用できない」リポジトリがあるかどうか確認してください。詳しくはバグイシューをご覧ください。

Geo インストール

  • 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 が検証のために “Queued” 状態で持続している場合、インストールに影響が出る可能性があります。これはフェイルオーバー後のデータ損失につながる可能性があります。
    • 影響を受けるバージョンGitLab バージョン 15.6.x、15.7.x、15.8.0 - 15.8.2.
    • 修正を含むバージョン：GitLab 15.8.3 以降。

15.6.7

Geo インストール

  • 少数の Geo インストールにおいて、プロジェクトと Wiki のレプリケーションと検証が追いつかないというイシューが発見されました。いくつかのプロジェクトや Wiki が検証のために “Queued” 状態で持続している場合、インストールに影響が出る可能性があります。これはフェイルオーバー後のデータ損失につながる可能性があります。
    • 影響を受けるバージョンGitLab バージョン 15.6.x、15.7.x、15.8.0 - 15.8.2.
    • 修正を含むバージョン：GitLab 15.8.3 以降。

15.6.6

Geo インストール

  • コンテナレジストリのプッシュイベントが/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 が検証のために “Queued” 状態で持続している場合、インストールに影響が出る可能性があります。これはフェイルオーバー後のデータ損失につながる可能性があります。
    • 影響を受けるバージョンGitLab バージョン 15.6.x、15.7.x、15.8.0 - 15.8.2.
    • 修正を含むバージョン：GitLab 15.8.3 以降。

15.6.5

Geo インストール

  • コンテナレジストリのプッシュイベントが/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 が検証のために “Queued” 状態で持続している場合、インストールに影響が出る可能性があります。これはフェイルオーバー後のデータ損失につながる可能性があります。
    • 影響を受けるバージョンGitLab バージョン 15.6.x、15.7.x、15.8.0 - 15.8.2.
    • 修正を含むバージョン：GitLab 15.8.3 以降。
  • GitLab 15.4で導入されたバグのため、Gitaly Clusterの1つ以上のGitリポジトリが利用できない場合、影響を受けるGitaly ClusterのすべてのプロジェクトまたはプロジェクトWikiリポジトリのリポジトリチェックと Geoレプリケーションと検証が実行されなくなります。このバグはGitLab 15.9.0の変更を戻すことで修正されました。このバージョンにアップグレードする前に、「利用できない」リポジトリがあるかどうか確認してください。詳しくはバグイシューをご覧ください。

15.6.4

Geo インストール

  • コンテナレジストリのプッシュイベントが/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 が検証のために “Queued” 状態で持続している場合、インストールに影響が出る可能性があります。これはフェイルオーバー後のデータ損失につながる可能性があります。
    • 影響を受けるバージョンGitLab バージョン 15.6.x、15.7.x、15.8.0 - 15.8.2.
    • 修正を含むバージョン：GitLab 15.8.3 以降。
  • GitLab 15.4で導入されたバグのため、Gitaly Clusterの1つ以上のGitリポジトリが利用できない場合、影響を受けるGitaly ClusterのすべてのプロジェクトまたはプロジェクトWikiリポジトリのリポジトリチェックと Geoレプリケーションと検証が実行されなくなります。このバグはGitLab 15.9.0の変更を戻すことで修正されました。このバージョンにアップグレードする前に、「利用できない」リポジトリがあるかどうか確認してください。詳しくはバグイシューをご覧ください。

15.6.3

Geo インストール

  • コンテナレジストリのプッシュイベントが/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 が検証のために “Queued” 状態で持続している場合、インストールに影響が出る可能性があります。これはフェイルオーバー後のデータ損失につながる可能性があります。
    • 影響を受けるバージョンGitLab バージョン 15.6.x、15.7.x、15.8.0 - 15.8.2.
    • 修正を含むバージョン：GitLab 15.8.3 以降。
  • GitLab 15.4で導入されたバグのため、Gitaly Clusterの1つ以上のGitリポジトリが利用できない場合、影響を受けるGitaly ClusterのすべてのプロジェクトまたはプロジェクトWikiリポジトリのリポジトリチェックと Geoレプリケーションと検証が実行されなくなります。このバグはGitLab 15.9.0の変更を戻すことで修正されました。このバージョンにアップグレードする前に、「利用できない」リポジトリがあるかどうか確認してください。詳しくはバグイシューをご覧ください。

15.6.2

Geo インストール

  • コンテナレジストリのプッシュイベントが/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 が検証のために “Queued” 状態で持続している場合、インストールに影響が出る可能性があります。これはフェイルオーバー後のデータ損失につながる可能性があります。
    • 影響を受けるバージョンGitLab バージョン 15.6.x、15.7.x、15.8.0 - 15.8.2.
    • 修正を含むバージョン：GitLab 15.8.3 以降。
  • GitLab 15.4で導入されたバグのため、Gitaly Clusterの1つ以上のGitリポジトリが利用できない場合、影響を受けるGitaly ClusterのすべてのプロジェクトまたはプロジェクトWikiリポジトリのリポジトリチェックと Geoレプリケーションと検証が実行されなくなります。このバグはGitLab 15.9.0の変更を戻すことで修正されました。このバージョンにアップグレードする前に、「利用できない」リポジトリがあるかどうか確認してください。詳しくはバグイシューをご覧ください。

15.6.1

Geo インストール

  • コンテナレジストリのプッシュイベントが/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 が検証のために “Queued” 状態で持続している場合、インストールに影響が出る可能性があります。これはフェイルオーバー後のデータ損失につながる可能性があります。
    • 影響を受けるバージョンGitLab バージョン 15.6.x、15.7.x、15.8.0 - 15.8.2.
    • 修正を含むバージョン：GitLab 15.8.3 以降。
  • GitLab 15.4で導入されたバグのため、Gitaly Clusterの1つ以上のGitリポジトリが利用できない場合、影響を受けるGitaly Clusterのすべてのプロジェクトまたはプロジェクト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にバックポートされました。このイシューは回避することもできます:これらのインデックスの作成方法をお読みください。

Geo インストール

  • 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 が検証のために “Queued” 状態で持続している場合、インストールに影響が出る可能性があります。これはフェイルオーバー後のデータ損失につながる可能性があります。
    • 影響を受けるバージョンGitLab バージョン 15.6.x、15.7.x、15.8.0 - 15.8.2.
    • 修正を含むバージョン：GitLab 15.8.3 以降。
  • GitLab 15.4で導入されたバグのため、Gitaly Clusterの1つ以上のGitリポジトリが利用できない場合、影響を受けるGitaly ClusterのすべてのプロジェクトまたはプロジェクトWikiリポジトリのリポジトリチェックと Geoレプリケーションと検証が実行されなくなります。このバグはGitLab 15.9.0の変更を戻すことで修正されました。このバージョンにアップグレードする前に、「利用できない」リポジトリがあるかどうか確認してください。詳しくはバグイシューをご覧ください。

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の1つ以上のGitリポジトリが利用できない場合、影響を受けるGitaly Clusterのすべてのプロジェクトまたはプロジェクト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の1つ以上のGitリポジトリが利用できない場合、影響を受けるGitaly Clusterのすべてのプロジェクトまたはプロジェクト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の1つ以上のGitリポジトリが利用できない場合、影響を受けるGitaly Clusterのすべてのプロジェクトまたはプロジェクト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の1つ以上のGitリポジトリが利用できない場合、影響を受けるGitaly ClusterのすべてのプロジェクトまたはプロジェクトWikiリポジトリのリポジトリチェックと Geoレプリケーションと検証が実行されなくなります。このバグはGitLab 15.9.0の変更を戻すことで修正されました。このバージョンにアップグレードする前に、「利用できない」リポジトリがあるかどうか確認してください。詳しくはバグイシューをご覧ください。

Geo インストール

  • pg_upgrade バンドルされている PostregSQL データベースをバージョン 13 にアップグレードできませんでした。詳細と回避策を参照してください。

15.4.6

15.4.5

15.4.4

15.4.3

15.4.2

  • ライセンスキャッシュのイシューにより、新しいライセンスを追加した場合、GitLabの一部のプレミアム機能が正しく動作しません。このイシューに対する回避策：
    • 新しいライセンスを適用したら、すべての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の1つ以上のGitリポジトリが利用できない場合、影響を受けるGitaly ClusterのすべてのプロジェクトまたはプロジェクトWikiリポジトリのリポジトリチェックと Geoレプリケーションと検証が実行されなくなります。このバグはGitLab 15.9.0の変更を戻すことで修正されました。このバージョンにアップグレードする前に、「利用できない」リポジトリがあるかどうか確認してください。詳しくはバグイシューをご覧ください。

15.4.1

  • ライセンスキャッシュのイシューにより、新しいライセンスを追加した場合、GitLabの一部のプレミアム機能が正しく動作しません。このイシューに対する回避策：
    • 新しいライセンスを適用したら、すべての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の1つ以上のGitリポジトリが利用できない場合、影響を受けるGitaly Clusterのすべてのプロジェクトまたはプロジェクト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.orgNET のタイムサーバーを使用します。pool.ntp.orgに接続できない場合は pool.ntp.org、 NTP_HOST 変数 を設定します。
  • GitLab 15.4.0では、全てのジョブをdefault キューにルーティングするデフォルトのSidekiqルーティングルールを導入しました。キューセレクタを使用しているインスタンスでは、Sidekiqプロセスの一部がアイドル状態になるため、パフォーマンスの問題が発生します。
    • デフォルトのルーティングルールは15.4.5で戻されたため、このバージョン以降にアップグレードすると以前の動作に戻ります。

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

       sidekiq['routing_rules'] = [['*', 'default']]
  • Gitaly クラスターで作成された新しい Git リポジトリは、@hashed ストレージパスを使用しなくなりました。新しいリポジトリのサーバーフックは、別の場所にコピーする必要があります。
  • 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の1つ以上のGitリポジトリが利用できない場合、影響を受けるGitaly ClusterのすべてのプロジェクトまたはプロジェクトWikiリポジトリのリポジトリチェックと Geoレプリケーションと検証が実行されなくなります。このバグはGitLab 15.9.0の変更を戻すことで修正されました。このバージョンにアップグレードする前に、「利用できない」リポジトリがあるかどうか確認してください。詳しくはバグイシューをご覧ください。

  • GitLab 15.4以降では、デザインの変更されたサインインページがデフォルトで有効になっています。詳しくは、エピック 8557 をご覧ください。機能フラグで無効にすることもできます。Railsコンソールを起動して実行します：

     Feature.disable(:restyle_login_page)

Geo インストール

  • pg_upgrade バンドルされている PostregSQL データベースをバージョン 13 にアップグレードできませんでした。詳細と回避策を参照してください。

15.3.4

ライセンスキャッシュのイシューにより、新しいライセンスを追加した場合、GitLabの一部のプレミアム機能が正しく動作しません。このイシューに対する回避策：

  • 新しいライセンスを適用したら、すべての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 Group LinksAPIaccess_level 属性タイプがintegerに変更されました。API ドキュメントを参照してください。

  • ライセンスキャッシュのイシューにより、新しいライセンスを追加した場合、GitLabの一部のプレミアム機能が正しく動作しません。このイシューに対する回避策：

    • 新しいライセンスを適用したら、すべての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の一部のプレミアム機能が正しく動作しません。このイシューに対する回避策：

  • 新しいライセンスを適用したら、すべての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の一部のプレミアム機能が正しく動作しません。このイシューに対する回避策：

  • 新しいライセンスを適用したら、すべての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 クラスターで作成された新しい Git リポジトリは、@hashed ストレージパスを使用しなくなりました。新しいリポジトリのサーバーフックは、別の場所にコピーする必要があります。

  • ライセンスキャッシュのイシューにより、新しいライセンスを追加した場合、GitLabの一部のプレミアム機能が正しく動作しません。このイシューに対する回避策：

    • 新しいライセンスを適用したら、すべての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 インストール

  • pg_upgrade バンドルされている PostregSQL データベースをバージョン 13 にアップグレードできませんでした。詳細と回避策を参照してください。
  • LFS 転送がセッションの途中でセカンダリサイトからプライマリサイトにリダイレクトされることがあります。詳細と回避策を参照してください。
  • Geo セカンダリ サイトでのオブジェクト ストレージ LFS ファイルの削除が正しくない。詳細と回避策を参照してください。

15.2.5

ライセンスキャッシュのイシューにより、新しいライセンスを追加した場合、GitLabの一部のプレミアム機能が正しく動作しません。このイシューに対する回避策：

  • 新しいライセンスを適用したら、すべての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

  • 複数の Web ノードを持つ GitLab インストールは、15.2 (およびそれ以降) にアップグレードする前に15.1 にアップグレードする必要があります。
  • このリリースでは、一部のSidekiqワーカーの名前が変更されました。混乱を避けるため、GitLab 15.2.0へのアップグレードを開始する前に、保留中のジョブをマイグレーションするRakeタスクを実行してください。

  • Gitalyはバイナリをランタイムの場所で実行するようになりました。Omnibus GitLabのデフォルトでは、このパスは/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 インストール

  • pg_upgrade バンドルされている PostregSQL データベースをバージョン 13 にアップグレードできませんでした。詳細と回避策を参照してください。
  • LFS 転送がセッションの途中でセカンダリサイトからプライマリサイトにリダイレクトされることがあります。詳細と回避策を参照してください。
  • Geo セカンダリ サイトでのオブジェクト ストレージ LFS ファイルの削除が正しくない。詳細と回避策を参照してください。

15.1.0

  • 外部のPostgreSQL、特にAWS RDSを実行している場合は、データベースがクラッシュしないようにPostgreSQLのバグフィックスを行っているか確認してください。

  • GitLab 15.1.0では、RailsActiveSupport::Digest 、MD5の代わりにSHA256を使うように変更しています。これは、生のスニペットファイルのダウンロードなどのリソースのETagキー生成に影響します。アップグレード時に複数のウェブノードで一貫したETagキー生成を保証するために、15.2.0以降にアップグレードする前に、まずすべてのサーバを15.1.6にアップグレードする必要があります：

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

    2. クラウドネイティブのGitLab Helmチャートを使用してKubernetes上でGitLabを実行する場合は、すべてのウェブサービスポッドが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. active_support_hash_digest_sha256 機能フラグ を有効にして、ActiveSupport::Digest が SHA256 を使用するように切り替えます：

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

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

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

Geo インストール

15.0.0

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

  • グローバルサーバーフックを設定するためのcustom_hooks_dir の設定がGitalyで設定できるようになりました。以前のGitLab Shellでの実装はGitLab 15.0で削除されました。この変更により、グローバルサーバーフックはフックタイプにちなんだサブディレクトリ内にのみ保存されます。グローバルサーバーフックは、カスタムフックディレクトリのルートにある単一のフックファイルではなくなりました。例えば、<custom_hooks_dir>/<hook_name> ではなく<custom_hooks_dir>/<hook_name>.d/* を使用しなければなりません。
    • Omnibus GitLabには、gitlab.rb (14.3で導入) のgitaly['custom_hooks_dir'] を使用してください。これはgitlab_shell['custom_hooks_dir'] を置き換えるものです。

セルフコンパイルによるインストール

  • 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 インストール

  • Geo セカンダリ サイトでのオブジェクト ストレージ LFS ファイルの削除が正しくない。詳細と回避策を参照してください。

複数のバージョンに影響するイシュー

以下のイシューは複数のバージョンに影響します。表を参照して、どのバージョンにアップグレードすべきかを確認してください。

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

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

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

このイシューはGitLab 15.3.3で解決されていますので、以下の設定のお客様は15.3.3以降にアップグレードしてください：

  • LFS が有効になっています。
  • LFS オブジェクトが Geo サイト間でレプリケートされています。
  • リポジトリは、Geo セカンダリサイトを使用してプルされています。

Geo：セカンダリサイトでのオブジェクトストレージ 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 に直接アップグレードしてください。

Geo：プロジェクト作成時に初期化されない Wiki リポジトリ

影響を受けるマイナーリリース影響を受けるパッチリリース修正内容
15.11全てなし
16.0全てなし
16.116.1.0 - 16.1.216.1.3以降

いくつかのプロジェクトインポートはプロジェクト作成時にWikiリポジトリを初期化しません。プロジェクトWikiのSSFへのマイグレーション以降、見つからないWikiリポジトリは検証失敗として誤ってフラグが立てられます。これは実際のレプリケーション/検証の失敗の結果ではなく、Geo内部でこれらの欠落したリポジトリの内部状態が無効であり、ログや検証の進捗でこれらのWikiリポジトリの失敗状態を報告するエラーになります。プロジェクトをインポートしていない場合は、このイシューの影響を受けません。

Geo: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以降にアップグレードできない場合は手動による回避策があります。