I’ve noticed that container builds are currently broken due to the usage of Fedora34 in the image, as I was fixing the small issues in updating it (add F34 compatability · ohadlevy/foreman@adf9584 · GitHub), I’ve got the following error:
Bundler found conflicting requirements for the Ruby version: In Gemfile: Ruby bullet (>= 6.1.0) was resolved to 6.1.4, which depends on Ruby (>= 2.3) fog-google (~> 1.11.0) was resolved to 1.11.0, which depends on Ruby (~> 2.0) gettext_i18n_rails (~> 1.8) was resolved to 1.8.1, which depends on Ruby (>= 2.1.0) mocha (~> 1.11) was resolved to 1.12.0, which depends on Ruby (>= 1.8.7) net-ssh (= 4.2.0) was resolved to 4.2.0, which depends on Ruby (>= 2.0) pry was resolved to 0.14.1, which depends on Ruby (>= 1.9.3) puma (~> 5.1) was resolved to 5.3.2, which depends on Ruby (>= 2.2) rails (~> 6.0.3.1) was resolved to 6.0.3.7, which depends on Ruby (>= 2.5.0) sidekiq (~> 5.0) was resolved to 5.2.9, which depends on Ruby (>= 2.2.2) Bundler could not find compatible versions for gem "rails": In Gemfile: rails (~> 6.0.3.1) apipie-rails (>= 0.5.17, < 0.6.0) was resolved to 0.5.18, which depends on rails (>= 4.1) 6/16/2021, 6:15:04 AM
thanks for the feedback, indeed dev deps are showing up, not sure why, i can reproduce this with vanilla f34…will hopefully find some time to look into it… thanks, this to me seems like a bug in bundler.
It looks like a week ago fog-google 1.14.0 was released but the ~> 1.11.0 pin doesn’t allow this version.
Bundler always retrieves metadata for all the gems mentioned in gemspec etc, even if the group excludes it. I think the reason is that it allows turning groups on/off easily. That’s also why it always does a git clone even for gems that are in a group that’s disabled.