From 58b329de9bdd87ca64894989257509200299d94a Mon Sep 17 00:00:00 2001 From: Loic Nageleisen Date: Thu, 21 Nov 2024 15:22:38 +0100 Subject: [PATCH] Use `REPRO_RUN_KEY` in centos --- src/engines/ruby/1.8/Dockerfile.centos | 28 +++++++++++++++++++++++++- src/engines/ruby/1.9/Dockerfile.centos | 28 +++++++++++++++++++++++++- src/engines/ruby/2.0/Dockerfile.centos | 28 +++++++++++++++++++++++++- src/engines/ruby/2.1/Dockerfile.centos | 28 +++++++++++++++++++++++++- src/engines/ruby/2.2/Dockerfile.centos | 28 +++++++++++++++++++++++++- src/engines/ruby/2.3/Dockerfile.centos | 28 +++++++++++++++++++++++++- src/engines/ruby/2.4/Dockerfile.centos | 28 +++++++++++++++++++++++++- src/engines/ruby/2.5/Dockerfile.centos | 28 +++++++++++++++++++++++++- src/engines/ruby/2.6/Dockerfile.centos | 28 +++++++++++++++++++++++++- src/engines/ruby/2.7/Dockerfile.centos | 28 +++++++++++++++++++++++++- src/engines/ruby/3.0/Dockerfile.centos | 28 +++++++++++++++++++++++++- src/engines/ruby/3.1/Dockerfile.centos | 28 +++++++++++++++++++++++++- src/engines/ruby/3.2/Dockerfile.centos | 28 +++++++++++++++++++++++++- src/engines/ruby/3.3/Dockerfile.centos | 28 +++++++++++++++++++++++++- src/engines/ruby/3.4/Dockerfile.centos | 28 +++++++++++++++++++++++++- 15 files changed, 405 insertions(+), 15 deletions(-) diff --git a/src/engines/ruby/1.8/Dockerfile.centos b/src/engines/ruby/1.8/Dockerfile.centos index 489173b..05a3ce7 100644 --- a/src/engines/ruby/1.8/Dockerfile.centos +++ b/src/engines/ruby/1.8/Dockerfile.centos @@ -37,7 +37,33 @@ enabled=0 EOF SHELL -RUN yum makecache -y +# 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 + +# `yum` db fetching is uncontrolled and fetches whatever is today's index. +# For the sake of reproducibility subsequent steps (including in dependent +# images) should not perform `yum` db cache updates, instead this base image +# should be updated by changing the `REPRO_RUN_KEY`. +RUN true "${REPRO_RUN_KEY}" && yum makecache -y # localedef has been forcefully removed by: # rm -rf "$target"/usr/{{lib,share}/locale,{lib,lib64}/gconv,bin/localedef,sbin/build-locale-archive} diff --git a/src/engines/ruby/1.9/Dockerfile.centos b/src/engines/ruby/1.9/Dockerfile.centos index fd3b565..38ac302 100644 --- a/src/engines/ruby/1.9/Dockerfile.centos +++ b/src/engines/ruby/1.9/Dockerfile.centos @@ -37,7 +37,33 @@ enabled=0 EOF SHELL -RUN yum makecache -y +# 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 + +# `yum` db fetching is uncontrolled and fetches whatever is today's index. +# For the sake of reproducibility subsequent steps (including in dependent +# images) should not perform `yum` db cache updates, instead this base image +# should be updated by changing the `REPRO_RUN_KEY`. +RUN true "${REPRO_RUN_KEY}" && yum makecache -y # localedef has been forcefully removed by: # rm -rf "$target"/usr/{{lib,share}/locale,{lib,lib64}/gconv,bin/localedef,sbin/build-locale-archive} diff --git a/src/engines/ruby/2.0/Dockerfile.centos b/src/engines/ruby/2.0/Dockerfile.centos index 224b58a..9a9190e 100644 --- a/src/engines/ruby/2.0/Dockerfile.centos +++ b/src/engines/ruby/2.0/Dockerfile.centos @@ -37,7 +37,33 @@ enabled=0 EOF SHELL -RUN yum makecache -y +# 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 + +# `yum` db fetching is uncontrolled and fetches whatever is today's index. +# For the sake of reproducibility subsequent steps (including in dependent +# images) should not perform `yum` db cache updates, instead this base image +# should be updated by changing the `REPRO_RUN_KEY`. +RUN true "${REPRO_RUN_KEY}" && yum makecache -y # localedef has been forcefully removed by: # rm -rf "$target"/usr/{{lib,share}/locale,{lib,lib64}/gconv,bin/localedef,sbin/build-locale-archive} diff --git a/src/engines/ruby/2.1/Dockerfile.centos b/src/engines/ruby/2.1/Dockerfile.centos index b8cb97c..00a59a1 100644 --- a/src/engines/ruby/2.1/Dockerfile.centos +++ b/src/engines/ruby/2.1/Dockerfile.centos @@ -35,7 +35,33 @@ enabled=0 EOF SHELL -RUN yum makecache -y +# 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 + +# `yum` db fetching is uncontrolled and fetches whatever is today's index. +# For the sake of reproducibility subsequent steps (including in dependent +# images) should not perform `yum` db cache updates, instead this base image +# should be updated by changing the `REPRO_RUN_KEY`. +RUN true "${REPRO_RUN_KEY}" && yum makecache -y # localedef has been forcefully removed by: # rm -rf "$target"/usr/{{lib,share}/locale,{lib,lib64}/gconv,bin/localedef,sbin/build-locale-archive} diff --git a/src/engines/ruby/2.2/Dockerfile.centos b/src/engines/ruby/2.2/Dockerfile.centos index f4eb6da..91d6662 100644 --- a/src/engines/ruby/2.2/Dockerfile.centos +++ b/src/engines/ruby/2.2/Dockerfile.centos @@ -35,7 +35,33 @@ enabled=0 EOF SHELL -RUN yum makecache -y +# 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 + +# `yum` db fetching is uncontrolled and fetches whatever is today's index. +# For the sake of reproducibility subsequent steps (including in dependent +# images) should not perform `yum` db cache updates, instead this base image +# should be updated by changing the `REPRO_RUN_KEY`. +RUN true "${REPRO_RUN_KEY}" && yum makecache -y # localedef has been forcefully removed by: # rm -rf "$target"/usr/{{lib,share}/locale,{lib,lib64}/gconv,bin/localedef,sbin/build-locale-archive} diff --git a/src/engines/ruby/2.3/Dockerfile.centos b/src/engines/ruby/2.3/Dockerfile.centos index 6c72eee..d73565b 100644 --- a/src/engines/ruby/2.3/Dockerfile.centos +++ b/src/engines/ruby/2.3/Dockerfile.centos @@ -35,7 +35,33 @@ enabled=0 EOF SHELL -RUN yum makecache -y +# 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 + +# `yum` db fetching is uncontrolled and fetches whatever is today's index. +# For the sake of reproducibility subsequent steps (including in dependent +# images) should not perform `yum` db cache updates, instead this base image +# should be updated by changing the `REPRO_RUN_KEY`. +RUN true "${REPRO_RUN_KEY}" && yum makecache -y # localedef has been forcefully removed by: # rm -rf "$target"/usr/{{lib,share}/locale,{lib,lib64}/gconv,bin/localedef,sbin/build-locale-archive} diff --git a/src/engines/ruby/2.4/Dockerfile.centos b/src/engines/ruby/2.4/Dockerfile.centos index 176a6e7..da8facb 100644 --- a/src/engines/ruby/2.4/Dockerfile.centos +++ b/src/engines/ruby/2.4/Dockerfile.centos @@ -35,7 +35,33 @@ enabled=0 EOF SHELL -RUN yum makecache -y +# 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 + +# `yum` db fetching is uncontrolled and fetches whatever is today's index. +# For the sake of reproducibility subsequent steps (including in dependent +# images) should not perform `yum` db cache updates, instead this base image +# should be updated by changing the `REPRO_RUN_KEY`. +RUN true "${REPRO_RUN_KEY}" && yum makecache -y # localedef has been forcefully removed by: # rm -rf "$target"/usr/{{lib,share}/locale,{lib,lib64}/gconv,bin/localedef,sbin/build-locale-archive} diff --git a/src/engines/ruby/2.5/Dockerfile.centos b/src/engines/ruby/2.5/Dockerfile.centos index 6ae2b1e..8fa6213 100644 --- a/src/engines/ruby/2.5/Dockerfile.centos +++ b/src/engines/ruby/2.5/Dockerfile.centos @@ -35,7 +35,33 @@ enabled=0 EOF SHELL -RUN yum makecache -y +# 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 + +# `yum` db fetching is uncontrolled and fetches whatever is today's index. +# For the sake of reproducibility subsequent steps (including in dependent +# images) should not perform `yum` db cache updates, instead this base image +# should be updated by changing the `REPRO_RUN_KEY`. +RUN true "${REPRO_RUN_KEY}" && yum makecache -y # localedef has been forcefully removed by: # rm -rf "$target"/usr/{{lib,share}/locale,{lib,lib64}/gconv,bin/localedef,sbin/build-locale-archive} diff --git a/src/engines/ruby/2.6/Dockerfile.centos b/src/engines/ruby/2.6/Dockerfile.centos index a2a65e5..50180c3 100644 --- a/src/engines/ruby/2.6/Dockerfile.centos +++ b/src/engines/ruby/2.6/Dockerfile.centos @@ -35,7 +35,33 @@ enabled=0 EOF SHELL -RUN yum makecache -y +# 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 + +# `yum` db fetching is uncontrolled and fetches whatever is today's index. +# For the sake of reproducibility subsequent steps (including in dependent +# images) should not perform `yum` db cache updates, instead this base image +# should be updated by changing the `REPRO_RUN_KEY`. +RUN true "${REPRO_RUN_KEY}" && yum makecache -y # localedef has been forcefully removed by: # rm -rf "$target"/usr/{{lib,share}/locale,{lib,lib64}/gconv,bin/localedef,sbin/build-locale-archive} diff --git a/src/engines/ruby/2.7/Dockerfile.centos b/src/engines/ruby/2.7/Dockerfile.centos index 6206207..6c65be7 100644 --- a/src/engines/ruby/2.7/Dockerfile.centos +++ b/src/engines/ruby/2.7/Dockerfile.centos @@ -35,7 +35,33 @@ enabled=0 EOF SHELL -RUN yum makecache -y +# 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 + +# `yum` db fetching is uncontrolled and fetches whatever is today's index. +# For the sake of reproducibility subsequent steps (including in dependent +# images) should not perform `yum` db cache updates, instead this base image +# should be updated by changing the `REPRO_RUN_KEY`. +RUN true "${REPRO_RUN_KEY}" && yum makecache -y # localedef has been forcefully removed by: # rm -rf "$target"/usr/{{lib,share}/locale,{lib,lib64}/gconv,bin/localedef,sbin/build-locale-archive} diff --git a/src/engines/ruby/3.0/Dockerfile.centos b/src/engines/ruby/3.0/Dockerfile.centos index 6c9ea52..8a3b240 100644 --- a/src/engines/ruby/3.0/Dockerfile.centos +++ b/src/engines/ruby/3.0/Dockerfile.centos @@ -35,7 +35,33 @@ enabled=0 EOF SHELL -RUN yum makecache -y +# 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 + +# `yum` db fetching is uncontrolled and fetches whatever is today's index. +# For the sake of reproducibility subsequent steps (including in dependent +# images) should not perform `yum` db cache updates, instead this base image +# should be updated by changing the `REPRO_RUN_KEY`. +RUN true "${REPRO_RUN_KEY}" && yum makecache -y # localedef has been forcefully removed by: # rm -rf "$target"/usr/{{lib,share}/locale,{lib,lib64}/gconv,bin/localedef,sbin/build-locale-archive} diff --git a/src/engines/ruby/3.1/Dockerfile.centos b/src/engines/ruby/3.1/Dockerfile.centos index 65ed315..e208fde 100644 --- a/src/engines/ruby/3.1/Dockerfile.centos +++ b/src/engines/ruby/3.1/Dockerfile.centos @@ -35,7 +35,33 @@ enabled=0 EOF SHELL -RUN yum makecache -y +# 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 + +# `yum` db fetching is uncontrolled and fetches whatever is today's index. +# For the sake of reproducibility subsequent steps (including in dependent +# images) should not perform `yum` db cache updates, instead this base image +# should be updated by changing the `REPRO_RUN_KEY`. +RUN true "${REPRO_RUN_KEY}" && yum makecache -y # localedef has been forcefully removed by: # rm -rf "$target"/usr/{{lib,share}/locale,{lib,lib64}/gconv,bin/localedef,sbin/build-locale-archive} diff --git a/src/engines/ruby/3.2/Dockerfile.centos b/src/engines/ruby/3.2/Dockerfile.centos index 5b8c5c0..20dfa5e 100644 --- a/src/engines/ruby/3.2/Dockerfile.centos +++ b/src/engines/ruby/3.2/Dockerfile.centos @@ -35,7 +35,33 @@ enabled=0 EOF SHELL -RUN yum makecache -y +# 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 + +# `yum` db fetching is uncontrolled and fetches whatever is today's index. +# For the sake of reproducibility subsequent steps (including in dependent +# images) should not perform `yum` db cache updates, instead this base image +# should be updated by changing the `REPRO_RUN_KEY`. +RUN true "${REPRO_RUN_KEY}" && yum makecache -y # localedef has been forcefully removed by: # rm -rf "$target"/usr/{{lib,share}/locale,{lib,lib64}/gconv,bin/localedef,sbin/build-locale-archive} diff --git a/src/engines/ruby/3.3/Dockerfile.centos b/src/engines/ruby/3.3/Dockerfile.centos index 4490258..c228097 100644 --- a/src/engines/ruby/3.3/Dockerfile.centos +++ b/src/engines/ruby/3.3/Dockerfile.centos @@ -35,7 +35,33 @@ enabled=0 EOF SHELL -RUN yum makecache -y +# 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 + +# `yum` db fetching is uncontrolled and fetches whatever is today's index. +# For the sake of reproducibility subsequent steps (including in dependent +# images) should not perform `yum` db cache updates, instead this base image +# should be updated by changing the `REPRO_RUN_KEY`. +RUN true "${REPRO_RUN_KEY}" && yum makecache -y # localedef has been forcefully removed by: # rm -rf "$target"/usr/{{lib,share}/locale,{lib,lib64}/gconv,bin/localedef,sbin/build-locale-archive} diff --git a/src/engines/ruby/3.4/Dockerfile.centos b/src/engines/ruby/3.4/Dockerfile.centos index 92d8f14..61515e2 100644 --- a/src/engines/ruby/3.4/Dockerfile.centos +++ b/src/engines/ruby/3.4/Dockerfile.centos @@ -35,7 +35,33 @@ enabled=0 EOF SHELL -RUN yum makecache -y +# 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 + +# `yum` db fetching is uncontrolled and fetches whatever is today's index. +# For the sake of reproducibility subsequent steps (including in dependent +# images) should not perform `yum` db cache updates, instead this base image +# should be updated by changing the `REPRO_RUN_KEY`. +RUN true "${REPRO_RUN_KEY}" && yum makecache -y # localedef has been forcefully removed by: # rm -rf "$target"/usr/{{lib,share}/locale,{lib,lib64}/gconv,bin/localedef,sbin/build-locale-archive}