You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The .NET Docker repos prioritize Dockerfile readability. By this I mean using a single Dockerfile to build arm, amd64, multiple distros, etc image variants is avoided because it would required Dockerfiles ARGs to specify version numbers, artifact shas, base images, etc. Having individual Dockerfiles per platform makes it is easy for users to copy a Dockerfile and adjust for their own specific purposes. It also makes it easy for users to understand what is in a particular image.
The drawback to this approach is that maintaining the Dockerfiles is more work. If a change is needed for a particular image variant, it typically needs to be copied across several Dockerfiles. Likewise, when support is added for a new distro, several Dockerfiles need to be added. Ensuring all Dockerfiles are identical/symmetric is left to the human eye and there have been cases in the past where the Dockerfiles have gotten out of sync. Some of these cases were cosmetic but others have been functional (e.g. Consistent environment variable names for DOTNET_RUNNING_IN_CONTAINER)
There are upcoming features (Approach for using Crossgen2 and Add Server Core Images) where symmetry is critical. The reason is that we would like the first installer stage to be identical in order to gain build optimizations (e.g. build cache).
The official Docker image repositories make use of a template system (e.g. golang). A similar mechanism could be used for .NET Dockerfiles.
Work Breakdown
Ensure consistency across Dockerfiles per version (e.g. ensure Dockerfiles that will be generated from a single template are the same)
Add ImageBuilder support for breaking manifest.json into separate files
Introduce manifest.versions.json
Add ImageBuilder generateDockerfiles command
Define templates and manifest metadata
Refactor UpdateDependencies in response to templates
Add unit test to ensure Dockerfiles are in sync with templates
Add documentation for template syntax and workflow for making Dockerfile changes
Notify contributing partners of template changes - .NET diagnostics and PowerShell
The text was updated successfully, but these errors were encountered:
The .NET Docker repos prioritize Dockerfile readability. By this I mean using a single Dockerfile to build arm, amd64, multiple distros, etc image variants is avoided because it would required Dockerfiles ARGs to specify version numbers, artifact shas, base images, etc. Having individual Dockerfiles per platform makes it is easy for users to copy a Dockerfile and adjust for their own specific purposes. It also makes it easy for users to understand what is in a particular image.
The drawback to this approach is that maintaining the Dockerfiles is more work. If a change is needed for a particular image variant, it typically needs to be copied across several Dockerfiles. Likewise, when support is added for a new distro, several Dockerfiles need to be added. Ensuring all Dockerfiles are identical/symmetric is left to the human eye and there have been cases in the past where the Dockerfiles have gotten out of sync. Some of these cases were cosmetic but others have been functional (e.g. Consistent environment variable names for DOTNET_RUNNING_IN_CONTAINER)
There are upcoming features (Approach for using Crossgen2 and Add Server Core Images) where symmetry is critical. The reason is that we would like the first installer stage to be identical in order to gain build optimizations (e.g. build cache).
The official Docker image repositories make use of a template system (e.g. golang). A similar mechanism could be used for .NET Dockerfiles.
Work Breakdown
The text was updated successfully, but these errors were encountered: