Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Centrally define versions that can be used by multiple Dockerfiles #1267

Open
mthalman opened this issue Nov 22, 2024 · 2 comments
Open

Centrally define versions that can be used by multiple Dockerfiles #1267

mthalman opened this issue Nov 22, 2024 · 2 comments

Comments

@mthalman
Copy link
Member

mthalman commented Nov 22, 2024

There are many Dockerfiles in this repo that are all installing a specific version of some software asset. It's important that the referenced version is consistently referenced across all the Dockerfiles.

Note

There may need to be some differences in the versions used between Dockerfiles for compatibility reasons based on the usage of those images.

Keeping these versions all in sync is a maintenance burden because it requires someone to have to search through all the Dockerfiles to understand which ones are affected and need to be updated. Having a centrally-defined location for these software versions would solve this problem.

Precedence for this approach already exists at https://github.com/dotnet/dotnet-docker (MinGit example). That repo uses an update-dependencies tool to keep a centrally-defined JSON file updated with references to versions. That version is then used as input for generating the Dockerfiles via templates. Instead of templating the Dockerfiles, another solution may be to pass in the version value as an ARG (however, see dotnet/docker-tools#1505).

@lbussell
Copy link
Contributor

I imagine if we added templating to this repo, we would want keep it very very light. It would be easy to get carried away. I am not super enthusiastic about onboarding completely new things to Cottle. Perhaps an opportunity to try something different here.

I don't love the ARGS approach either, since without a default version present in the Dockerfile they would be more annoying to build.

@lbussell lbussell moved this from Backlog to Current Release in .NET Docker Nov 25, 2024
@lbussell
Copy link
Contributor

[Triage] We should make sure to close dotnet/docker-tools#1505 as not-planned if we decide against using ARGS to accomplish this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Current Release
Development

No branches or pull requests

2 participants