极狐 GitLab

Rails 升级指南

我们致力于使用最新 Rails 版本运行极狐GitLab，以享受性能提升、安全更新和新功能。

Rails 升级方法#

  1. 为极狐GitLab 准备 MR。
  2. 为安全补丁创建补丁版本和回溯移植。

为极狐GitLab 准备 MR#

  1. 查看 升级 Ruby on Rails 指南，并为即将到来的变更准备应用程序。
  2. 在 Gemfile 中更新 rails gem 版本。
  3. 运行 bundle update --conservative rails。
  4. 对于主要和次要版本更新，运行 bin/rails app:update 并检查是否有任何建议的更改需要应用。
  5. 在 qa/Gemfile 中更新 activesupport 版本。
  6. 在 qa 文件夹中运行 bundle update --conservative activesupport。
  7. 运行 find gems -name Gemfile -exec bundle update --gemfile {} activesupport --patch --conservative \; 并根据需要将命令中的 --patch 替换为 --minor 或 --major。
  8. 解决所有 Bundler 冲突。
  9. 确保 @rails/ujs 和 @rails/actioncable npm 包匹配 package.json 中的新 rails 版本。
  10. 在更新此内容后，运行 yarn patch-package @rails/ujs 以确保我们的本地补丁文件版本匹配。
  11. 创建一个带有 pipeline:run-all-rspec 标签的 MR，并查看流水线是否中断。
  12. 要解决并调试 spec 失败，请对 rails 仓库使用 git bisect。请参阅下面的调试部分。
  13. 在合并请求描述中包含两个版本之间 Gem 差异的链接。例如，这是 activesupport 6.1.3.2 到 6.1.4.1 的 gem 差异。

为 Gitaly 准备 MR#

由于 Gitaly 不再有 Ruby 代码，因此不再需要。

为安全补丁创建补丁版本和回溯移植#

如果 Rails 升级是针对补丁版本并且包含重要的安全修复，请确保将其发布为面向私有化部署客户的极狐GitLab 补丁版本。请咨询我们的发布经理，了解如何进行。

弃用日志记录器#

我们还将 Ruby 和 Rails 弃用警告记录到专用日志文件 log/deprecation_json.log 中。当存在未被测试充分覆盖的代码，从而会遗漏 DeprecationToolkitEnv 时，它可以提供线索。

对于 JihuLab.com，极狐GitLab 团队成员可以在 Kibana 中检查这些日志事件（https://log.gprd.gitlab.net/goto/f7cebf1ff05038d901ba2c45925c7e01）。

对 Rails 使用 Git bisect#

通常，如果你知道是哪个 Rails 更改导致 spec 失败，这会增加额外的上下文并有助于找到失败的修复方法。要高效快速地找到导致 spec 失败的 Rails 更改，你可以对 Rails 仓库使用 git bisect 命令。

  1. 在你选择的文件夹中克隆 rails 项目。例如，它可以位于 GDK 根目录中：

    shell
    cd <GDK_FOLDER>
git clone https://github.com/rails/rails.git

  2. 将极狐GitLab Gemfile 中的 gem 'rails' 行替换为：

    ruby
    gem 'rails', ENV['RAILS_VERSION'], path: ENV['RAILS_FOLDER']

  3. 使用你克隆 Rails 的文件夹设置 RAILS_FOLDER 环境变量：

    shell
    export RAILS_FOLDER="<GDK_FOLDER>/rails"

  4. 将目录切换到 RAILS_FOLDER 并为 git bisect 命令设置范围：

    shell
    cd $RAILS_FOLDER
git bisect start <NEW_VERSION_TAG> <OLD_VERSION_TAG>

    其中 <NEW_VERSION_TAG> 是 spec 失败的标签，<OLD_VERSION_TAG> 是 spec 通过的标签。 例如，git bisect start v6.1.4.1 v6.1.3.2，如果我们从版本 6.1.3.2 升级到 6.1.4.1。 将 <NEW_VERSION_TAG> 替换为 spec 失败的标签，将 <OLD_VERSION_TAG> 替换为 spec 通过的标签。例如，如果我们从版本 6.1.3.2 升级到 6.1.4.1，则为 git bisect start v6.1.4.1 v6.1.3.2。 在输出中，你可以看到大约需要多少步才能找到该提交。

  5. 启动 git bisect 过程，并将 spec 的文件名作为参数传递给 scripts/rails-update-bisect。仅选取一个示例可能会比整个 spec 文件更快。

    shell
    git bisect run <GDK_FOLDER>/gitlab/scripts/rails-update-bisect spec/models/ability_spec.rb
# 或者
git bisect run <GDK_FOLDER>/gitlab/scripts/rails-update-bisect spec/models/ability_spec.rb:7

  6. 当过程完成时，git bisect 会打印提交哈希，你可以使用它在 rails/rails 仓库中找到相应的 MR。

  7. 执行 git bisect reset 以退出 bisect 模式。

  8. 还原对 Gemfile 的更改：

    shell
    git checkout -- Gemfile

后续阅读材料#