Failing to rebuild app on Discourse since May 7

Hi,
I cannot rebuild successfully discourse app.

Error generated:

An error occured while installing mini_racer (0.2.3) and bundler cannot continue.
FAILED TO BOOTSTRAP…

I am using Discourse v2.2.1 and had no issue with the rebuild in the previous weeks.
No issue with the mini_racer as well.

Is there something new? because I’ve noticed that some new packages were downloaded, and it was not the case for the previous rebuild I did.

Thanks,

How was this instance installed?

2 Likes

Hi Stephen,

We followed normal Discourse installation on Ubuntu16.04.
We installed docker-ce and clone discourse_docker.git in /var/discourse.

In our app.yml we are using the commit of Discourse 2.2.1
version: e9d1597f818dc6dbbd5b588310bcef799c5b25ed and latest postgres DB.

Until recently, the rebuild of Discourse was successful but yesterday I had to install a new plugin. The rebuild app is now failing with an error on the mini_racer.

You changed something and then it started failing? Does it work without the plugin?

Which plugin did you install?

Can you post the output of the build here, sanitized if necessary?

1 Like

Hi Michael,

It is not related to the update of our app.yml, because we are using 2 discourse installations.
One installation was not touched, the other installation was updated with the new plugin (GitHub - discourse/discourse-linkify-words: theme to auto linkify urls in discourse).
But unfortunately the rebuild app is now failing on both Discourse installations.

Here is the error message:

An error occurred while installing mini_racer (0.2.3), and Bundler cannot
continue.
Make sure that gem install mini_racer -v '0.2.3' --source 'https://rubygems.org/' succeeds before bundling.

In Gemfile:
mini_racer

I, [2019-05-08T15:07:05.470695 #14] INFO – : Terminating async processes
I, [2019-05-08T15:07:05.470756 #14] 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/10/bin/postmaster -D /etc/postgresql/10/main pid: 68
I, [2019-05-08T15:07:05.470823 #14] INFO – : Sending TERM to exec chpst -u redis -U redis /usr/bin/redis-server /etc/redis/redis.conf pid: 184
184:signal-handler (1557328025) Received SIGTERM scheduling shutdown…
2019-05-08 15:07:05.473 UTC [68] LOG: received fast shutdown request
2019-05-08 15:07:05.475 UTC [68] LOG: aborting any active transactions
2019-05-08 15:07:05.479 UTC [68] LOG: worker process: logical replication launcher (PID 77) exited with exit code 1
2019-05-08 15:07:05.479 UTC [72] LOG: shutting down
184:M 08 May 2019 15:07:05.499 # User requested shutdown…
184:M 08 May 2019 15:07:05.499 * Saving the final RDB snapshot before exiting.
184:M 08 May 2019 15:07:05.565 * DB saved on disk
184:M 08 May 2019 15:07:05.565 # Redis is now ready to exit, bye bye…
2019-05-08 15:07:05.573 UTC [68] LOG: database system is shut down

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

That is a theme!

Did you try to add that as a plugin in the app.yml ?

3 Likes

Yes we added the plugin in the app.yml as it should be

That is not a plugin, that is a theme.

Themes are installed in the web interface at /admin/customize/themes and can’t ever be added to the app.yml.

See:

4 Likes

Ok Rafael. As I said, the rebuild is failing in another Discourse installation where this plugin is not installed.

Are those 2 discourse installations running in the same machine? Are you pointing the stateful volume (/shared folder in the container) to different locations in the host?

containers/app1.yml:

volumes:
  - volume:
      host: /var/discourse/shared/app1
      guest: /shared
  - volume:
      host: /var/discourse/shared/app1/log/var-log
      guest: /var/log

containers/app2.yml:

volumes:
  - volume:
      host: /var/discourse/shared/app2
      guest: /shared
  - volume:
      host: /var/discourse/shared/app2/log/var-log
      guest: /var/log

(this is to make sure that both of your discourse instances are independent, because an error in one of them shouldn’t reflect in the other when nothing else changed)

I don’t think your setup is mapping to the same location both apps, after all I dont think it would even work.

In case they are pointing to different locations (what I assume), then the most probable cause that I can think of is some kind of conflict caused by a plugin.

Even if you haven’t added any plugins in your app.yml after your last rebuild that worked, when you execute the rebuild command, the latest version/commit of discourse is used and it may have conflicts with existing plugins.

What are your plugins? If you comment them and rebuild you have the same error?

There’s also a similar issue about problems when compiling mini-racer (although it was an older version, but may be related):

Are you using the tests-passed branch?

Hi Lucas,

We are using Discourse 2.2.1 on 2 servers (one is the main, the other the backup)

On my backup server, I completely deleted the DB and bootstrap discourse as a first install.
In the app.yml I provided the version of Discourse that I wanted to install.
I was not able to bootstrap discourse version 2.2.0, 2.2.1, 2.2.2, 2.2.3, 2.2.4, etc…until 2.3.0beta9 by providing the commit number.
The only successfull bootstrap of Discourse was using version: tests-passed

Which Git revision should this container use? (default: tests-passed)
version: tests-passed
#version: bbb4b6ccef45a791c6faee0a60eb7514439da9a7 #v2.2.0
#version: e9d1597f818dc6dbbd5b588310bcef799c5b25ed #v2.2.1
#version: 760d51cab1a7a0a1b2dce2997ef709a2f84a1d2c #v2.2.2
#version: d8c3c8234522bf39c70a2cece8d822ae34b730ff #v2.2.3
#version: 63dbac786fc4e9c575d12de6c5531a90f090555b #v2.2.4
#version: 3388cc092a12dffbc0c80b654dc13f7a2f7cfae7 #v2.3.0beta1
#version: 0e8dbbd8e48363e4a771de1c65dc5c8b4cdf282b #v2.3.0beta2
#version: 3d0008165f35df9a0895b7fb7e575071d47ffa22 #beta3
#version: 2ee02cb6c7fe86e31fc84cf1f6c4c49c6e91aadb #beta4
#version: 4f74210949ea8329c0c4c5b25d9eef081a6640c2 #beta5
#version: 6e2e095b53e2bb44811578ab6c2468ef10ba6513 #beta6
#version: 347e3e5a469f4be04a53b1366ef84cdc916dd27a #beta7
#version: d53cc07de164555968efff8b4b90b95adb4930a1 #beta8
#version: 84b21e3ad682baaeeb4f61200cf24fe0766a26fa #beta9

We absolutely need to be able to rebuild discourse 2.2.1.
Providing the commit number of the version we want to install is not working anymore (if we would like to upgrade from 2.2.1 to 2.2.2).

We get a mini_racer issue. How to fix it?

Thanks,
/Thierry

Can you try a new rebuild now @lmcthjo?

Just be sure that in the app.yml it must be:

  ## Which Git revision should this container use? (default: tests-passed)
  version: stable

if you want to run Discourse stable branch (currently 2.2.x).

5 Likes

Hi Rafael,

Thanks a lot! It is one of the solutions.

1.When using

## Which Git revision should this container use? (default: tests-passed)
version: stable

in app.yml, the rebuild app is working fine with no error. Discourse is nevertheless upgraded to latest stable version 2.2.5

2.I found another way by providing the mini_racer version in app.yml

# Fix for mini-racer error
- exec:
    cd: $home
    cmd:
      - sed -i "s/mini_racer .*/mini_racer (0.2.5)/" Gemfile.lock

I needed to specify latest version 0.2.5 otherwise rebuild app is failing with 0.2.3 or 0.2.4 (even if the error message tells to install mini_racer 0.2.3)

2 solutions. I have the choice now :blush:
Thanks for your quick support

2 Likes

I just tried to build on the beta branch and it’s failing. I guess this won’t be fixed (for beta instead of tests-passed) until the next beta bump? And presumably most people on beta won’t upgrade until then anyway, so maybe it won’t matter to many folks.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.