管理Go版本

概述

除了 GitLab Runner 和 Security Projects 之外，所有 Go 二进制文件都在由 Distribution team 管理的项目中构建。

Omnibus GitLab 项目创建了一个包含所有二进制文件的单一、整体的操作系统包，而 Cloud-Native GitLab (CNG) 项目发布了一组由 Helm Charts 或 GitLab Operator 部署和配置的 Docker 镜像。

针对已发布Go版本的测试

所有使用 Go 的项目的测试矩阵必须包含 Distribution 发布的版本。检查 GO_VERSION 设置的 Go 版本：

• Linux package builds.
• Cloud-Native GitLab (CNG).

支持多个Go版本

单个 Go 项目可能需要支持多个 Go 版本，因为：

• 当新版本的 Go 发布时，我们应该开始将其集成到 CI 管道中以验证向前兼容性。
• 为了支持向后移植，我们必须支持 Distribution 发布的 Go 版本 在最新的 3 个次要 GitLab 版本中，不包括当前的里程碑版本。

更新Go版本

我们应当始终：

• 为 Omnibus GitLab 和 Cloud Native GitLab 使用相同的 Go 版本。
• 使用 支持的版本。
• 使用该版本的最新补丁级别以跟上安全修复。

版本变更会影响每个正在编译的项目，因此在更改包构建器使用新版本之前，确保所有项目都已更新以测试新 Go 版本非常重要。尽管有 Go 的兼容性承诺，但次要版本之间的变更可能会暴露我们项目中的错误或导致问题。

go.mod 中的版本

关键要求：

• 始终使用 0 作为补丁版本（例如 go 1.23.0，而不是 go 1.23.4）。
• 不要设置比 CNG 和 Omnibus 中使用的更新的版本，否则会导致构建失败。

你的 go.mod 中的 Go 版本会影响所有下游项目。当你指定最低 Go 版本时，任何导入你包的项目都必须使用该版本或更高版本。这可能会为具有不同 Go 版本约束的项目造成不可能的情况。

例如，如果 CNG 使用 Go 1.23.4，但你的项目声明 go 1.23.5 为最低要求版本，CNG 将无法构建你的包。同样，导入你包的其他项目将被迫升级其 Go 版本，这可能不可行。

查看上文 了解 CNG 和 Omnibus 中使用的版本。

来自 Go Modules Reference：

go 指令设置了使用此模块所需的最低 Go 版本。

你不需要设置 go 1.24.0 来兼容 Go 1.24.0。设置为 go 1.23.0 就可以正常工作。得益于 Go 1 兼容性承诺，Go 1.23.0 和任何更新版本几乎肯定能无问题地构建你的包。

升级节奏

GitLab 在主要 Go 版本发布后八个月内采用该版本，以确保支持的 GitLab 版本不会附带已终止支持的 Go 版本。

如果次要版本修复了安全问题、错误或添加了开发团队请求并由产品管理团队批准的功能，则需要进行次要版本升级。

更多信息，请参见：

• The Go release cycle.
• The Go release policy.

升级流程

升级过程涉及几个关键步骤：

• 跟踪组件更新和验证。
• 跟踪组件集成以发布。
• 与利益相关者沟通。

跟踪工作

1. 导航到 构建架构配置管道页面。
2. 使用以下变量创建一个用于试运行的新管道：
   • 将 COMPONENT_UPGRADE 设置为 true。
   • 将 COMPONENT_NAME 设置为 golang.
   • 将 COMPONENT_VERSION 设置为目标升级版本。
3. 运行管道。
4. 检查试运行管道中的错误。如果任何订阅文件因标签更改或直接责任人不再有效而抛出错误，请联系订阅项目并请求他们更新其配置。
5. 在成功的试运行管道后，使用以下变量创建另一个管道以创建升级史诗和所有相关问题：
   • 将 COMPONENT_UPGRADE 设置为 true。
   • 将 COMPONENT_NAME 设置为 golang.
   • 将 COMPONENT_VERSION 设置为目标升级版本。
   • 将 EPIC_DRY_RUN 设置为 false。
6. 运行管道。

使用Go的已知依赖项

Go 升级的直接责任人必须确保所有必要的组件都得到升级。

先决条件

这些项目必须首先按照出现的顺序进行升级，以便下一节中列出的项目能够使用新的 Go 版本构建。

发布审批所需

主要的 Go 发布版本需要对下面列出的每个项目进行更新，以使该版本能够流入其构建作业。在实际构建环境更新之前，每个项目都必须成功构建。

发布最终更新

上述表格中列出的所有组件成功构建后，直接责任人可以授权更新用于向客户交付 GitLab 包和云原生镜像的构建镜像。

独立发布

尽管这些组件必须更新，但它们不会阻止 GitLab 发布的 Go/No-Go 决策。如果它们落后，直接责任人应将其升级到产品和工程管理。

沟通计划

在整个过程中的几个关键点需要进行沟通，并应作为完成定义的一部分包含在相关问题中：

1. 创建史诗后立即，应将其发布到 Slack。社区成员必须请求被提及的工程经理协助此步骤。负责的 GitLab 团队成员应在以下 Slack 频道中分享史诗链接：
   • #backend
   • #development
2. 合并 GitLab 开发工具包更新后，同一维护者应添加到工程周度回顾同步中，并在以下 Slack 频道宣布变更：
   • #backend
   • #development
3. 在 云原生 GitLab 和 Omnibus GitLab 中合并更新的 Go 版本后，立即将变更添加到工程周度回顾同步中，并在以下 Slack 频道宣布：
   • #backend
   • #development
   • #releases

升级验证

上游组件维护者必须使用以下方法验证其基于 Go 的项目：

• 代码库中既定的单元测试。
• 合并请求性能指南 中建立的流程。
• 性能、可靠性和可用性指南 中建立的流程。

上游组件维护者应考虑使用以下方法验证其基于 Go 的项目：

• 组件隔离操作性能测试。

  集成测试成本高昂，应测试组件间操作问题。组件隔离测试减少了更新的反馈时间并降低了整个组织的资源消耗。

• 组件应在 GitLab 性能测试工具中具有端到端测试覆盖率。

• 通过安装新包**和**从先前版本升级进行集成验证：

  • 单个 GitLab 节点
  • 参考架构部署
  • Geo 部署