我在尝试通过用户界面升级时收到此消息：
经过几次 git pull 和重建后，我仍然收到相同的消息。有什么建议吗？
我想我需要这样做：
这是针对一个老牌论坛的。
抄送 @pacharanero
这是标准安装吗？会不会是你在错误的服务器上运行了升级？重建失败然后你重启了旧容器？我没有更好的猜测了。
你应该像你链接的主题中建议的那样保持你的操作系统更新，但这与你描述的问题无关。
有时，当 GUI 更新似乎没有重置并且指示我们 SSH 登录时，即使刚刚执行过此操作，我也感到困惑。
这是一个标准的安装，但最初的安装是在 2014 年，当时 Discourse 刚刚走出公开测试版。
user@server:/var/discourse$ docker -v
Docker version 19.03.13, build 4484c46d9d
有一个更新的 Docker 版本，但 Ubuntu 中的版本通常会比最新版本稍晚一点。
操作系统已全面且定期更新。
嗯。在 Discourse 检查容器是否已重建之前，更新后会有一个延迟，尽管我从未发现它会影响 docker-manager。
您可以尝试这个：
docker exec app bash -c 'rails runner AdminDashboardGeneralData.refresh_stats
但这已经足够长了，我不认为这是您的问题。不过，尝试一下也无妨。
我不记得支持的最低 Docker 版本，但我也认为这不是问题，至少如果您不在 Ubuntu 16.04 上。
这会不会与我们运行的分支有关？
在 containers/app.yml 中，我们明确选择了 tests-passed
但这当然是容器内部运行的内容。容器外部的默认分支是否重要？
user@server:/var/discourse# git status
On branch master
Your branch is up to date with 'origin/master'.
以前，master 是 GitHub 的默认分支。现在是 main。
好的。我想你可以试试
cd /var/discourse
git checkout main
但我没觉得你需要明确地这么做。
那这个呢？
cd /var/discourse
./launcher enter app
cd /var/www/discourse
git status
1 个赞
这当然与 discourse_docker 有关：
:/var/discourse# git remote -v
origin https://github.com/discourse/discourse_docker.git (fetch)
origin https://github.com/discourse/discourse_docker.git (push)
该分支在 2021 年 8 月切换，在撰写本文时落后于 main 分支 49 个提交： GitHub - discourse/discourse_docker at master
所以你肯定想切换到 main 分支？
然而，我同意 @pfaffman 的观点，从未明确做过这件事，所以一定有某个脚本完成了它。也许在下一次重建时会发生？
1 个赞
返回
user@inside-container-app:/var/www/discourse# git status
刷新索引：100% (30949/30949)，完成。
在 tests-passed 分支上
您的分支已与 'origin/tests-passed' 同步。
看起来您已是最新版本。但仍然看到“升级已禁用”页面？
是的。我查看了另一个我运行的 Discourse 实例，它也比较老，同样运行在 master 分支上，也显示了相同的“升级已禁用”页面。
不过，我在 2022 年中期设置的另一个 Discourse 实例也运行在 master 分支上，并且正常显示更新屏幕！
如果我们能得到任何确认，表明将 discourse_docker 的分支切换到跟踪 main 会解决这个问题，那么我愿意尝试一下。也许在一个只有我使用的站点上进行。
这大致与我在一些 Discourse 实例上开始遇到更新时出现奇怪行为的时间吻合。（因此，我最终每次都通过 SSH 使用 Ansible 来更新它们。）
这基本上就是我一直以来的做法，尽管越来越多的时候，我会使用 https://www.pfaffmanager.com/ 来运行 Ansible 升级脚本。
好的，我已将 Discourse 的跟踪切换到 main，它仅用作我的个人笔记和日记本等。
切换之前，我跟踪的是 master，并且管理员升级页面确实已禁用。
切换到跟踪 main 并重新构建后，我可以确认管理员升级 UI 已恢复正常运行。
4 个赞
嗯。我想知道这是否意味着所有那些旧的安装都需要更改它们的分支。@Falco，也许你想看看这个。
启动器将分支从 master 自动更改为主。听起来有什么东西阻止了自动切换，比如待处理的暂存更改。
2 个赞
在这么多实例上，这种情况有多大的可能性？
而且，储藏区更改到底是什么？
我们说的是多少？市面上有数千个 Discourse 实例，我并没有看到几十份关于这个问题的报告。至少目前还没有 
如果有人有一个服务器目前正在复现这个 bug 并且可以保持一天不变，请在此回复，以便我们进一步调查。
1 个赞
嗯。这 可能 与我们实例上的情况有关 @nathank
我在 Discourse Git 仓库的同一目录中有几个操作文件（与 Discourse 代码库无关）。如果 ./launcher 尝试更改分支，Git 会 报错，需要我暂存这些更改（或提交它们）。
谢谢 @Falco 我会做进一步调查。可能只有在 Git 因任何原因尝试更改分支时出错的 Discourse 实例才会受到影响。
4 个赞
更新：我认为这些未跟踪文件的问题*可能就是问题所在。
我删除了这些文件，并确保命令 git checkout main 成功执行。
然后我运行了 ./launcher rebuild app，似乎奏效了。
据我所知，正如 @Falco 在上面所说，我认为在 Discourse 仓库中跟踪 main 实际上并非必需。当你运行 ./launcher rebuild app 时，脚本本身会检出正确的分支。
3 个赞
我确实有一些较旧的 Discourse 实例，尽管我已确保\n\ngit checkout main\ngit pull\ngit checkout master\n\n可以正常运行，但它们仍然显示“Upgrades Disabled”页面。\n\n对于这些实例，我只是让它们继续跟踪 main 并运行 ./launcher rebuild app，一切就绪。