Describe the Problem
.NET Docker's manifest.json is over 7000 lines long and can only be edited by hand. This is an extremely time-consuming and error-prone process that needs to happen every time we move or update floating tags, and add or remove linux distros.
Additionally, there is lots of duplication of the same information inside and outside of the manifest file. For example,
|
"productVersion": "$(dotnet|8.0|product-version)", |
|
"sharedTags": { |
|
"$(dotnet|8.0|product-version)": {}, |
|
"$(dotnet|8.0|product-version)-bookworm-slim": {}, |
|
"8.0-preview": {}, |
|
"8.0-preview-bookworm-slim": {}, |
|
"latest": {} |
|
}, |
|
"platforms": [ |
|
{ |
|
"dockerfile": "src/runtime-deps/8.0/bookworm-slim/amd64", |
|
"dockerfileTemplate": "eng/dockerfile-templates/runtime-deps/Dockerfile", |
|
"os": "linux", |
|
"osVersion": "bookworm-slim", |
|
"tags": { |
|
"$(dotnet|8.0|product-version)-bookworm-slim-amd64": {}, |
|
"8.0-preview-bookworm-slim-amd64": {} |
|
} |
|
}, |
|
{ |
|
"architecture": "arm", |
|
"dockerfile": "src/runtime-deps/8.0/bookworm-slim/arm32v7", |
|
"dockerfileTemplate": "eng/dockerfile-templates/runtime-deps/Dockerfile", |
|
"os": "linux", |
|
"osVersion": "bookworm-slim", |
|
"tags": { |
|
"$(dotnet|8.0|product-version)-bookworm-slim-arm32v7": {}, |
|
"8.0-preview-bookworm-slim-arm32v7": {} |
|
}, |
|
"variant": "v7" |
|
}, |
|
{ |
|
"architecture": "arm64", |
|
"dockerfile": "src/runtime-deps/8.0/bookworm-slim/arm64v8", |
|
"dockerfileTemplate": "eng/dockerfile-templates/runtime-deps/Dockerfile", |
|
"os": "linux", |
|
"osVersion": "bookworm-slim", |
|
"tags": { |
|
"$(dotnet|8.0|product-version)-bookworm-slim-arm64v8": {}, |
|
"8.0-preview-bookworm-slim-arm64v8": {} |
|
}, |
|
"variant": "v8" |
|
} |
|
] |
|
}, |
The .NET version, architecture, and operating system are repeated constantly throughout this snippet. The tags are plaintext except for the product version variables - while this is nice for flexibility we always update them based on a pattern. It is very easy to get wrong, see:
There are many more instances caught in code review.
Describe the Solution
The intention of this issue is to start a discussion on how we can improve the situation.
I have thought of a few potential solutions:
- Generate dotnet-docker's
mainfest.json using a template.
- This allows us the same amount of flexibility that we already have by operating in plain-text, and also leaves other repos alone (.NET Fx, buildtools-prereqs).
- Create a tool or new command in ImageBuilder that can operate on the manifest.json.
- Simplify the
manifest.json schema.
- As far as I'm aware, the
manifest.json schema has not changed dramatically since it was created many years ago. This could allow us to re-think many aspects of the repo and take advantage of buildx/buildkit/multi-arch Dockerfiles/whatever new Docker features exist today.
Describe the Problem
.NET Docker's manifest.json is over 7000 lines long and can only be edited by hand. This is an extremely time-consuming and error-prone process that needs to happen every time we move or update floating tags, and add or remove linux distros.
Additionally, there is lots of duplication of the same information inside and outside of the manifest file. For example,
dotnet-docker/manifest.json
Lines 965 to 1009 in 5b22241
The .NET version, architecture, and operating system are repeated constantly throughout this snippet. The tags are plaintext except for the product version variables - while this is nice for flexibility we always update them based on a pattern. It is very easy to get wrong, see:
latesttag missing frommainbranch #4060latesttag is not getting updated in mcr.microsoft.com/dotnet/core-nightly/runtime-deps #2307There are many more instances caught in code review.
Describe the Solution
The intention of this issue is to start a discussion on how we can improve the situation.
I have thought of a few potential solutions:
mainfest.jsonusing a template.manifest.jsonschema.manifest.jsonschema has not changed dramatically since it was created many years ago. This could allow us to re-think many aspects of the repo and take advantage ofbuildx/buildkit/multi-arch Dockerfiles/whatever new Docker features exist today.