While working on #417 and #409 , I wondered if we could not simplify the "spread" of build arg values to factorized locations (1 for all Linux and one for all Windows).
The goal is to avoid any leftover when updating a JDK, Git or any important component.
@team-docker-packaging I remember the constraint of having a value for build-arg in the Dockerfile because of the DockerHub automated builds (major) and allowing users to build a standalone Dockerfile without the need for additional tools (minor).
But today (May 2023):
We do not use the DockerHub automated build since quite some time
Both BuildX and Compose are part of any default Docker installation (or available as docker CLI client-side plugins easy to install for edge cases) even on Windows and Linux
Any objection for a code cleanup to remove, only when specified through a centralize file(s) , the values from Dockerfile ?
While working on #417 and #409 , I wondered if we could not simplify the "spread" of build arg values to factorized locations (1 for all Linux and one for all Windows).
The goal is to avoid any leftover when updating a JDK, Git or any important component.
@team-docker-packaging I remember the constraint of having a value for build-arg in the
Dockerfile
because of the DockerHub automated builds (major) and allowing users to build a standaloneDockerfile
without the need for additional tools (minor).But today (May 2023):
docker
CLI client-side plugins easy to install for edge cases) even on Windows and LinuxAny objection for a code cleanup to remove, only when specified through a centralize file(s) , the values from
Dockerfile
?