Bug #21501
closeddebian11 package build Dockerfile fails installing dotenv gem
Description
dotenv 3.0 was released yesterday. Because of that, with a freshly pulled bullseye-slim image:
$ ./run-build-test-packages-one-target.sh --target debian11 --arch amd64 --only-build python3-arvados-python-client --force-build --force-test … Install of ruby-2.7.2 - #complete Ruby was built without documentation, to build it run: rvm docs generate-ri Creating alias default for ruby-2.7.2... Successfully installed bundler-2.2.19 1 gem installed ERROR: Error installing fpm: The last version of dotenv (>= 0) to support your Ruby & RubyGems was 2.8.1. Try installing it with `gem install dotenv -v 2.8.1` and then running the current command again dotenv requires Ruby version >= 3.0. The current ruby version is 2.7.2.137. Successfully installed stud-0.0.23 The command '/bin/bash -c gpg --import --no-tty /tmp/mpapis.asc && gpg --import --no-tty /tmp/pkuczynski.asc && curl -L https://get.rvm.io | bash -s stable && /usr/local/rvm/bin/rvm install 2.7 -j $(grep -c processor /proc/cpuinfo) --disable-binary && /usr/local/rvm/bin/rvm alias create default ruby-2.7 && echo "gem: --no-document" >> ~/.gemrc && /usr/local/rvm/bin/rvm-exec default gem install bundler --version 2.2.19 && /usr/local/rvm/bin/rvm-exec default gem install fpm --version 1.15.1' returned a non-zero code: 1
I assume this problem applies to every Docker image where we install Ruby 2.7. Note this happens before we run any Arvados code, so the fix has to go in the Dockerfile. (In other words, while this looks a lot like #21384, we can't fix it the same way.)
Updated by Brett Smith 9 months ago
21501-pin-dotenv @ b6aef1869e3fa5a8f7f87b551fa68592b43756ac - build-packages-multijob: #3989
- All agreed upon points are implemented / addressed.
- Yes
- Anything not implemented (discovered or discussed during work) has a follow-up story.
- This did inspire me to write up #21522. But that's only tangentially related, so in the interests of fixing our build as quickly as possible, I didn't tackle it here.
- Code is tested and passing, both automated and manual, what manual testing was done is described
- See above. I also built and tested a package on debian11 on my local system before running the Jenkins job.
- Documentation has been updated.
- N/A
- Behaves appropriately at the intended scale (describe intended scale).
- No change in scale
- Considered backwards and forwards compatibility issues between client and server.
- N/A
- Follows our coding standards and GUI style guidelines.
- Yes
Updated by Tom Clegg 9 months ago
- Status changed from New to In Progress
LGTM.
It occurred to me that a newer version of bundler could potentially know how to resolve this sort of thing automatically. I haven't looked into it.
arvbox updated to bundler 2.4.22 in 485488b8f975fb75daf77a4fad72d3d9d05cd611 but (I think) all the rest of our stuff is still synchronized at 2.2.19. Should "see if upgrading bundler to 2.4.22 or beyond could fix this and future episodes of the same problem" be a follow-up ticket to try?
Updated by Brett Smith 9 months ago
Tom Clegg wrote in #note-4:
arvbox updated to bundler 2.4.22 in 485488b8f975fb75daf77a4fad72d3d9d05cd611 but (I think) all the rest of our stuff is still synchronized at 2.2.19. Should "see if upgrading bundler to 2.4.22 or beyond could fix this and future episodes of the same problem" be a follow-up ticket to try?
I'm basically always in favor of upgrading stuff, but I'm not sure how it would help with the specific problem this branch has? fpm
gets installed with a raw gem install
, outside any bundler environment.
Updated by Brett Smith 9 months ago
- % Done changed from 0 to 100
- Status changed from In Progress to Resolved
Applied in changeset arvados|acb5cbe8fb3524e18e31d0bbc5e9a3a80936a771.