You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
engines/<engine>:<version>: thin image, just the runtime; use this if you don't care what the underlying libc/OS userland is and just want a Ruby runtime at said version; today this is gnu-backed but could transparently become musl-backed in the future.
engines/<engine>:<version>-<libc>: thin image, just the runtime; use this if you care what the underlying libc is and just want a Ruby runtime at said version and on said libc.
engines/<engine>:<version>-<libc>-<compiler>: fat image, runtime+compiler+whatever necessary to build extensions; use this if you care what the underlying libc is and want a Ruby buildtime environment at said version and on said libc and with said compiler.
The goal is to be able to:
Reliably produce minimal images via multistage builds (e.g depend on FROM-gnu-gcc on a bundle install intermediate stage, then copy over /usr/loca/bundle to a final stage that FROMs just -gnu)
Be explicit about what a particular image consumer actually depends on
Maximise shared layers between images while minimising individual layer and image size
Since various repos and tooling use ruby:2.1 to ruby:3.2 and jruby-9.2 to jruby-9.4 and expect a compiler (i.e as if they were *-gnu-gcc) it was elected to have these "lie" and be aliases to -gnu-gcc for backwards compatibility.
This results in:
ruby:2.1-gnu-gcc to ruby:3.2-gnu-gcc, jruby-9.2-gnu-gcc to jruby-9.4-gnu-gcc
ruby:2.1-gnu to ruby:3.2-gnu, jruby-9.2-gnu to jruby-9.4-gnu, alias tags of the above
ruby:2.1 to ruby:3.2, jruby-9.2 to jruby-9.4, alias tags of the above
ruby:2.1-musl to ruby:3.2-musl, jruby-9.2-musl to jruby-9.4-musl, thin alpine-based images without compiler
ruby:2.1-musl-gcc to ruby:3.2-musl-gcc, jruby-9.2-musl-gcc to jruby-9.4-musl-gcc, based off of the above (FROM), with gcc
engines/<engine>:<version>-centos and engines/<engine>:<version>-centos-gcc follow the same aliasing as for gnu.
The targeted global generalisable pattern is:
engines/<engine>:<version>
: thin image, just the runtime; use this if you don't care what the underlying libc/OS userland is and just want a Ruby runtime at said version; today this isgnu
-backed but could transparently becomemusl
-backed in the future.engines/<engine>:<version>-<libc>
: thin image, just the runtime; use this if you care what the underlying libc is and just want a Ruby runtime at said version and on said libc.engines/<engine>:<version>-<libc>-<compiler>
: fat image, runtime+compiler+whatever necessary to build extensions; use this if you care what the underlying libc is and want a Ruby buildtime environment at said version and on said libc and with said compiler.The goal is to be able to:
FROM
-gnu-gcc
on abundle install
intermediate stage, then copy over/usr/loca/bundle
to a final stage thatFROM
s just-gnu
)Since various repos and tooling use
ruby:2.1
toruby:3.2
andjruby-9.2
tojruby-9.4
and expect a compiler (i.e as if they were*-gnu-gcc
) it was elected to have these "lie" and be aliases to-gnu-gcc
for backwards compatibility.This results in:
ruby:2.1-gnu-gcc
toruby:3.2-gnu-gcc
,jruby-9.2-gnu-gcc
tojruby-9.4-gnu-gcc
ruby:2.1-gnu
toruby:3.2-gnu
,jruby-9.2-gnu
tojruby-9.4-gnu
, alias tags of the aboveruby:2.1
toruby:3.2
,jruby-9.2
tojruby-9.4
, alias tags of the aboveruby:2.1-musl
toruby:3.2-musl
,jruby-9.2-musl
tojruby-9.4-musl
, thin alpine-based images without compilerruby:2.1-musl-gcc
toruby:3.2-musl-gcc
,jruby-9.2-musl-gcc
tojruby-9.4-musl-gcc
, based off of the above (FROM
), with gccengines/<engine>:<version>-centos
andengines/<engine>:<version>-centos-gcc
follow the same aliasing as forgnu
.Task is to make:
engines/<engine>:<version>-gnu
thinengines/<engine>:<version>-gnu-gcc
fatengines/<engine>:<version>-centos
thinengines/<engine>:<version>-centos-gcc
fatRequires: #26
The text was updated successfully, but these errors were encountered: