Discourse_docker: launcher boostrap fails (workaround included)

[m.abi (Michael A.)]

Bootstraping a fresh container image fails. Some days ago it worked, “nothing changed”, today it fails. Log:

[0:02:27] Still working on:
[0:02:27]   v8
________ running 'vpython third_party/depot_tools/update_depot_tools_toggle.py
--disable' in
'/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/libv8-8.4.255.0/vendor'
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/libv8-8.4.255.0/vendor/depot_tools/.cipd_bin/.cipd/pkgs/0/fI6WggdkRyN1r91MnTeApc2_gyTtXfYpueHZVLcaF8gC/vpython:
could not resolve options: failed to resolve Python script: stat
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/libv8-8.4.255.0/vendor/third_party/depot_tools/update_depot_tools_toggle.py:
no such file or directory
Error: Command 'vpython third_party/depot_tools/update_depot_tools_toggle.py
--disable' returned non-zero exit status 1 in
/var/www/discourse/vendor/bundle/ruby/2.7.0/gems/libv8-8.4.255.0/vendor

...

** 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.

Digging into it: For libv8 there is already a similar problem reported on github, related to a version change in the ruby builder. During bootstraping, an upgrade of builder is performed. I think the problem seems to be related to the version 2.2.15 of bundler (released yesterday). To be honest: I’m not a ruby guy, so maybe the real issue is slightly different.

However, the following workaround worked for me: Change line 148 in templates/web.template.yml from
- gem update bundler
to
- gem install bundler -v 2.2.14

Best,

Michael

[Falco (Rafael dos Santos Silva)]

Was this when trying to build on the stable branch?

[m.abi (Michael A.)]

Good point! master branch from discourse_docker, params: version: stable in app.yml

[pfaffman (Jay Pfaffman)]

Unless you have a reason to run stable and are willing to pay extra attention to some stuff (like this problem) you’ll be better off on tests-passed, it’s much better tested and the one that Discourse uses for their hosting.

[sam (Sam Saffron)]

This is certainly worth debugging, if bundler just released a bug we want a workaround in place quickly.

@kris.kotlarek can you repro the issue on digital ocean?

[david (David Taylor)]

There are a number of issues at play here. For now, the smoothest solution is to bump the Gemfile version in stable. See the commit message for more details:

https://github.com/discourse/discourse/commit/5dbac4e58ec1055e2b1688f1e195f52540851266

@m.abi please try rebuilding again - it should work work now

[mentalstring (Paulo)]

@pfaffman

Unless you have a reason to run stable and are willing to pay extra attention to some stuff

I expect that one running on the stable to get more, well, stability — ideally security fixes and little else. At least that’s our interpretation of the stable branch. And not that one needs to pay more attention on stable because it might break more often that the bleeding edge.

[pfaffman (Jay Pfaffman)]

@mentalstring

And not that one needs to pay more attention on stable because it might break more often that the bleeding edge.

Well, as this case shows, it’s somewhat less like that than you might expect. They do a good job of fixing stuff up quickly (like this one), but they (mostly?) don’t stable on their own hosting, so it’s somewhat less well tested than tests-passed, so except right when there’s a new stable release, I consider tests-passed a somewhat “safer” bet. Not everyone agrees.

[m.abi (Michael A.)]

@david Build works! Thank you!