Merge pull request #10 from DataDog/lloeki/add-musl-images

Add musl images

src/engines/jruby/9.2/Dockerfile → src/engines/jruby/9.2/Dockerfile.gnu

@@ -1,3 +1,6 @@
+# strip-tags: gnu
+# append-tags: gcc
+
 FROM eclipse-temurin:8-jammy AS jruby-9.2.21.0-jre8
 
 # A few RUN actions in Dockerfiles are subject to uncontrollable outside

src/engines/jruby/9.2/Dockerfile.musl

@@ -0,0 +1,58 @@
+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
+
+## Install a pinned RubyGems and Bundler
+RUN gem update --system 3.3.26
+RUN gem install bundler:2.3.26
+
+# Install additional gems that are in CRuby but missing from the above
+# JRuby install distribution. These are version-pinned for reproducibility.
+RUN gem install rake:13.2.1
+
+# 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 → src/engines/jruby/9.3/Dockerfile.gnu

@@ -1,3 +1,6 @@
+# strip-tags: gnu
+# append-tags: gcc
+
 FROM eclipse-temurin:11-jammy AS jruby-9.3.9.0-jre11
 
 # A few RUN actions in Dockerfiles are subject to uncontrollable outside

src/engines/jruby/9.3/Dockerfile.musl

@@ -0,0 +1,58 @@
+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
+
+## Install a pinned RubyGems and Bundler
+RUN gem update --system 3.3.26
+RUN gem install bundler:2.3.26
+
+# Install additional gems that are in CRuby but missing from the above
+# JRuby install distribution. These are version-pinned for reproducibility.
+RUN gem install rake:13.2.1
+
+# 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 → src/engines/jruby/9.4/Dockerfile.gnu

@@ -1,3 +1,6 @@
+# strip-tags: gnu
+# append-tags: gcc
+
 FROM eclipse-temurin:11-jammy AS jruby-9.4.7.0-jre11
 
 # A few RUN actions in Dockerfiles are subject to uncontrollable outside

src/engines/jruby/9.4/Dockerfile.musl

@@ -0,0 +1,58 @@
+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
+
+## Install a pinned RubyGems and Bundler
+RUN gem update --system 3.5.21
+RUN gem install bundler:2.3.26
+
+# Install additional gems that are in CRuby but missing from the above
+# JRuby install distribution. These are version-pinned for reproducibility.
+RUN gem install rake:13.2.1
+
+# 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 → src/engines/ruby/2.1/Dockerfile.gnu

@@ -1,3 +1,6 @@
+# strip-tags: gnu
+# append-tags: gcc
+
 # ruby:2.1.10 was based on jessie, but never got a aarch64 image
 # aarch64 used to be supported upon release but is not part of LTS, so archive.debian.org does not contain aarch64: https://www.debian.org/releases/jessie/
 

src/engines/ruby/2.1/Dockerfile.musl

@@ -0,0 +1,37 @@
+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
+
+## Install a pinned RubyGems and Bundler
+RUN gem update --system 2.7.11
+RUN gem install bundler --version 1.17.3
+
+# Install additional gems that are in CRuby but missing from the above
+# JRuby install distribution. These are version-pinned for reproducibility.
+RUN gem install rake:12.3.3

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 → src/engines/ruby/2.2/Dockerfile.gnu

@@ -1,3 +1,6 @@
+# strip-tags: gnu
+# append-tags: gcc
+
 # ruby:2.2.10-jessie was based on jessie, and had a aarch64 image
 # aarch64 used to be supported upon release but is not part of LTS,
 # so archive.debian.org does not contain aarch64: https://www.debian.org/releases/jessie/

src/engines/ruby/2.2/Dockerfile.musl

@@ -0,0 +1,38 @@
+# 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
+
+## Install a pinned RubyGems and Bundler
+RUN gem update --system 2.7.11
+RUN gem install bundler --version 1.17.3
+
+# Install additional gems that are in CRuby but missing from the above
+# JRuby install distribution. These are version-pinned for reproducibility.
+RUN gem install rake:13.0.6

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 → src/engines/ruby/2.3/Dockerfile.gnu

@@ -1,3 +1,6 @@
+# strip-tags: gnu
+# append-tags: gcc
+
 # Last version: https://github.com/docker-library/ruby/blob/31f66490fdb837ddcc5896e3275f2188f2b7b6dd/2.3/stretch/Dockerfile
 FROM ruby:2.3.8-stretch
 

src/engines/ruby/2.3/Dockerfile.musl

@@ -0,0 +1,37 @@
+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
+
+## Install a pinned RubyGems and Bundler
+RUN gem update --system 3.3.26
+RUN gem install bundler:2.3.26
+
+# Install additional gems that are in CRuby but missing from the above
+# JRuby install distribution. These are version-pinned for reproducibility.
+RUN gem install rake:13.2.1

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 → src/engines/ruby/2.4/Dockerfile.gnu

@@ -1,3 +1,6 @@
+# strip-tags: gnu
+# append-tags: gcc
+
 FROM ruby:2.4.10-buster
 
 # A few RUN actions in Dockerfiles are subject to uncontrollable outside