Failed Rebuild V2.2.0... I know I know

Purpose her is to test out an upgrade process from a very old version of discourse and trouble shoot.

  1. Created a snapshot droplet in DO
  2. Created a new instance of the discourse snapshot,
  3. Issue remains Live coined droplet will keep jumping to live site/TLD,
  4. I assume a rebuild is required when you change domain name/hostname in app.yml

(cloud flare handling custom dev domain)

This is where I am stuck as the rebuild is erring out on the second pass.

First run result of rebuild app:

UPGRADE OF POSTGRES COMPLETE

Old 10 database is stored at /shared/postgres_data_old

To complete the upgrade, rebuild again using:

./launcher rebuild app

2nd result of rebuild app

FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && git checkout v2.2.0.beta4 failed with return #<Process::Status: pid 228 exit 1>
Location of failure: /pups/lib/pups/exec_command.rb:112:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"code", "cmd"=>["git reset --hard", "git clean -f", "git remote set-branches --add origin main", "git remote set-branches origin $version", "git fetch --depth 1 origin $version", "git checkout $version", "mkdir -p tmp", "chown discourse:www-data tmp", "mkdir -p tmp/pids", "mkdir -p tmp/sockets", "touch tmp/.gitkeep", "mkdir -p                    /shared/log/rails", "bash -c \"touch -a           /shared/log/rails/{production,production_errors,unicorn.stdout,unicorn.stderr,sidekiq}.log\"", "bash -c \"ln    -s           /shared/log/rails/{production,production_errors,unicorn.stdout,unicorn.stderr,sidekiq}.log $home/log\"", "bash -c \"mkdir -p           /shared/{uploads,backups}\"", "bash -c \"ln    -s           /shared/{uploads,backups} $home/public\"", "bash -c \"mkdir -p           /shared/tmp/{backups,restores}\"", "bash -c \"ln    -s           /shared/tmp/{backups,restores} $home/tmp\"", "chown -R discourse:www-data /shared/log/rails /shared/uploads /shared/backups /shared/tmp", "find public/plugins/ -maxdepth 1 -xtype l -delete"]}

** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
./discourse-doctor may help diagnose the problem.

Since then commented out plugins from app.yml and also let encrypt templates

Any ideas how to solve this or what ot try next (apart for many reboots too!) I don’t mind figuring it out with the right pointers if spoon feeding is frowned upon. :wink:

I’m also thinking and open to alternative tac, perhaps install a new empty discourse at v2.2.0 and import an export DB from live site, then run the upgrade to see what happens (breaks!), not a DB guru by a long shot that’s for sure. So open to pointers here too. Thanks in advance.

We removed support for setting git tags in the app.yml version key. You can only use branches.

If you really need to use a tag there try this:

2 Likes

Thanks for that solution. I added the following to the app.yml file, but I have still got the same error:

          - git fetch --depth=1 origin tag v2.2.0 --no-tags
          - git checkout v2.2.0

I also note in the app.yml file there is this

## Which Git revision should this container use? (default: tests-passed)
  version: v2.2.0.beta4

Perhaps I should change this to the non beta or something else?

You need to comment out that line.

Cool did that, we have less/new error output now :wink:

FAILED

--------------------

Pups::ExecError: cd /var/www/discourse && find /var/www/discourse ! -user discourse -exec chown discourse {} \+ failed with return #<Process::Status: pid 368 exit 1>

Location of failure: /pups/lib/pups/exec_command.rb:112:in `spawn'

exec failed with the params {"cd"=>"$home", "hook"=>"web", "cmd"=>["gem install bundler --conservative -v $(awk '/BUNDLED WITH/ { getline; gsub(/ /,\"\"); print $0 }' Gemfile.lock)", "find $home ! -user discourse -exec chown discourse {} \\+"]}

I have tried a few more passes with some variations but still getting stuck on this gem installer bundler fail?

I checked docker version it’ 18.x… I see other have had similar issues after searching and it seems different things worked. I tried configuring the DNS on the server to google 8.8.8.8 as that seemed to work for one user but not here. Another user simply started a fresh install, but I have no idea if they had a DB to import or not.

Perhaps I need to run some updates from within docker?

Since this seems to be a regular problem this one looks promising i.e. the same issue I am facing, I’m going to log any other useful relevant threads as I go:

1 Like

I compared dates on commits in the two repos and tested reasonable versions of the launcher to find one that worked, if i recall correctly.