Closed Earlopain closed 6 months ago
Sorry, I'm generally pretty strongly -1 on changes that add codepaths we do not use/test ourselves (because we cannot make any promises about how well they will be supported and maintained over time).
In theory, you should be able to get this working by hand-crafting (probably via jq
) a new entry in versions.json
and running apply-templates.sh
to have the existing templates put out some Dockerfile
s that should build appropriately.
Oh baby, https://cache.ruby-lang.org/pub/ruby/snapshot/snapshot-master.json makes this even easier to implement because it matches the existing data format! :joy:
$ wget -qO- 'https://cache.ruby-lang.org/pub/ruby/snapshot/snapshot-master.json' | jq -s '.[1][0] as $master | .[0] | .master = (.["3.3"] as $donor | { version: "master" } + $master + { variants: $donor.variants, rust: $donor.rust, rustup: $donor.rustup } | with_entries(if .key == "filename" then .key = "url" | .value |= map_values("https://cache.ruby-lang.org/pub/ruby/snapshot/" + .) else . end))' versions.json - > versions.new.json
$ mv versions.new.json versions.json
$ ./apply-templates.sh master
...
$ docker build --pull master/bookworm
...
+ ruby --version
ruby 3.4.0dev (2024-04-26 master b6489e9f62) [x86_64-linux]
...
Successfully built fb95e684415b
$ docker run --rm fb95e684415b ruby --version
ruby 3.4.0dev (2024-04-26 master b6489e9f62) [x86_64-linux]
and just that jq
line again, but with more whitespace for better readability:
wget -qO- 'https://cache.ruby-lang.org/pub/ruby/snapshot/snapshot-master.json' \
| jq -s '
.[1][0] as $master
| .[0]
| .master = (
.["3.3"] as $donor
| { version: "master" }
+ $master
+ { variants: $donor.variants, rust: $donor.rust, rustup: $donor.rustup }
| with_entries(
if .key == "filename" then
.key = "url"
| .value |= map_values("https://cache.ruby-lang.org/pub/ruby/snapshot/" + .)
else . end
)
)
' versions.json - \
> versions.new.json
Edit:
The version file is pretty neat, I wasn't aware that it exists. Switching it out is indeed very easy. I've opted to go with a fork that builds these images daily on GitHub actions and pushes them to their container registry. Here's the workflow I ended up with: https://github.com/docker-ruby-nightly/ruby/blob/f682f975d682defdf22becf475945fca25aab95e/.github/workflows/nightly.yml, I can then use the image like so ghcr.io/docker-ruby-nightly/ruby:alpine3.19-nightly-2024-04-25
. I know in the linked issue there some thing that publishes as well but that doesn't do alpine.
It's missing a bunch I imagine, especially around the metadata I was very lazy. It just got a tag and that's it. Also not very multiarch friendly. But it's whatever, works for me.
Thanks again for your pointers on this. I'll go ahead and close this now.
This makes it possible to build against ruby master (as long as there are no additional changes that would need to be made)
I understand that as per #222 providing head images directly is not feasable. This makes it one step simpler to use these yourself if you want to. I believe it doesn't add too much complexity.
Due to the volatility of the nighly builds I added a build arg to skip the checksum check. It wouldn't really work that well otherwise.
A sample
docker-compose.yml
to demonstrate:It doesn't work for the 3.0 images since they have a different format but it's EOL anyways and soon to be removed I imagine.