I’ve got this message pop up when I try and upgrade via the UI:
After several git pulls and rebuilds I’m still getting the same message. Any tips?
I wonder if I need to do this:
This is for an old, well established forum.
Cc @pacharanero
Was this a standard install? Could it be something like running the upgrade on the wrong server? Did the rebuild fail and you restarted the old container? I don’t have any better guesses.
You should keep your os to date as recommended in the topic you linked, but that’s unrelated to the problem you describe.
It has puzzled me on occasion when the GUI update doesn’t seem to be reset and it directs us to SSH in, even when this has just literally been done.
It was a standard install, but the original install was way back in 2014, in the very early days when Discourse was not long out of public beta.
user@server:/var/discourse$ docker -v
Docker version 19.03.13, build 4484c46d9d
There is a more recent version of Docker, but it’s common for the version in Ubuntu to lag a little behind the latest.
OS is fully and regularly updated.
Hmm. There is a lag after update before Discourse checks to see if the container has been rebuilt, though I have never known it to affect docker-manager.
You could try this:
docker exec app bash -c 'rails runner AdminDashboardGeneralData.refresh_stats
But it’s been long enough now, that I don’t think this is your problem. It can’t hurt, though.
I can’t remember the minimum version of docker supported, but I don’t think that’s the issue either, at least if you’re not on Ubuntu 16.04.
Is there any way it could be about the branch we’re running?
In containers/app.yml we are explicitly selecting tests-passed
But of course that’s what’s running INSIDE the container. Would it matter what the default branch is outside the container?
user@server:/var/discourse# git status
On branch master
Your branch is up to date with 'origin/master'.
Back in the day master was the default in GitHub. Now it’s main.
RIght. I guess you could try
cd /var/discourse
git checkout main
But I didn’t think you needed to do that explicitly.
What about
cd /var/discourse
./launcher enter app
cd /var/www/discourse
git status
1 Like
This relates to discourse_docker, of course:
:/var/discourse# git remote -v
origin https://github.com/discourse/discourse_docker.git (fetch)
origin https://github.com/discourse/discourse_docker.git (push)
The branch was switched over in August 2021 and is 49 commits behind main at time of writing:
GitHub - discourse/discourse_docker at master
So you definitely want to switch to main branch?
However, I’ve agree with @pfaffman have never explicitly done that, so there must’ve been some script that did it. Perhaps it will occur with the next rebuild?
1 Like
returns
user@inside-container-app:/var/www/discourse# git status
Refresh index: 100% (30949/30949), done.
On branch tests-passed
Your branch is up to date with 'origin/tests-passed'.
That looks like you’re up to date. And you’re still getting the Upgrades Disabled page?
Yep. I had a look on another Discourse I run which dates back a bit, and is similarly on master and that also has the same Upgrades Disabled page.
That said, another Discourse I set up in mid-2022 is also on master and presents the update screen as normal!
If we can get any confirmation that changing the branch of discourse_docker to track main will fix it then I’m prepared to give it a go. Perhaps on a site that only I use.
That would roughly coincide with when I started to get weird behaviour on some Discourses around update time. (Because of this I ended up just updating them all via SSH every time, using Ansible).
That’s pretty much what I always do as well, though increasingly, I crank up the Ansible upgrade script with https://www.pfaffmanager.com/.
Ok so I switched to track main on a Discourse that I only use as a personal notebook and journal etc.
Prior to the switch, I was tracking master and the Admin Upgrade page was indeed disabled.
At switching to track main, and rebuilding, I can confirm the Admin Upgrade UI is back to functioning normally.
4 Likes
Hmmm. I wonder if that means that all of those old installations need to change their branch. @Falco, maybe you want to see this.
Launcher changes the branch to main from master automatically. Sounds like something was blocking the automatic switch, like pending stash changes.
2 Likes
How likely is that on so many instances?
And what on earth are stash changes?
How many are we talking? There are thousands of Discourse out there, and I don’t see dozens of reports of this problem. At least not yet 
If someone has a server that is currently reproducing this bug and can keep it that way for another day, please reply here so we can investigate further.
1 Like
Hmmmm. This might be something to do with it on our instance @nathank
I have a couple of operational files (which are nothing to do with the Discourse codebase) in the same directory as the Discourse Git repo. If ./launcher attempted to change branch Git would error, requiring me to stash these changes (or commit them).
Thanks @Falco I will do some further investigation. It may be that the only Discourse instances which would be affected are ones in which Git throws an error for whatever reason on attempting to change branch.
4 Likes
Update: I think this issue with some untracked files *may have been the problem.
I removed the files and made sure that the command git checkout main succeeded.
Then I ran ./launcher rebuild app and it seems to have worked.
AFAICT, as per what @Falco states above, I don’t think it is actually necessary to track main in the Discourse repo. When you run ./launcher rebuild app the script itself will check out the correct branch.
3 Likes
I did have a few older Discourses which still showed the Upgrades Disabled page despite having ensured that
git checkout main
git pull
git checkout master
worked without errors.
And for these I simply left those instances tracking main and ./auncher rebuild app and it was fine.