此更新对我来说失败了，现在我的所有 3 个 Discourse 论坛都已关闭。
升级屏幕上的控制台窗口没有任何内容，但 UI 的其余部分表明升级仍在进行中（但这已经比我做过的任何更新都要长了）。
有其他人遇到这种情况吗？有什么办法可以让我成功完成升级？
1 个赞
@pearsonified 因为这包括对 Rails 组件的更新，所以这是需要从命令行进行更新的版本之一。
2 个赞
啊，这是 ruby 3.0 错误和 web-push-3.0.0 的问题吗？
管理员升级 web UI 应该告诉用户这个问题，而不是让他们点击“全部升级”然后导致论坛完全损坏。这能为用户省去很多心悸。
1 个赞
我不知道；我个人从不使用 GUI 进行更新，我个人只从命令行进行更新。我没有看到任何看起来像那样的错误。但那样的话我也不会看到。
大多数时候，当你看到一个通用的错误消息时，如果具体情况可以预见得足够好，以至于可以生成一个特定的错误消息，那么它本可以被避免。
我想这很好，因为“帮助我的 GUI 更新失败”的问题非常罕见，以至于大多数人都不知道首先要做的是执行 git pull; ./launcher rebuild app 进行默认部署。这几乎总是这里的答案。
但这是 GUI 更新失败时的一般做法。
3 个赞
我使用 Discourse 已经很多年了，大概有 7 年了吧。不过，以前从未遇到过 Web 升级灾难性失败的情况。当然，它也失败过，但论坛总是能恢复正常，因为它回滚并启动了旧容器。
这不是一个通用错误，Ruby 的错误信息很清楚。
web-push-3.0.0 需要 ruby 版本 >= 3.0，这与当前版本 2.7.6 不兼容
Docker Manager: 升级失败
如果我为 Discourse 付费，我会对此大声抱怨。不是因为有一个巨大的 bug 导致我们的论坛崩溃（bug 总是会发生），而是因为它在过去至少三天里都没有得到修复。目前来看，这只是在一天结束时带来的一点小刺激。
1 个赞
从 docker 管理器的角度来看，在当前运行的版本编写代码时，并不知道将来会发生这个问题。我理解您很沮丧，但您所要求的在技术上可能没有意义。
如果您付费购买了 Discourse，他们会负责管理这个过程，而您永远不会看到它。
3 个赞
即使技术上无法修复，您也可以向用户发送电子邮件，警告他们通过 CLI 进行升级。对此大肆宣传。破坏论坛且无法回滚是糟糕的。
我以为 Discourse 也销售本地部署支持？无论如何，我不能抱怨得太厉害，因为我不是付费客户，但天啊，3 天确实不怎么样。
1 个赞
我很高兴您七年来第一次不得不退回到这一点，但是：
我将称之为歪曲。CDCK 确实建议在更新前进行备份作为最佳实践。我在这里的元（meta）上多次看到这样的说明，即如果 GUI 更新失败，请作为管理自己论坛的正常预期的一部分，退回到从命令行重建。他们并没有在没有回滚的情况下破坏论坛，所以你的暗示是错误的。
我不会在这里争论几个小时。我只是觉得你在这里不完全合理。
此外，在没有通过某种暂存环境运行升级的情况下升级生产服务器简直是在自找麻烦。
它不必是完整的副本，$5 的 VPS 对大多数人来说就足够了。如果你想避免停机和求助于备份的需要，这是你能获得的最便宜的保险。
1 个赞
我刚刚在一个很久没更新的测试 DO 实例上进行了测试：
正如报告的那样，它出错了：
Fetching gem metadata from https://rubygems.org/.........
Fetching https://github.com/rails/sprockets
web-push-3.0.0 requires ruby version >= 3.0, which is incompatible with the
current version, 2.7.6
Docker Manager: FAILED TO UPGRADE
#<RuntimeError: RuntimeError>
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:209:in `run'
/var/www/discourse/plugins/docker_manager/lib/docker_manager/upgrader.rb:93:in `upgrade'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:19:in `block in <main>'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3.1/lib/active_support/fork_tracker.rb:20:in `block in fork'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3.1/lib/active_support/fork_tracker.rb:18:in `fork'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/activesupport-7.0.3.1/lib/active_support/fork_tracker.rb:18:in `fork'
/var/www/discourse/plugins/docker_manager/scripts/docker_manager_upgrade.rb:6:in `<main>'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.3.1/lib/rails/commands/runner/runner_command.rb:43:in `load'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.3.1/lib/rails/commands/runner/runner_command.rb:43:in `perform'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.2.1/lib/thor/command.rb:27:in `run'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.2.1/lib/thor/invocation.rb:127:in `invoke_command'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/thor-1.2.1/lib/thor.rb:392:in `dispatch'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.3.1/lib/rails/command/base.rb:87:in `perform'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.3.1/lib/rails/command.rb:48:in `invoke'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/railties-7.0.3.1/lib/rails/commands.rb:18:in `<main>'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/bootsnap-1.13.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/bootsnap-1.13.0/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:32:in `require'
bin/rails:18:in `<main>'
Spinning up 3 Unicorn worker(s) that were stopped initially
升级页面现在显示：
主站点出现 500 错误。在 /logs 中我看到了这个错误：
NoMethodError (undefined method `navigation_menu' for #<Class:0x00007fdffcb1b2f8>)
lib/wizard/builder.rb:98:in `block in build'
lib/wizard.rb:25:in `append_step'
lib/wizard/builder.rb:61:in `build'
lib/wizard.rb:110:in `requires_completion?'
lib/wizard.rb:117:in `user_requires_completion?'
app/serializers/site_serializer.rb:171:in `include_wizard_required?'
...
@pearsonified @mcdanlj 你们能粘贴一下你们遇到的错误吗？
我不知道我们现在是否能做些什么来防止未来的用户遇到这种情况，但我们会调查的。
同时，以下步骤有帮助吗？
6 个赞
我今天早上要运行命令行升级，看看效果如何。论坛已经宕机 18 小时了 
2 个赞
是的，如果您问我，CLI 重建工作正常。我是一名不错的系统管理员，在这里找到了解决方案，但看起来像 @pearsonified 这样的其他论坛所有者受到了严重的不便。18 小时的停机时间，哎哟。
那些谈论暂存和生产环境的人简直是疯了。有许多非企业人士在小型虚拟机上托管 Discourse 论坛。“你应该在暂存环境中进行测试”是一种侮辱性的、道貌岸然的回应，这丝毫不能证明破坏他们的安装是正当的。没有什么可以证明这一点。
我只想强调，我非常感谢这款出色的软件是完全免费的。我对此心存感激，偶尔遇到的绊脚石并不会改变我的感受。
2 个赞
Discourse 是免费的，但服务器、域名和我们的时间不是。
这与企业环境无关，只是因为存在太多变量，所以这是常识。我们做了大量工作来使升级无缝进行，如果你宁愿免费花费你的时间来解决重大的故障，那是你的选择——但就我个人而言，我更希望我知道我托管的非营利组织和志愿者社区将因一次无痛的升级而宕机一次，而不是长时间宕机。
DO 的最小 VPS 足以在升级具有代表性的情况下降低风险——如果你是一名合格的系统管理员，那么 5 美元就相当于一杯咖啡的成本，是你时薪市场价的一小部分。
stg 虚拟机还必须存储论坛的数据，这将使我们的托管成本翻倍。反正也没有必要，这是一个电子游戏论坛，一点停机时间（不是 18 小时！）是可以接受的。最坏的情况是，我在升级前有一个虚拟机快照，所以我可以回滚。
我确实认为它已损坏 4 天，这令人担忧。升级失败而无法回滚应该会引发一个真正的“我的天，这必须立即修复”的时刻。这不应该是一个有争议的说法。
1 个赞
我也遇到了 web-push Ruby 错误。这是普通的论坛，没有自定义插件。
web-push-3.0.0 需要 ruby 版本 >= 3.0，这与当前版本 2.7.6 不兼容。
以前也曾出现过需要通过命令行升级的情况。也许现在可以为导致此问题的任何版本启用该选项？
编辑：哦，它确实是这么说的！
问题在于，当你执行 docker_manager update 然后只点击顶部选项卡而不是刷新页面时。那么，能否通过 HTTP 刷新而不是仅仅通过 JS 更改选项卡？
1 个赞