Add musl images

- `musl` is "slim" compilerless
- `gcc` and `clang` add build elements with respective compilers to the above

src/engines/jruby/9.2/Dockerfile.musl

@@ -0,0 +1,50 @@
+FROM eclipse-temurin:22-jdk-alpine AS jruby-9.2.21.0-jre22
+
+# A few RUN actions in Dockerfiles are subject to uncontrollable outside
+# variability: an identical command would be the same from `docker build`'s
+# point of view but does not indicate the result would be identical at
+# different points in time.
+#
+# This causes two possible issues:
+#
+# - one wants to capture a new state and so wants the identical
+#   non-reproducible command to produce a new result. This could be achieved
+#   with --no-cache but this affects every single operation in a Dockerfile
+# - one wants to identify a specific state and leverage caching at that
+#   specific state.
+#
+# To that end a BUILD_ARG is introduced to capture an arbitrary identifier of
+# that state (typically time) that is introduced in non-reproducible commands
+# to make them appear different to Docker.
+#
+# Of course it only works when caching data is available: two independent
+# builds with the same value and no cache shared would produce different
+# results.
+ARG REPRO_RUN_KEY=0
+
+# `apk update` is uncontrolled and fetches whatever is today's index.
+# For the sake of reproducibility subsequent steps (including in dependent
+# images) should not do `apk update`, instead this base image should be
+# updated by changing the `REPRO_RUN_KEY`.
+RUN true "${REPRO_RUN_KEY}" && apk update
+
+# Add a few packages for consistency
+RUN apk add curl bash
+
+# Install JRuby, pinned for reproducibility
+ENV JRUBY_VERSION 9.2.21.0
+ENV JRUBY_SHA256 dbf05fca4f61bd7d5131d9b83c5f4d1a249213c474b82def37e82013969c8b8a
+RUN mkdir /opt/jruby \
+ && curl -fSL https://repo1.maven.org/maven2/org/jruby/jruby-dist/${JRUBY_VERSION}/jruby-dist-${JRUBY_VERSION}-bin.tar.gz -o /tmp/jruby.tar.gz \
+ && echo "$JRUBY_SHA256 /tmp/jruby.tar.gz" | sha256sum -c - \
+ && tar -zx --strip-components=1 -f /tmp/jruby.tar.gz -C /opt/jruby \
+ && rm /tmp/jruby.tar.gz \
+ && ln -sf /opt/jruby/bin/jruby /usr/local/bin/ruby
+ENV PATH /opt/jruby/bin:$PATH
+
+# Skip installing gem documentation
+RUN mkdir -p /opt/jruby/etc \
+ && echo -e 'install: --no-document\nupdate: --no-document' >> /opt/jruby/etc/gemrc
+
+# Start IRB as a default
+CMD [ "irb" ]

src/engines/jruby/9.2/Dockerfile.musl.clang

@@ -0,0 +1,3 @@
+FROM ghcr.io/datadog/images-rb/engines/jruby:9.2-musl
+
+RUN apk add binutils file fortify-headers make musl-dev clang

src/engines/jruby/9.2/Dockerfile.musl.gcc

@@ -0,0 +1,3 @@
+FROM ghcr.io/datadog/images-rb/engines/jruby:9.2-musl
+
+RUN apk add binutils file fortify-headers make musl-dev gcc g++

src/engines/jruby/9.3/Dockerfile.musl

@@ -0,0 +1,50 @@
+FROM eclipse-temurin:22-jdk-alpine AS jruby-9.3.9.0-jre22
+
+# A few RUN actions in Dockerfiles are subject to uncontrollable outside
+# variability: an identical command would be the same from `docker build`'s
+# point of view but does not indicate the result would be identical at
+# different points in time.
+#
+# This causes two possible issues:
+#
+# - one wants to capture a new state and so wants the identical
+#   non-reproducible command to produce a new result. This could be achieved
+#   with --no-cache but this affects every single operation in a Dockerfile
+# - one wants to identify a specific state and leverage caching at that
+#   specific state.
+#
+# To that end a BUILD_ARG is introduced to capture an arbitrary identifier of
+# that state (typically time) that is introduced in non-reproducible commands
+# to make them appear different to Docker.
+#
+# Of course it only works when caching data is available: two independent
+# builds with the same value and no cache shared would produce different
+# results.
+ARG REPRO_RUN_KEY=0
+
+# `apk update` is uncontrolled and fetches whatever is today's index.
+# For the sake of reproducibility subsequent steps (including in dependent
+# images) should not do `apk update`, instead this base image should be
+# updated by changing the `REPRO_RUN_KEY`.
+RUN true "${REPRO_RUN_KEY}" && apk update
+
+# Add a few packages for consistency
+RUN apk add curl bash
+
+# Install JRuby, pinned for reproducibility
+ENV JRUBY_VERSION 9.3.9.0
+ENV JRUBY_SHA256 251e6dd8d1d2f82922c8c778d7857e1bef82fe5ca2cf77bc09356421d0b05ab8
+RUN mkdir /opt/jruby \
+ && curl -fSL https://repo1.maven.org/maven2/org/jruby/jruby-dist/${JRUBY_VERSION}/jruby-dist-${JRUBY_VERSION}-bin.tar.gz -o /tmp/jruby.tar.gz \
+ && echo "$JRUBY_SHA256 /tmp/jruby.tar.gz" | sha256sum -c - \
+ && tar -zx --strip-components=1 -f /tmp/jruby.tar.gz -C /opt/jruby \
+ && rm /tmp/jruby.tar.gz \
+ && ln -sf /opt/jruby/bin/jruby /usr/local/bin/ruby
+ENV PATH /opt/jruby/bin:$PATH
+
+# Skip installing gem documentation
+RUN mkdir -p /opt/jruby/etc \
+ && echo -e 'install: --no-document\nupdate: --no-document' >> /opt/jruby/etc/gemrc
+
+# Start IRB as a default
+CMD [ "irb" ]

src/engines/jruby/9.3/Dockerfile.musl.clang

@@ -0,0 +1,3 @@
+FROM ghcr.io/datadog/images-rb/engines/jruby:9.3-musl
+
+RUN apk add binutils file fortify-headers make musl-dev clang

src/engines/jruby/9.3/Dockerfile.musl.gcc

@@ -0,0 +1,3 @@
+FROM ghcr.io/datadog/images-rb/engines/jruby:9.3-musl
+
+RUN apk add binutils file fortify-headers make musl-dev gcc g++

src/engines/jruby/9.4/Dockerfile.musl

@@ -0,0 +1,50 @@
+FROM eclipse-temurin:22-jdk-alpine AS jruby-9.4.7.0-jre22
+
+# A few RUN actions in Dockerfiles are subject to uncontrollable outside
+# variability: an identical command would be the same from `docker build`'s
+# point of view but does not indicate the result would be identical at
+# different points in time.
+#
+# This causes two possible issues:
+#
+# - one wants to capture a new state and so wants the identical
+#   non-reproducible command to produce a new result. This could be achieved
+#   with --no-cache but this affects every single operation in a Dockerfile
+# - one wants to identify a specific state and leverage caching at that
+#   specific state.
+#
+# To that end a BUILD_ARG is introduced to capture an arbitrary identifier of
+# that state (typically time) that is introduced in non-reproducible commands
+# to make them appear different to Docker.
+#
+# Of course it only works when caching data is available: two independent
+# builds with the same value and no cache shared would produce different
+# results.
+ARG REPRO_RUN_KEY=0
+
+# `apk update` is uncontrolled and fetches whatever is today's index.
+# For the sake of reproducibility subsequent steps (including in dependent
+# images) should not do `apk update`, instead this base image should be
+# updated by changing the `REPRO_RUN_KEY`.
+RUN true "${REPRO_RUN_KEY}" && apk update
+
+# Add a few packages for consistency
+RUN apk add curl bash
+
+# Install JRuby, pinned for reproducibility
+ENV JRUBY_VERSION 9.4.7.0
+ENV JRUBY_SHA256 f1c39f8257505300a528ff83fe4721fbe61a855abb25e3d27d52d43ac97a4d80
+RUN mkdir /opt/jruby \
+ && curl -fSL https://repo1.maven.org/maven2/org/jruby/jruby-dist/${JRUBY_VERSION}/jruby-dist-${JRUBY_VERSION}-bin.tar.gz -o /tmp/jruby.tar.gz \
+ && echo "$JRUBY_SHA256 /tmp/jruby.tar.gz" | sha256sum -c - \
+ && tar -zx --strip-components=1 -f /tmp/jruby.tar.gz -C /opt/jruby \
+ && rm /tmp/jruby.tar.gz \
+ && ln -sf /opt/jruby/bin/jruby /usr/local/bin/ruby
+ENV PATH /opt/jruby/bin:$PATH
+
+# Skip installing gem documentation
+RUN mkdir -p /opt/jruby/etc \
+ && echo -e 'install: --no-document\nupdate: --no-document' >> /opt/jruby/etc/gemrc
+
+# Start IRB as a default
+CMD [ "irb" ]

src/engines/jruby/9.4/Dockerfile.musl.clang

@@ -0,0 +1,3 @@
+FROM ghcr.io/datadog/images-rb/engines/jruby:9.4-musl
+
+RUN apk add binutils file fortify-headers make musl-dev clang

src/engines/jruby/9.4/Dockerfile.musl.gcc

@@ -0,0 +1,3 @@
+FROM ghcr.io/datadog/images-rb/engines/jruby:9.4-musl
+
+RUN apk add binutils file fortify-headers make musl-dev gcc g++

src/engines/ruby/2.1/Dockerfile.musl

@@ -0,0 +1,29 @@
+FROM ruby:2.1-alpine
+
+# A few RUN actions in Dockerfiles are subject to uncontrollable outside
+# variability: an identical command would be the same from `docker build`'s
+# point of view but does not indicate the result would be identical at
+# different points in time.
+#
+# This causes two possible issues:
+#
+# - one wants to capture a new state and so wants the identical
+#   non-reproducible command to produce a new result. This could be achieved
+#   with --no-cache but this affects every single operation in a Dockerfile
+# - one wants to identify a specific state and leverage caching at that
+#   specific state.
+#
+# To that end a BUILD_ARG is introduced to capture an arbitrary identifier of
+# that state (typically time) that is introduced in non-reproducible commands
+# to make them appear different to Docker.
+#
+# Of course it only works when caching data is available: two independent
+# builds with the same value and no cache shared would produce different
+# results.
+ARG REPRO_RUN_KEY=0
+
+# `apk update` is uncontrolled and fetches whatever is today's index.
+# For the sake of reproducibility subsequent steps (including in dependent
+# images) should not do `apk update`, instead this base image should be
+# updated by changing the `REPRO_RUN_KEY`.
+RUN true "${REPRO_RUN_KEY}" && apk update

src/engines/ruby/2.1/Dockerfile.musl.clang

@@ -0,0 +1,3 @@
+FROM ghcr.io/datadog/images-rb/engines/ruby:2.1-musl
+
+RUN apk add binutils file fortify-headers make musl-dev clang

src/engines/ruby/2.1/Dockerfile.musl.gcc

@@ -0,0 +1,3 @@
+FROM ghcr.io/datadog/images-rb/engines/ruby:2.1-musl
+
+RUN apk add binutils file fortify-headers make musl-dev gcc g++

src/engines/ruby/2.2/Dockerfile.musl

@@ -0,0 +1,30 @@
+# platforms: linux/x86_64
+FROM ruby:2.2-alpine
+
+# A few RUN actions in Dockerfiles are subject to uncontrollable outside
+# variability: an identical command would be the same from `docker build`'s
+# point of view but does not indicate the result would be identical at
+# different points in time.
+#
+# This causes two possible issues:
+#
+# - one wants to capture a new state and so wants the identical
+#   non-reproducible command to produce a new result. This could be achieved
+#   with --no-cache but this affects every single operation in a Dockerfile
+# - one wants to identify a specific state and leverage caching at that
+#   specific state.
+#
+# To that end a BUILD_ARG is introduced to capture an arbitrary identifier of
+# that state (typically time) that is introduced in non-reproducible commands
+# to make them appear different to Docker.
+#
+# Of course it only works when caching data is available: two independent
+# builds with the same value and no cache shared would produce different
+# results.
+ARG REPRO_RUN_KEY=0
+
+# `apk update` is uncontrolled and fetches whatever is today's index.
+# For the sake of reproducibility subsequent steps (including in dependent
+# images) should not do `apk update`, instead this base image should be
+# updated by changing the `REPRO_RUN_KEY`.
+RUN true "${REPRO_RUN_KEY}" && apk update

src/engines/ruby/2.2/Dockerfile.musl.clang

@@ -0,0 +1,3 @@
+FROM ghcr.io/datadog/images-rb/engines/ruby:2.2-musl
+
+RUN apk add binutils file fortify-headers make musl-dev clang

src/engines/ruby/2.2/Dockerfile.musl.gcc

@@ -0,0 +1,3 @@
+FROM ghcr.io/datadog/images-rb/engines/ruby:2.2-musl
+
+RUN apk add binutils file fortify-headers make musl-dev gcc g++

src/engines/ruby/2.3/Dockerfile.musl

@@ -0,0 +1,29 @@
+FROM ruby:2.3-alpine
+
+# A few RUN actions in Dockerfiles are subject to uncontrollable outside
+# variability: an identical command would be the same from `docker build`'s
+# point of view but does not indicate the result would be identical at
+# different points in time.
+#
+# This causes two possible issues:
+#
+# - one wants to capture a new state and so wants the identical
+#   non-reproducible command to produce a new result. This could be achieved
+#   with --no-cache but this affects every single operation in a Dockerfile
+# - one wants to identify a specific state and leverage caching at that
+#   specific state.
+#
+# To that end a BUILD_ARG is introduced to capture an arbitrary identifier of
+# that state (typically time) that is introduced in non-reproducible commands
+# to make them appear different to Docker.
+#
+# Of course it only works when caching data is available: two independent
+# builds with the same value and no cache shared would produce different
+# results.
+ARG REPRO_RUN_KEY=0
+
+# `apk update` is uncontrolled and fetches whatever is today's index.
+# For the sake of reproducibility subsequent steps (including in dependent
+# images) should not do `apk update`, instead this base image should be
+# updated by changing the `REPRO_RUN_KEY`.
+RUN true "${REPRO_RUN_KEY}" && apk update

src/engines/ruby/2.3/Dockerfile.musl.clang

@@ -0,0 +1,3 @@
+FROM ghcr.io/datadog/images-rb/engines/ruby:2.3-musl
+
+RUN apk add binutils file fortify-headers make musl-dev clang

src/engines/ruby/2.3/Dockerfile.musl.gcc

@@ -0,0 +1,3 @@
+FROM ghcr.io/datadog/images-rb/engines/ruby:2.3-musl
+
+RUN apk add binutils file fortify-headers make musl-dev gcc g++

src/engines/ruby/2.4/Dockerfile.musl

@@ -0,0 +1,29 @@
+FROM ruby:2.4-alpine
+
+# A few RUN actions in Dockerfiles are subject to uncontrollable outside
+# variability: an identical command would be the same from `docker build`'s
+# point of view but does not indicate the result would be identical at
+# different points in time.
+#
+# This causes two possible issues:
+#
+# - one wants to capture a new state and so wants the identical
+#   non-reproducible command to produce a new result. This could be achieved
+#   with --no-cache but this affects every single operation in a Dockerfile
+# - one wants to identify a specific state and leverage caching at that
+#   specific state.
+#
+# To that end a BUILD_ARG is introduced to capture an arbitrary identifier of
+# that state (typically time) that is introduced in non-reproducible commands
+# to make them appear different to Docker.
+#
+# Of course it only works when caching data is available: two independent
+# builds with the same value and no cache shared would produce different
+# results.
+ARG REPRO_RUN_KEY=0
+
+# `apk update` is uncontrolled and fetches whatever is today's index.
+# For the sake of reproducibility subsequent steps (including in dependent
+# images) should not do `apk update`, instead this base image should be
+# updated by changing the `REPRO_RUN_KEY`.
+RUN true "${REPRO_RUN_KEY}" && apk update

src/engines/ruby/2.4/Dockerfile.musl.clang

@@ -0,0 +1,3 @@
+FROM ghcr.io/datadog/images-rb/engines/ruby:2.4-musl
+
+RUN apk add binutils file fortify-headers make musl-dev clang

src/engines/ruby/2.4/Dockerfile.musl.gcc

@@ -0,0 +1,3 @@
+FROM ghcr.io/datadog/images-rb/engines/ruby:2.4-musl
+
+RUN apk add binutils file fortify-headers make musl-dev gcc g++

src/engines/ruby/2.5/Dockerfile.musl

@@ -0,0 +1,29 @@
+FROM ruby:2.5-alpine
+
+# A few RUN actions in Dockerfiles are subject to uncontrollable outside
+# variability: an identical command would be the same from `docker build`'s
+# point of view but does not indicate the result would be identical at
+# different points in time.
+#
+# This causes two possible issues:
+#
+# - one wants to capture a new state and so wants the identical
+#   non-reproducible command to produce a new result. This could be achieved
+#   with --no-cache but this affects every single operation in a Dockerfile
+# - one wants to identify a specific state and leverage caching at that
+#   specific state.
+#
+# To that end a BUILD_ARG is introduced to capture an arbitrary identifier of
+# that state (typically time) that is introduced in non-reproducible commands
+# to make them appear different to Docker.
+#
+# Of course it only works when caching data is available: two independent
+# builds with the same value and no cache shared would produce different
+# results.
+ARG REPRO_RUN_KEY=0
+
+# `apk update` is uncontrolled and fetches whatever is today's index.
+# For the sake of reproducibility subsequent steps (including in dependent
+# images) should not do `apk update`, instead this base image should be
+# updated by changing the `REPRO_RUN_KEY`.
+RUN true "${REPRO_RUN_KEY}" && apk update

src/engines/ruby/2.5/Dockerfile.musl.clang

@@ -0,0 +1,3 @@
+FROM ghcr.io/datadog/images-rb/engines/ruby:2.5-musl
+
+RUN apk add binutils file fortify-headers make musl-dev clang

src/engines/ruby/2.5/Dockerfile.musl.gcc

@@ -0,0 +1,3 @@
+FROM ghcr.io/datadog/images-rb/engines/ruby:2.5-musl
+
+RUN apk add binutils file fortify-headers make musl-dev gcc g++

src/engines/ruby/2.6/Dockerfile.musl

@@ -0,0 +1,29 @@
+FROM ruby:2.6-alpine
+
+# A few RUN actions in Dockerfiles are subject to uncontrollable outside
+# variability: an identical command would be the same from `docker build`'s
+# point of view but does not indicate the result would be identical at
+# different points in time.
+#
+# This causes two possible issues:
+#
+# - one wants to capture a new state and so wants the identical
+#   non-reproducible command to produce a new result. This could be achieved
+#   with --no-cache but this affects every single operation in a Dockerfile
+# - one wants to identify a specific state and leverage caching at that
+#   specific state.
+#
+# To that end a BUILD_ARG is introduced to capture an arbitrary identifier of
+# that state (typically time) that is introduced in non-reproducible commands
+# to make them appear different to Docker.
+#
+# Of course it only works when caching data is available: two independent
+# builds with the same value and no cache shared would produce different
+# results.
+ARG REPRO_RUN_KEY=0
+
+# `apk update` is uncontrolled and fetches whatever is today's index.
+# For the sake of reproducibility subsequent steps (including in dependent
+# images) should not do `apk update`, instead this base image should be
+# updated by changing the `REPRO_RUN_KEY`.
+RUN true "${REPRO_RUN_KEY}" && apk update