Upgrade to `latest-version` through docker

(Leo Bergnéhr) #1

I love the docker hosting you’ve done, but I ran into something today when I was going to upgrade to the latest version:

This is what I get from the /admin/docker log after clicking upgrade:

$ cd /var/www/discourse && git pull
You are not currently on a branch, so I cannot use any
’branch…merge’ in your configuration file.
Please specify which branch you want to merge with on the command
line and try again (e.g. 'git pull ').
See git-pull(1) for details.

This is my /var/docker/containers/app.yml

  # ssh key here ...
  # git revision to run  
  version: latest-release

I think it’s the first time I’m running with the latest-release tag and think that might be the problem. I’m having trouble finding some more info on that particular parameter and what’s reasonable to set it to.

Before running the upgrade through /admin/docker I upgraded to the latest docker and pulled the latest bits from the docker repo, then did a launcher destroy/boostrap/start app cycle.

(Sam Saffron) #2

I have this open PR open


But I am not really sure how latest-release is failing here.

Can you try pulling docker manager from that fork and seeing if it resolves the issue for you?

(Leo Bergnéhr) #3

Perhaps I will be able to try that, but I’m thinking: since I’m doing launcher destroy/bootstrap, wouldn’t this scenario be the same for anyone running with the latest-release tag as the version: parameter?

(Leo Bergnéhr) #4

I tried doing an upgrade again after the 0.9.9 release. I went ahead and did the usual

cd /var/docker
./launcher stop app
./launcher destroy app
./launcher bootstrap app
./launcher start app

The version: setting in /var/docker/containers/app.yml is set to latest-release as before. That didn’t do anything though. I tried the admin/docker upgrade approach as well, which now produced a different error:

$ cd /var/www/discourse && git fetch && git reset --hard HEAD@{upstream}
error: No upstream branch found for 'HEAD’
error: No upstream branch found for 'HEAD’
fatal: ambiguous argument ‘HEAD@{upstream}’: unknown revision or path not in the working tree.
Use ‘–’ to separate paths from revisions

Something’s not right. I ssh’ed into the container and then into /var/www/discourse as well as a git status and git show. That was interesting as it produces this:

$ git status
# Not currently on any branch.             
nothing to commit (working directory clean)

$ git show
commit 87f054366ce851732ce2ad7278015888435996b7
Author: Neil Lalonde <neillalonde@gmail.com>   
Date:   Thu Mar 13 15:20:08 2014 -0400         
Version bump to v0.9.8.10                  

So it appears the repo is not currently on a branch. Don’t the bootstrapping of the container resets that to whatever I have in the version: property in app.yaml? I mean, even though I’ve destroyed the container it still seems to end up in this state for some reason.

What would be the most sane way to get out of this? I know I’m not supposed to manually update things in the git repo on the container, but is there another way you think?

(Leo Bergnéhr) #5

For anyone finding themselves in this situation, as well as this post, here’s an update:

I ssh:ed into the container and manually updated to the master branch since it was currently on a detached commit for some reason. After that, the docker upgrade worked as it should. Could the problem here be that the commit for v0.9.8.10 was not on master? Looking at the commit log, it seems the commit pattern changed a bit after that versions, which might be due to the stuck state this discourse installation found itself in.

(Rikki Tooley) #6

Pretty sure if you checkout a tag, then you get into in a headless state, i.e. not on a branch. latest-release is a tag, which would explain why docker can’t git pull when you tell it to.

I’m not sure of the resolution to this, maybe docker should checkout master before the pull?

(Leo Bergnéhr) #7

You’re right, that must be why it can’t fast forward to HEAD. But that begs the question if it’s even possible to put anything but HEAD in that configuration and have it work reliably? I’m not even sure the version: setting does what I think it does. It appears whatever I put in there, the /admin/docker upgrade process will always upgrade to HEAD. Perhaps it’s more connected to when I get notifications from discourse that there’s a new upgrade, ready to be installed?