Quite! Strange, since I had never heard about either Gemfile or Gemfile.lock before. But having 20 other fora to repeat the install on (sigh), it turns out that the whole thing started with a different problem during install where the complaints ended with a recommendation to try deleting the Gemfile.lock:
Bundler found conflicting requirements for the Ruby version:
actionmailer (= 220.127.116.11) was resolved to 18.104.22.168, which depends on
Ruby (>= 2.7.0)
sassc-rails was resolved to 2.1.2, which depends on
sprockets-rails was resolved to 3.4.2, which depends on
Ruby (>= 2.5)
json was resolved to 2.6.3, which depends on
Ruby (>= 2.3)
json_schemer was resolved to 0.2.23, which depends on
ecma-re-validator (~> 0.3) was resolved to 0.4.0, which depends on
Ruby (>= 2.6, < 4.0)
rspec was resolved to 3.12.0, which depends on
rspec-expectations (~> 3.12.0) was resolved to 3.12.2, which depends on
diff-lcs (>= 1.2.0, < 2.0) was resolved to 1.5.0, which depends on
Ruby (>= 1.8)
web-push was resolved to 3.0.0, which depends on
Ruby (>= 3.0)
Current Ruby version:
Ruby (= 2.7.6)
Bundler could not find compatible versions for gem "hkdf":
In snapshot (Gemfile.lock):
hkdf (= 1.0.0)
web-push was resolved to 1.0.0, which depends on
hkdf (~> 0.2)
Deleting your Gemfile.lock file and running `bundle install` will rebuild your
snapshot from scratch, using only
the gems in your Gemfile, which may resolve the conflict.
So, I got past that initial error after removing the lock file as suggested, then ran into the NameError: undefined method ‘call’ described earlier. Fixed that by pegging the redis version. Then, everything worked.
So, my script was modified to a) remove Gemfile.lock (because of the error quoted above) and b) automatically change the Gemfile to peg redis at 4.8.0. Hunky dory… I thought. This worked on three out of the 20 “identical” machines! The rest gave this new error:
[discourse@in3020-discourse discourse]$ cd $INSTA; RAILS_ENV=production /usr/local/bin/bundle exec rake db:migrate # stuffing a lot of stuff into the database
NoMethodError: undefined method `logger=' for Sidekiq:Module
Did you mean? logger
/var/discourse/vendor/bundle/ruby/2.7.0/gems/railties-22.214.171.124/lib/rails/engine.rb:667:in `block in load_config_initializer'
/var/discourse/vendor/bundle/ruby/2.7.0/gems/railties-126.96.36.199/lib/rails/engine.rb:620:in `block (2 levels) in <class:Engine>'
/var/discourse/vendor/bundle/ruby/2.7.0/gems/railties-188.8.131.52/lib/rails/engine.rb:619:in `block in <class:Engine>'
/var/discourse/vendor/bundle/ruby/2.7.0/gems/railties-184.108.40.206/lib/rails/initializable.rb:61:in `block in run_initializers'
/var/discourse/vendor/bundle/ruby/2.7.0/gems/railties-220.127.116.11/lib/rails/application.rb:511:in `block in run_tasks_blocks'
/var/discourse/vendor/bundle/ruby/2.7.0/gems/rake-13.0.6/exe/rake:27:in `<top (required)>'
/usr/local/share/gems/gems/bundler-2.3.26/exe/bundle:48:in `block in <top (required)>'
/usr/local/share/gems/gems/bundler-2.3.26/exe/bundle:36:in `<top (required)>'
Tasks: TOP => db:migrate => db:load_config => environment
(See full trace by running task with --trace)
Which was really, really strange because the /var/discourse/config/initializers/100-sidekiq.rb files were identical on all machines, and certainly did not contain ‘logger=’, but a ‘logger = …’ statement.
I finally figured out that on the machines where it worked, /usr/local/bin/bundle was version 2.3.20, not 2.3.26 as on the machines where it failed. So in sum, adding this before the install command for discourse did the trick for me (it was not enough to do the bundler pegging at 2.3.20 commands after the bundler install of discourse, it had to be before):
perl -pi.bak -e 's/gem "redis"/gem "redis","4.8.0"/;' Gemfile
/usr/bin/gem uninstall bundler -v 2.3.26
/usr/bin/gem install bundler -v 2.3.20
RAILS_ENV=production /usr/local/bin/bundle install
RAILS_ENV=production /usr/local/bin/bundle exec rake db:migrate
RAILS_ENV=production /usr/local/bin/bundle exec rake assets:precompile
Why on Earth some of those machines had bundler 2.3.26 and others had 2.3.20 I have no idea… but it’s probably not your fault .