From 5e4a3dc74abdc472ed9e7788dc72ef07dbfbf625 Mon Sep 17 00:00:00 2001 From: Loic Nageleisen Date: Thu, 14 Nov 2024 10:38:35 +0100 Subject: [PATCH] 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 | 50 +++++++++++++++++++++ src/engines/jruby/9.2/Dockerfile.musl.clang | 3 ++ src/engines/jruby/9.2/Dockerfile.musl.gcc | 3 ++ src/engines/jruby/9.3/Dockerfile.musl | 50 +++++++++++++++++++++ src/engines/jruby/9.3/Dockerfile.musl.clang | 3 ++ src/engines/jruby/9.3/Dockerfile.musl.gcc | 3 ++ src/engines/jruby/9.4/Dockerfile.musl | 50 +++++++++++++++++++++ src/engines/jruby/9.4/Dockerfile.musl.clang | 3 ++ src/engines/jruby/9.4/Dockerfile.musl.gcc | 3 ++ src/engines/ruby/2.1/Dockerfile.musl | 29 ++++++++++++ src/engines/ruby/2.1/Dockerfile.musl.clang | 3 ++ src/engines/ruby/2.1/Dockerfile.musl.gcc | 3 ++ src/engines/ruby/2.2/Dockerfile.musl | 30 +++++++++++++ src/engines/ruby/2.2/Dockerfile.musl.clang | 3 ++ src/engines/ruby/2.2/Dockerfile.musl.gcc | 3 ++ src/engines/ruby/2.3/Dockerfile.musl | 29 ++++++++++++ src/engines/ruby/2.3/Dockerfile.musl.clang | 3 ++ src/engines/ruby/2.3/Dockerfile.musl.gcc | 3 ++ src/engines/ruby/2.4/Dockerfile.musl | 29 ++++++++++++ src/engines/ruby/2.4/Dockerfile.musl.clang | 3 ++ src/engines/ruby/2.4/Dockerfile.musl.gcc | 3 ++ src/engines/ruby/2.5/Dockerfile.musl | 29 ++++++++++++ src/engines/ruby/2.5/Dockerfile.musl.clang | 3 ++ src/engines/ruby/2.5/Dockerfile.musl.gcc | 3 ++ src/engines/ruby/2.6/Dockerfile.musl | 29 ++++++++++++ src/engines/ruby/2.6/Dockerfile.musl.clang | 3 ++ src/engines/ruby/2.6/Dockerfile.musl.gcc | 3 ++ src/engines/ruby/2.7/Dockerfile.musl | 29 ++++++++++++ src/engines/ruby/2.7/Dockerfile.musl.clang | 3 ++ src/engines/ruby/2.7/Dockerfile.musl.gcc | 3 ++ src/engines/ruby/3.0/Dockerfile.musl | 29 ++++++++++++ src/engines/ruby/3.0/Dockerfile.musl.clang | 3 ++ src/engines/ruby/3.0/Dockerfile.musl.gcc | 3 ++ src/engines/ruby/3.1/Dockerfile.musl | 29 ++++++++++++ src/engines/ruby/3.1/Dockerfile.musl.clang | 3 ++ src/engines/ruby/3.1/Dockerfile.musl.gcc | 3 ++ src/engines/ruby/3.2/Dockerfile.musl | 29 ++++++++++++ src/engines/ruby/3.2/Dockerfile.musl.clang | 3 ++ src/engines/ruby/3.2/Dockerfile.musl.gcc | 3 ++ src/engines/ruby/3.3/Dockerfile.musl | 29 ++++++++++++ src/engines/ruby/3.3/Dockerfile.musl.clang | 3 ++ src/engines/ruby/3.3/Dockerfile.musl.gcc | 3 ++ src/engines/ruby/3.4/Dockerfile.musl | 29 ++++++++++++ src/engines/ruby/3.4/Dockerfile.musl.clang | 3 ++ src/engines/ruby/3.4/Dockerfile.musl.gcc | 3 ++ 45 files changed, 589 insertions(+) create mode 100644 src/engines/jruby/9.2/Dockerfile.musl create mode 100644 src/engines/jruby/9.2/Dockerfile.musl.clang create mode 100644 src/engines/jruby/9.2/Dockerfile.musl.gcc create mode 100644 src/engines/jruby/9.3/Dockerfile.musl create mode 100644 src/engines/jruby/9.3/Dockerfile.musl.clang create mode 100644 src/engines/jruby/9.3/Dockerfile.musl.gcc create mode 100644 src/engines/jruby/9.4/Dockerfile.musl create mode 100644 src/engines/jruby/9.4/Dockerfile.musl.clang create mode 100644 src/engines/jruby/9.4/Dockerfile.musl.gcc create mode 100644 src/engines/ruby/2.1/Dockerfile.musl create mode 100644 src/engines/ruby/2.1/Dockerfile.musl.clang create mode 100644 src/engines/ruby/2.1/Dockerfile.musl.gcc create mode 100644 src/engines/ruby/2.2/Dockerfile.musl create mode 100644 src/engines/ruby/2.2/Dockerfile.musl.clang create mode 100644 src/engines/ruby/2.2/Dockerfile.musl.gcc create mode 100644 src/engines/ruby/2.3/Dockerfile.musl create mode 100644 src/engines/ruby/2.3/Dockerfile.musl.clang create mode 100644 src/engines/ruby/2.3/Dockerfile.musl.gcc create mode 100644 src/engines/ruby/2.4/Dockerfile.musl create mode 100644 src/engines/ruby/2.4/Dockerfile.musl.clang create mode 100644 src/engines/ruby/2.4/Dockerfile.musl.gcc create mode 100644 src/engines/ruby/2.5/Dockerfile.musl create mode 100644 src/engines/ruby/2.5/Dockerfile.musl.clang create mode 100644 src/engines/ruby/2.5/Dockerfile.musl.gcc create mode 100644 src/engines/ruby/2.6/Dockerfile.musl create mode 100644 src/engines/ruby/2.6/Dockerfile.musl.clang create mode 100644 src/engines/ruby/2.6/Dockerfile.musl.gcc create mode 100644 src/engines/ruby/2.7/Dockerfile.musl create mode 100644 src/engines/ruby/2.7/Dockerfile.musl.clang create mode 100644 src/engines/ruby/2.7/Dockerfile.musl.gcc create mode 100644 src/engines/ruby/3.0/Dockerfile.musl create mode 100644 src/engines/ruby/3.0/Dockerfile.musl.clang create mode 100644 src/engines/ruby/3.0/Dockerfile.musl.gcc create mode 100644 src/engines/ruby/3.1/Dockerfile.musl create mode 100644 src/engines/ruby/3.1/Dockerfile.musl.clang create mode 100644 src/engines/ruby/3.1/Dockerfile.musl.gcc create mode 100644 src/engines/ruby/3.2/Dockerfile.musl create mode 100644 src/engines/ruby/3.2/Dockerfile.musl.clang create mode 100644 src/engines/ruby/3.2/Dockerfile.musl.gcc create mode 100644 src/engines/ruby/3.3/Dockerfile.musl create mode 100644 src/engines/ruby/3.3/Dockerfile.musl.clang create mode 100644 src/engines/ruby/3.3/Dockerfile.musl.gcc create mode 100644 src/engines/ruby/3.4/Dockerfile.musl create mode 100644 src/engines/ruby/3.4/Dockerfile.musl.clang create mode 100644 src/engines/ruby/3.4/Dockerfile.musl.gcc diff --git a/src/engines/jruby/9.2/Dockerfile.musl b/src/engines/jruby/9.2/Dockerfile.musl new file mode 100644 index 0000000..caab212 --- /dev/null +++ b/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" ] diff --git a/src/engines/jruby/9.2/Dockerfile.musl.clang b/src/engines/jruby/9.2/Dockerfile.musl.clang new file mode 100644 index 0000000..1e5b383 --- /dev/null +++ b/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 diff --git a/src/engines/jruby/9.2/Dockerfile.musl.gcc b/src/engines/jruby/9.2/Dockerfile.musl.gcc new file mode 100644 index 0000000..7072c2d --- /dev/null +++ b/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++ diff --git a/src/engines/jruby/9.3/Dockerfile.musl b/src/engines/jruby/9.3/Dockerfile.musl new file mode 100644 index 0000000..5a909e8 --- /dev/null +++ b/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" ] diff --git a/src/engines/jruby/9.3/Dockerfile.musl.clang b/src/engines/jruby/9.3/Dockerfile.musl.clang new file mode 100644 index 0000000..586cbcd --- /dev/null +++ b/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 diff --git a/src/engines/jruby/9.3/Dockerfile.musl.gcc b/src/engines/jruby/9.3/Dockerfile.musl.gcc new file mode 100644 index 0000000..6a609df --- /dev/null +++ b/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++ diff --git a/src/engines/jruby/9.4/Dockerfile.musl b/src/engines/jruby/9.4/Dockerfile.musl new file mode 100644 index 0000000..ba7b1d1 --- /dev/null +++ b/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" ] diff --git a/src/engines/jruby/9.4/Dockerfile.musl.clang b/src/engines/jruby/9.4/Dockerfile.musl.clang new file mode 100644 index 0000000..4e928fb --- /dev/null +++ b/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 diff --git a/src/engines/jruby/9.4/Dockerfile.musl.gcc b/src/engines/jruby/9.4/Dockerfile.musl.gcc new file mode 100644 index 0000000..7fe1bfa --- /dev/null +++ b/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++ diff --git a/src/engines/ruby/2.1/Dockerfile.musl b/src/engines/ruby/2.1/Dockerfile.musl new file mode 100644 index 0000000..d9acc53 --- /dev/null +++ b/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 diff --git a/src/engines/ruby/2.1/Dockerfile.musl.clang b/src/engines/ruby/2.1/Dockerfile.musl.clang new file mode 100644 index 0000000..cc33491 --- /dev/null +++ b/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 diff --git a/src/engines/ruby/2.1/Dockerfile.musl.gcc b/src/engines/ruby/2.1/Dockerfile.musl.gcc new file mode 100644 index 0000000..ecda630 --- /dev/null +++ b/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++ diff --git a/src/engines/ruby/2.2/Dockerfile.musl b/src/engines/ruby/2.2/Dockerfile.musl new file mode 100644 index 0000000..a140066 --- /dev/null +++ b/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 diff --git a/src/engines/ruby/2.2/Dockerfile.musl.clang b/src/engines/ruby/2.2/Dockerfile.musl.clang new file mode 100644 index 0000000..b06cb61 --- /dev/null +++ b/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 diff --git a/src/engines/ruby/2.2/Dockerfile.musl.gcc b/src/engines/ruby/2.2/Dockerfile.musl.gcc new file mode 100644 index 0000000..a249bef --- /dev/null +++ b/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++ diff --git a/src/engines/ruby/2.3/Dockerfile.musl b/src/engines/ruby/2.3/Dockerfile.musl new file mode 100644 index 0000000..2668347 --- /dev/null +++ b/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 diff --git a/src/engines/ruby/2.3/Dockerfile.musl.clang b/src/engines/ruby/2.3/Dockerfile.musl.clang new file mode 100644 index 0000000..feef3ac --- /dev/null +++ b/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 diff --git a/src/engines/ruby/2.3/Dockerfile.musl.gcc b/src/engines/ruby/2.3/Dockerfile.musl.gcc new file mode 100644 index 0000000..f02ff9f --- /dev/null +++ b/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++ diff --git a/src/engines/ruby/2.4/Dockerfile.musl b/src/engines/ruby/2.4/Dockerfile.musl new file mode 100644 index 0000000..ebe9ca4 --- /dev/null +++ b/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 diff --git a/src/engines/ruby/2.4/Dockerfile.musl.clang b/src/engines/ruby/2.4/Dockerfile.musl.clang new file mode 100644 index 0000000..352dcc9 --- /dev/null +++ b/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 diff --git a/src/engines/ruby/2.4/Dockerfile.musl.gcc b/src/engines/ruby/2.4/Dockerfile.musl.gcc new file mode 100644 index 0000000..f7a8cf6 --- /dev/null +++ b/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++ diff --git a/src/engines/ruby/2.5/Dockerfile.musl b/src/engines/ruby/2.5/Dockerfile.musl new file mode 100644 index 0000000..3d9b79a --- /dev/null +++ b/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 diff --git a/src/engines/ruby/2.5/Dockerfile.musl.clang b/src/engines/ruby/2.5/Dockerfile.musl.clang new file mode 100644 index 0000000..40499d9 --- /dev/null +++ b/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 diff --git a/src/engines/ruby/2.5/Dockerfile.musl.gcc b/src/engines/ruby/2.5/Dockerfile.musl.gcc new file mode 100644 index 0000000..40c7d56 --- /dev/null +++ b/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++ diff --git a/src/engines/ruby/2.6/Dockerfile.musl b/src/engines/ruby/2.6/Dockerfile.musl new file mode 100644 index 0000000..2dbb145 --- /dev/null +++ b/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 diff --git a/src/engines/ruby/2.6/Dockerfile.musl.clang b/src/engines/ruby/2.6/Dockerfile.musl.clang new file mode 100644 index 0000000..fa2a143 --- /dev/null +++ b/src/engines/ruby/2.6/Dockerfile.musl.clang @@ -0,0 +1,3 @@ +FROM ghcr.io/datadog/images-rb/engines/ruby:2.6-musl + +RUN apk add binutils file fortify-headers make musl-dev clang diff --git a/src/engines/ruby/2.6/Dockerfile.musl.gcc b/src/engines/ruby/2.6/Dockerfile.musl.gcc new file mode 100644 index 0000000..f1296ab --- /dev/null +++ b/src/engines/ruby/2.6/Dockerfile.musl.gcc @@ -0,0 +1,3 @@ +FROM ghcr.io/datadog/images-rb/engines/ruby:2.6-musl + +RUN apk add binutils file fortify-headers make musl-dev gcc g++ diff --git a/src/engines/ruby/2.7/Dockerfile.musl b/src/engines/ruby/2.7/Dockerfile.musl new file mode 100644 index 0000000..1ca4d84 --- /dev/null +++ b/src/engines/ruby/2.7/Dockerfile.musl @@ -0,0 +1,29 @@ +FROM ruby:2.7-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 diff --git a/src/engines/ruby/2.7/Dockerfile.musl.clang b/src/engines/ruby/2.7/Dockerfile.musl.clang new file mode 100644 index 0000000..4f78e4f --- /dev/null +++ b/src/engines/ruby/2.7/Dockerfile.musl.clang @@ -0,0 +1,3 @@ +FROM ghcr.io/datadog/images-rb/engines/ruby:2.7-musl + +RUN apk add binutils file fortify-headers make musl-dev clang diff --git a/src/engines/ruby/2.7/Dockerfile.musl.gcc b/src/engines/ruby/2.7/Dockerfile.musl.gcc new file mode 100644 index 0000000..1aa6b48 --- /dev/null +++ b/src/engines/ruby/2.7/Dockerfile.musl.gcc @@ -0,0 +1,3 @@ +FROM ghcr.io/datadog/images-rb/engines/ruby:2.7-musl + +RUN apk add binutils file fortify-headers make musl-dev gcc g++ diff --git a/src/engines/ruby/3.0/Dockerfile.musl b/src/engines/ruby/3.0/Dockerfile.musl new file mode 100644 index 0000000..d12b259 --- /dev/null +++ b/src/engines/ruby/3.0/Dockerfile.musl @@ -0,0 +1,29 @@ +FROM ruby:3.0-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 diff --git a/src/engines/ruby/3.0/Dockerfile.musl.clang b/src/engines/ruby/3.0/Dockerfile.musl.clang new file mode 100644 index 0000000..00d5be5 --- /dev/null +++ b/src/engines/ruby/3.0/Dockerfile.musl.clang @@ -0,0 +1,3 @@ +FROM ghcr.io/datadog/images-rb/engines/ruby:3.0-musl + +RUN apk add binutils file fortify-headers make musl-dev clang diff --git a/src/engines/ruby/3.0/Dockerfile.musl.gcc b/src/engines/ruby/3.0/Dockerfile.musl.gcc new file mode 100644 index 0000000..0ecca67 --- /dev/null +++ b/src/engines/ruby/3.0/Dockerfile.musl.gcc @@ -0,0 +1,3 @@ +FROM ghcr.io/datadog/images-rb/engines/ruby:3.0-musl + +RUN apk add binutils file fortify-headers make musl-dev gcc g++ diff --git a/src/engines/ruby/3.1/Dockerfile.musl b/src/engines/ruby/3.1/Dockerfile.musl new file mode 100644 index 0000000..817db6d --- /dev/null +++ b/src/engines/ruby/3.1/Dockerfile.musl @@ -0,0 +1,29 @@ +FROM ruby:3.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 diff --git a/src/engines/ruby/3.1/Dockerfile.musl.clang b/src/engines/ruby/3.1/Dockerfile.musl.clang new file mode 100644 index 0000000..87544ff --- /dev/null +++ b/src/engines/ruby/3.1/Dockerfile.musl.clang @@ -0,0 +1,3 @@ +FROM ghcr.io/datadog/images-rb/engines/ruby:3.1-musl + +RUN apk add binutils file fortify-headers make musl-dev clang diff --git a/src/engines/ruby/3.1/Dockerfile.musl.gcc b/src/engines/ruby/3.1/Dockerfile.musl.gcc new file mode 100644 index 0000000..a8c7f44 --- /dev/null +++ b/src/engines/ruby/3.1/Dockerfile.musl.gcc @@ -0,0 +1,3 @@ +FROM ghcr.io/datadog/images-rb/engines/ruby:3.1-musl + +RUN apk add binutils file fortify-headers make musl-dev gcc g++ diff --git a/src/engines/ruby/3.2/Dockerfile.musl b/src/engines/ruby/3.2/Dockerfile.musl new file mode 100644 index 0000000..18f5ff9 --- /dev/null +++ b/src/engines/ruby/3.2/Dockerfile.musl @@ -0,0 +1,29 @@ +FROM ruby:3.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 diff --git a/src/engines/ruby/3.2/Dockerfile.musl.clang b/src/engines/ruby/3.2/Dockerfile.musl.clang new file mode 100644 index 0000000..293c136 --- /dev/null +++ b/src/engines/ruby/3.2/Dockerfile.musl.clang @@ -0,0 +1,3 @@ +FROM ghcr.io/datadog/images-rb/engines/ruby:3.2-musl + +RUN apk add binutils file fortify-headers make musl-dev clang diff --git a/src/engines/ruby/3.2/Dockerfile.musl.gcc b/src/engines/ruby/3.2/Dockerfile.musl.gcc new file mode 100644 index 0000000..bdf2960 --- /dev/null +++ b/src/engines/ruby/3.2/Dockerfile.musl.gcc @@ -0,0 +1,3 @@ +FROM ghcr.io/datadog/images-rb/engines/ruby:3.2-musl + +RUN apk add binutils file fortify-headers make musl-dev gcc g++ diff --git a/src/engines/ruby/3.3/Dockerfile.musl b/src/engines/ruby/3.3/Dockerfile.musl new file mode 100644 index 0000000..c46a3d0 --- /dev/null +++ b/src/engines/ruby/3.3/Dockerfile.musl @@ -0,0 +1,29 @@ +FROM ruby:3.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 diff --git a/src/engines/ruby/3.3/Dockerfile.musl.clang b/src/engines/ruby/3.3/Dockerfile.musl.clang new file mode 100644 index 0000000..10f6a34 --- /dev/null +++ b/src/engines/ruby/3.3/Dockerfile.musl.clang @@ -0,0 +1,3 @@ +FROM ghcr.io/datadog/images-rb/engines/ruby:3.3-musl + +RUN apk add binutils file fortify-headers make musl-dev clang diff --git a/src/engines/ruby/3.3/Dockerfile.musl.gcc b/src/engines/ruby/3.3/Dockerfile.musl.gcc new file mode 100644 index 0000000..3462b66 --- /dev/null +++ b/src/engines/ruby/3.3/Dockerfile.musl.gcc @@ -0,0 +1,3 @@ +FROM ghcr.io/datadog/images-rb/engines/ruby:3.3-musl + +RUN apk add binutils file fortify-headers make musl-dev gcc g++ diff --git a/src/engines/ruby/3.4/Dockerfile.musl b/src/engines/ruby/3.4/Dockerfile.musl new file mode 100644 index 0000000..0068342 --- /dev/null +++ b/src/engines/ruby/3.4/Dockerfile.musl @@ -0,0 +1,29 @@ +FROM ruby:3.4-rc-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 diff --git a/src/engines/ruby/3.4/Dockerfile.musl.clang b/src/engines/ruby/3.4/Dockerfile.musl.clang new file mode 100644 index 0000000..0bd515a --- /dev/null +++ b/src/engines/ruby/3.4/Dockerfile.musl.clang @@ -0,0 +1,3 @@ +FROM ghcr.io/datadog/images-rb/engines/ruby:3.4-musl + +RUN apk add binutils file fortify-headers make musl-dev clang diff --git a/src/engines/ruby/3.4/Dockerfile.musl.gcc b/src/engines/ruby/3.4/Dockerfile.musl.gcc new file mode 100644 index 0000000..a93e457 --- /dev/null +++ b/src/engines/ruby/3.4/Dockerfile.musl.gcc @@ -0,0 +1,3 @@ +FROM ghcr.io/datadog/images-rb/engines/ruby:3.4-musl + +RUN apk add binutils file fortify-headers make musl-dev gcc g++