"stable" branch will not downgrade - fails on db:migrate

I’m trying to set up a new installation of Discourse using the stable branch. The installation completes successfully if I leave app.yml set to “tests-passed”. However, if I change that to stable and rebuild, it fails with:

I, [2018-01-01T11:55:35.349654 #13]  INFO -- : > cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate'
URGENT: type Failed to initialize site default
rake aborted!
ArgumentError: type
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:46:in `eval'
/var/www/discourse/lib/site_setting_extension.rb:221:in `block (2 levels) in refresh!'
/var/www/discourse/lib/site_setting_extension.rb:220:in `map'
/var/www/discourse/lib/site_setting_extension.rb:220:in `block in refresh!'
/var/www/discourse/lib/site_setting_extension.rb:216:in `synchronize'
/var/www/discourse/lib/site_setting_extension.rb:216:in `refresh!'
(eval):6:in `block (2 levels) in run_file'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:46:in `eval'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:46:in `block (2 levels) in run_file'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:58:in `block in open'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:57:in `open'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:57:in `open'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:36:in `block in run_file'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-4.2.8/lib/active_record/connection_adapters/abstract/database_statements.rb:213:in `block in transaction'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-4.2.8/lib/active_record/connection_adapters/abstract/transaction.rb:184:in `within_new_transaction'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-4.2.8/lib/active_record/connection_adapters/abstract/database_statements.rb:213:in `transaction'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/activerecord-4.2.8/lib/active_record/transactions.rb:220:in `transaction'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:35:in `run_file'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:26:in `block in run'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:25:in `each'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/seed-fu-2.3.5/lib/seed-fu/runner.rb:25:in `run'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/seed-fu-2.3.5/lib/seed-fu.rb:29:in `seed'
/var/www/discourse/lib/tasks/db.rake:8:in `block in <top (required)>'
/var/www/discourse/vendor/bundle/ruby/2.4.0/gems/rake-11.3.0/exe/rake:27:in `<top (required)>'
/usr/local/bin/bundle:23:in `load'
/usr/local/bin/bundle:23:in `<main>'
Tasks: TOP => db:migrate
(See full trace by running task with --trace)
I, [2018-01-01T11:55:39.870156 #13]  INFO -- :
== Seed from /var/www/discourse/db/fixtures/001_categories.rb

I, [2018-01-01T11:55:39.870684 #13]  INFO -- : Terminating async processes
I, [2018-01-01T11:55:39.870854 #13]  INFO -- : Sending INT to HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/9.5/bin/postmaster -D /etc/postgresql/9.5/main pid: 44
2018-01-01 11:55:39.871 UTC [44] LOG:  received fast shutdown request
2018-01-01 11:55:39.871 UTC [44] LOG:  aborting any active transactions
2018-01-01 11:55:39.871 UTC [51] LOG:  autovacuum launcher shutting down
I, [2018-01-01T11:55:39.871055 #13]  INFO -- : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 159
159:signal-handler (1514807739) Received SIGTERM scheduling shutdown...
2018-01-01 11:55:39.874 UTC [48] LOG:  shutting down
2018-01-01 11:55:39.890 UTC [48] LOG:  database system is shut down
159:M 01 Jan 11:55:39.894 # User requested shutdown...
159:M 01 Jan 11:55:39.894 * Saving the final RDB snapshot before exiting.
159:M 01 Jan 11:55:39.903 * DB saved on disk
159:M 01 Jan 11:55:39.903 # Redis is now ready to exit, bye bye...


FAILED
--------------------
Pups::ExecError: cd /var/www/discourse && su discourse -c 'bundle exec rake db:migrate' failed with return #<Process::Status: pid 1508 exit 1>
Location of failure: /pups/lib/pups/exec_command.rb:108:in `spawn'
exec failed with the params {"cd"=>"$home", "hook"=>"bundle_exec", "cmd"=>["su discourse -c 'bundle install --deployment --verbose --without test --without development --retry 3 --jobs 4'", "su discourse -c 'bundle exec rake db:migrate'", "su discourse -c 'bundle exec rake assets:precompile'"]}
d6f04ca979800ae6938c231f5ec57316431b6cbbe358bd1c843fcc1f94db984a
** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one

I have tried rebuilding multiple times and I’ve tried completely destroying the installation and starting again but it always fails this way. Changing the branch back to tests-passed allows the rebuild to complete.

We don’t support downgrades, so to move to stable you need to start on a brand new install.

3 Likes

I’ve tried it on a brand new install. I deleted the Discourse directory, pruned Docker of any existing images, cloned the git repository, edited app.yml to specify the desired branch and it will not build.

The database storage is outside the container, though, and it looks like you didn’t nuke that?

1 Like

OK … that is a possibility, although if it isn’t stored within /var/discourse (or whereever the git repository gets cloned), where is it stored since I haven’t specified another path?

It should be in there. Try this:

  1. cd /var/discourse
  2. Stop the container in case it is still running: sudo ./launcher stop app
  3. Delete the database: sudo rm -rf shared/standalone/
    :warning: This step will delete all Discourse-related data!
  4. Make sure app.yml is on the stable version
  5. Run sudo ./launcher rebuild app to bootstrap and start the container, which will create a fresh database

The important thing is not to bootstrap any newer version before having selected stable, or deleting the shared folder in-between – anything else would be a downgrade of a (mostly empty) Discourse database, which is unsupported.

4 Likes

I’ve realised where I’ve been going wrong … the yml config file references “/var/discourse/shared” but we’re actually using /srv/discourse … so I forgot to update those paths.

Now that I’ve sorted that all out (and properly removed the previously build database), I can correctly set up Discourse on the stable branch.

Sorry for the noise :slight_smile:

5 Likes