极狐GitLab 15 变更

本页面包含极狐GitLab 15 的小版本和补丁版本的升级信息。确保您查看这些说明以进行：

  • 您的安装类型。
  • 当前版本和目标版本之间的所有版本。

有关升级极狐GitLab Helm Chart 的更多信息，请参阅 6.0 的发布说明。

15.11.1

  • 许多 项目导入器 和 组导入器 现在需要维护者角色，而不是仅仅需要开发者角色。有关更多信息，请参阅您使用的任何导入器的文档。

15.11.0

  • 升级到补丁版本 15.11.3 或更高版本。这可以避免从 15.5.0 及更早版本升级时遇到的问题。

  • 通常情况下，在具有 PgBouncer 的环境中备份必须通过 设置带有 GITLAB_BACKUP_ 前缀的变量来绕过 PgBouncer。然而，由于一个已知问题，gitlab-backup 使用通过 PgBouncer 的常规数据库连接，而不是覆盖中定义的直接连接，导致数据库备份失败。解决方法是直接使用 pg_dump。

    受影响的版本：

    受影响的小版本 受影响的补丁版本 修复于
    15.11 All None
    16.0 All None
    16.1 All None
    16.2 All None
    16.3 All None
    16.4 All None
    16.5 All None
    16.6 All None
    16.7 16.7.0 - 16.7.6 16.7.7
    16.8 16.8.0 - 16.8.3 16.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 安装

DETAILS:
Tier: 专业版，旗舰版
Offering: 私有化部署

pg_upgrade 无法将捆绑的 PostregSQL 数据库升级到版本 13

受影响的小版本 受影响的补丁版本 修复于
15.2 - 15.10 All None
15.11 15.11.0 - 15.11.11 15.11.12 及更高版本

内置的 pg-upgrade 工具中的一个 bug 阻止将捆绑的 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 或更高版本，该 bug 已得到修复。

15.10.5

  • 一个 Elastic Indexer Cron Workers 的 bug 可能导致 Sidekiq 饱和。
    • 当此问题发生时，合并请求合并、流水线、Slack 通知和其他事件未被创建或需要很长时间才能发生。
    • 此问题可能不会立即显现，因为可能需要长达一周的时间，Sidekiq 才会饱和。
    • 不需要启用 Elasticsearch 即可发生此问题。
    • 为了解决此问题，请升级到 15.11 或使用问题中的解决方法。
  • 许多 项目导入器 和 组导入器 现在需要维护者角色，而不是仅仅需要开发者角色。有关更多信息，请参阅您使用的任何导入器的文档。

15.10.0

  • 一个 Elastic Indexer Cron Workers 的 bug 可能导致 Sidekiq 饱和。
    • 当此问题发生时，合并请求合并、流水线、Slack 通知和其他事件未被创建或需要很长时间才能发生。
    • 此问题可能不会立即显现，因为可能需要长达一周的时间，Sidekiq 才会饱和。
    • 不需要启用 Elasticsearch 即可发生此问题。
    • 为了解决此问题，请升级到 15.11 或使用问题中的解决方法。
  • 一个零停机时间重新索引的 bug 可能会在重新索引时导致 无法加载任务状态 错误。您也可能在 Elasticsearch 主机上收到 sliceId 必须大于 0，但为 [-1] 错误。作为解决方法，请考虑从头开始重新索引或升级到极狐GitLab 16.3。
  • Omnibus GitLab 16.0 中的 Gitaly 配置发生了重大变化。在 Omnibus 极狐GitLab 15.10 中，您可以开始迁移到新结构，同时在 16.0 之前保持向后兼容。阅读有关此更改的更多信息。

  • 升级到极狐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. 使用数据库控制台执行以下 SQL 语句（对于 Linux 软件包安装为 sudo gitlab-psql）： 

      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 或更高版本之前未完成引发的。要解决此错误，可以安全地将迁移标记为完成： 

    # 开始 rails 控制台

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, [])

  # 标记所有作业已完成
  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
  • Terraform 配置的一个 bug 导致 Terraform 状态在 gitlab.rb 配置文件中将 gitlab_rails['terraform_state_enabled'] 设置为 false 时仍然启用。由于此 bug 在极狐GitLab 15.10 中修复，升级到极狐GitLab 15.10 可能会破坏使用 Terraform 状态 功能的项目，如果在 gitlab.rb 配置中禁用它。如果您已在 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 安装

15.9.0

  • Elastic Indexer Cron Workers 的一个 bug 可能导致 Sidekiq 饱和。
    • 当此问题发生时，合并请求合并、流水线、Slack 通知和其他事件未被创建或需要很长时间才能发生。
    • 此问题可能不会立即显现，因为可能需要长达一周的时间，Sidekiq 才会饱和。
    • 不需要启用 Elasticsearch 即可发生此问题。
    • 为了解决此问题，请升级到 15.11 或使用问题中的解决方法。
  • BackfillTraversalIdsToBlobsAndWikiBlobs 高级搜索迁移的 bug 可能导致 Elasticsearch 集群饱和。
    • 当此问题发生时，搜索可能会变慢，并且 Elasticsearch 集群的更新可能需要很长时间才能完成。
    • 为了解决此问题，请升级到极狐GitLab 15.10 以减少迁移批量大小。
  • 升级到补丁版本 15.9.3 或更高版本。这为两个数据库迁移 bug 提供了修复：
    • 补丁版本 15.9.0、15.9.1、15.9.2 存在一个 bug，可能导致用户个人资料字段 linkedin、twitter、skype、website_url、location 和 organization 的数据丢失。
    • 第二个 bug 修复确保可以直接从 15.4.x 升级。
  • 作为 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 15.9 中，您可以开始迁移到新结构，同时在 16.0 之前保持向后兼容。阅读有关此更改的更多信息。

自编译安装

  • 对于 自编译（源代码）安装，随着 gitlab-sshd 的添加，构建极狐GitLab Shell 需要 Kerberos 头文件。 

    sudo apt install libkrb5-dev

Geo 安装

DETAILS:
Tier: 专业版，旗舰版
Offering: 私有化部署

15.8.2

Geo 安装

DETAILS:
Tier: 专业版，旗舰版
Offering: 私有化部署

  • 我们发现了一个问题，项目和 wiki 的复制和验证无法跟上在少数 Geo 安装中。如果您看到某些项目和/或 wiki 持续处于“排队”状态进行验证，则您的安装可能会受到影响。这可能导致故障转移后数据丢失。
    • 受影响的版本：极狐GitLab 版本 15.6.x、15.7.x 和 15.8.0 - 15.8.2。
    • 包含修复的版本：极狐GitLab 15.8.3 及更高版本。

15.8.1

  • 由于极狐GitLab 15.4 中引入的 bug，如果 Gitaly Cluster 中的一个或多个 Git 仓库不可用，则仓库检查和Geo 复制和验证将停止在受影响的 Gitaly Cluster 中运行所有项目或项目 wiki 仓库。该 bug 已通过在极狐GitLab 15.9.0 中恢复更改进行修复。在升级到此版本之前，请检查是否有任何“不可用”的仓库。

Geo 安装

  • 我们发现了一个问题，项目和 wiki 的复制和验证无法跟上在少数 Geo 安装中。如果您看到某些项目和/或 wiki 持续处于“排队”状态进行验证，则您的安装可能会受到影响。这可能导致故障转移后数据丢失。
    • 受影响的版本：极狐GitLab 版本 15.6.x、15.7.x 和 15.8.0 - 15.8.2。
    • 包含修复的版本：极狐GitLab 15.8.3 及更高版本。

15.8.0

  • Gitaly 要求 Git 版本为 2.38.0 或更高。对于自编译安装，您应该使用 Gitaly 提供的 Git 版本。
  • 由于极狐GitLab 15.4 中引入的 bug，如果 Gitaly Cluster 中的一个或多个 Git 仓库不可用，则仓库检查和Geo 复制和验证将停止在受影响的 Gitaly Cluster 中运行所有项目或项目 wiki 仓库。该 bug 已通过在极狐GitLab 15.9.0 中恢复更改进行修复。在升级到此版本之前，请检查是否有任何“不可用”的仓库。

Geo 安装

  • pg_upgrade 无法将捆绑的 PostregSQL 数据库升级到版本 13。请参阅详细信息和解决方法。
  • 我们发现了一个问题，项目和 wiki 的复制和验证无法跟上在少数 Geo 安装中。如果您看到某些项目和/或 wiki 持续处于“排队”状态进行验证，则您的安装可能会受到影响。这可能导致故障转移后数据丢失。
    • 受影响的版本：极狐GitLab 版本 15.6.x、15.7.x 和 15.8.0 - 15.8.2。
    • 包含修复的版本：极狐GitLab 15.8.3 及更高版本。
  • 从次要站点克隆 LFS 对象即使次要站点已完全同步，也会从主站点下载。请参阅详细信息和解决方法。

15.7.6

  • 由于极狐GitLab 15.4 中引入的 bug，如果 Gitaly Cluster 中的一个或多个 Git 仓库不可用，则仓库检查和Geo 复制和验证将停止在受影响的 Gitaly Cluster 中运行所有项目或项目 wiki 仓库。该 bug 已通过在极狐GitLab 15.9.0 中恢复更改进行修复。在升级到此版本之前，请检查是否有任何“不可用”的仓库。

Geo 安装

  • 我们发现了一个问题，项目和 wiki 的复制和验证无法跟上在少数 Geo 安装中。如果您看到某些项目和/或 wiki 持续处于“排队”状态进行验证，则您的安装可能会受到影响。这可能导致故障转移后数据丢失。
    • 受影响的版本：极狐GitLab 版本 15.6.x、15.7.x 和 15.8.0 - 15.8.2。
    • 包含修复的版本：极狐GitLab 15.8.3 及更高版本。

15.7.5

  • 由于极狐GitLab 15.4 中引入的 bug，如果 Gitaly Cluster 中的一个或多个 Git 仓库不可用，则仓库检查和Geo 复制和验证将停止在受影响的 Gitaly Cluster 中运行所有项目或项目 wiki 仓库。该 bug 已通过在极狐GitLab 15.9.0 中恢复更改进行修复。在升级到此版本之前，请检查是否有任何“不可用”的仓库。

Geo 安装

  • 我们发现了一个问题，项目和 wiki 的复制和验证无法跟上在少数 Geo 安装中。如果您看到某些项目和/或 wiki 持续处于“排队”状态进行验证，则您的安装可能会受到影响。这可能导致故障转移后数据丢失。
    • 受影响的版本：极狐GitLab 版本 15.6.x、15.7.x 和 15.8.0 - 15.8.2。
    • 包含修复的版本：极狐GitLab 15.8.3 及更高版本。

15.7.4

  • 由于极狐GitLab 15.4 中引入的 bug，如果 Gitaly Cluster 中的一个或多个 Git 仓库不可用，则仓库检查和Geo 复制和验证将停止在受影响的 Gitaly Cluster 中运行所有项目或项目 wiki 仓库。该 bug 已通过在极狐GitLab 15.9.0 中恢复更改进行修复。在升级到此版本之前，请检查是否有任何“不可用”的仓库。

Geo 安装

  • 我们发现了一个问题，项目和 wiki 的复制和验证无法跟上在少数 Geo 安装中。如果您看到某些项目和/或 wiki 持续处于“排队”状态进行验证，则您的安装可能会受到影响。这可能导致故障转移后数据丢失。
    • 受影响的版本：极狐GitLab 版本 15.6.x、15.7.x 和 15.8.0 - 15.8.2。
    • 包含修复的版本：极狐GitLab 15.8.3 及更高版本。

15.7.3

  • 由于极狐GitLab 15.4 中引入的 bug，如果 Gitaly Cluster 中的一个或多个 Git 仓库不可用，则仓库检查和Geo 复制和验证将停止在受影响的 Gitaly Cluster 中运行所有项目或项目 wiki 仓库。该 bug 已通过在极狐GitLab 15.9.0 中恢复更改进行修复。在升级到此版本之前，请检查是否有任何“不可用”的仓库。

Geo 安装

  • 我们发现了一个问题，项目和 wiki 的复制和验证无法跟上在少数 Geo 安装中。如果您看到某些项目和/或 wiki 持续处于“排队”状态进行验证，则您的安装可能会受到影响。这可能导致故障转移后数据丢失。
    • 受影响的版本：极狐GitLab 版本 15.6.x、15.7.x 和 15.8.0 - 15.8.2。
    • 包含修复的版本：极狐GitLab 15.8.3 及更高版本。

15.7.2

  • 由于极狐GitLab 15.4 中引入的 bug，如果 Gitaly Cluster 中的一个或多个 Git 仓库不可用，则仓库检查和Geo 复制和验证将停止在受影响的 Gitaly Cluster 中运行所有项目或项目 wiki 仓库。该 bug 已通过在极狐GitLab 15.9.0 中恢复更改进行修复。在升级到此版本之前，请检查是否有任何“不可用”的仓库。

Geo 安装

DETAILS:
Tier: 专业版，旗舰版
Offering: 私有化部署

  • 容器镜像仓库推送事件被拒绝，因为 /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，这些版本包含此问题的修复，并避免故障转移后的潜在数据丢失。
  • 我们发现了一个问题，项目和 wiki 的复制和验证无法跟上在少数 Geo 安装中。如果您看到某些项目和/或 wiki 持续处于“排队”状态进行验证，则您的安装可能会受到影响。这可能导致故障转移后数据丢失。
    • 受影响的版本：极狐GitLab 版本 15.6.x、15.7.x 和 15.8.0 - 15.8.2。
    • 包含修复的版本：极狐GitLab 15.8.3 及更高版本。

15.7.1

  • 由于极狐GitLab 15.4 中引入的 bug，如果 Gitaly Cluster 中的一个或多个 Git 仓库不可用，则仓库检查和Geo 复制和验证将停止在受影响的 Gitaly Cluster 中运行所有项目或项目 wiki 仓库。该 bug 已通过在极狐GitLab 15.9.0 中恢复更改进行修复。在升级到此版本之前，请检查是否有任何“不可用”的仓库。

Geo 安装

DETAILS:
Tier: 专业版，旗舰版
Offering: 私有化部署

  • 容器注册表推送事件被拒绝，因为 /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，这些版本包含此问题的修复，并避免故障转移后的潜在数据丢失。
  • 我们发现了一个问题，项目和 wiki 的复制和验证无法跟上在少数 Geo 安装中。如果您看到某些项目和/或 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 表上不应存在具有 NULL 的 work_item_type_id 的记录。 存在多个 BackfillWorkItemTypeIdForIssues 后台迁移，这些迁移将在 EnsureWorkItemTypeBackfillMigrationFinished 部署后迁移中完成。
  • 极狐GitLab 15.4.0 引入了一个批量后台迁移以在议题表上回填 namespace_id 值。 在较大的极狐GitLab 实例上，此迁移可能需要多个小时或几天才能完成。 确保迁移成功完成，然后再升级到 15.7.0。

  • 添加了一个数据库约束，指定议题表上的 namespace_id 列没有 NULL 值。

    • 如果 15.4 的 namespace_id 批量后台迁移失败（请参阅上文），则 15.7 升级会因数据库迁移错误而失败。

    • 对于具有大型议题表的极狐GitLab 实例，验证此约束会导致升级所需时间比平时更长。 所有数据库更改需要在一小时限制内完成： 

      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 chart 的默认值（gitlab.sidekiq.concurrency）：25

    参考架构仍然使用 10 的默认值，因为这是为这些配置专门设置的。

    配置了 max_concurrency 的站点不会受到此更改的影响。 阅读有关 Sidekiq 并发设置的更多信息。

  • 极狐GitLab Runner 15.7.0 引入了影响 CI/CD 作业的重大变化：正确处理作业文件变量的扩展。 以前，引用 文件类型变量 的作业定义的变量被扩展为文件变量的值（其内容）。此行为不符合 shell 变量扩展的典型规则。还可能导致泄露秘密或敏感信息，例如在 echo 输出中打印文件变量及其内容。
  • 由于极狐GitLab 15.4 中引入的 bug，如果 Gitaly Cluster 中的一个或多个 Git 仓库不可用，则仓库检查和Geo 复制和验证将停止在受影响的 Gitaly Cluster 中运行所有项目或项目 wiki 仓库。该 bug 已通过在极狐GitLab 15.9.0 中恢复更改进行修复。在升级到此版本之前，请检查是否有任何“不可用”的仓库。
  • 从次要站点克隆 LFS 对象即使次要站点已完全同步，也会从主站点下载。请参阅详细信息和解决方法。

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，这些版本包含此问题的修复，并避免故障转移后的潜在数据丢失。
  • 我们发现了一个问题，项目和 wiki 的复制和验证无法跟上在少数 Geo 安装中。如果您看到某些项目和/或 wiki 持续处于“排队”状态进行验证，则您的安装可能会受到影响。这可能导致故障转移后数据丢失。
    • 受影响的版本：极狐GitLab 版本 15.6.x、15.7.x 和 15.8.0 - 15.8.2。
    • 包含修复的版本：极狐GitLab 15.8.3 及更高版本。

15.6.7

  • 由于极狐GitLab 15.4 中引入的 bug，如果 Gitaly Cluster 中的一个或多个 Git 仓库不可用，则仓库检查和Geo 复制和验证将停止在受影响的 Gitaly Cluster 中运行所有项目或项目 wiki 仓库。该 bug 已通过[在极狐GitLab 15.9.