Skip to content

[main] Update common Docker engineering infrastructure with latest #1310

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.

Sign up for GitHub

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

Open
dotnet-docker-bot wants to merge 1 commit into
base: main
Choose a base branch
from
+24 −1
Open

[main] Update common Docker engineering infrastructure with latest #1310

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
25 changes: 24 additions & 1 deletion eng/docker-tools/DEV-GUIDE.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -143,6 +143,7 @@ Build Stage
▼
Post_Build Stage
├── Merge image info files
├── Create multi-arch manifests
└── Consolidate SBOMs
│
▼
Expand Down Expand Up @@ -191,13 +192,35 @@ Common patterns:
- `"publish"` - Publish only (when re-running a failed publish from a previous build)
- `"build,test,sign,publish"` - Full pipeline

**Note:** The `Post_Build` stage is implicitly included whenever `build` is in the stages list. You don't need to specify it separately—it automatically runs after Build to merge image info files and consolidate SBOMs.
**Note:** The `Post_Build` stage is implicitly included whenever `build` is in the stages list. You don't need to specify it separately—it automatically runs after Build to merge image info files, create and validate multi-arch manifests, and consolidate SBOMs.

The stages variable is useful for:
- Re-running just the publish stage after fixing a transient failure
- Skipping tests during initial development
- Running isolated stages for debugging

### Decoupling build OS from the base image OS

By default, a platform's `osVersion` represents the base image OS version, but also determines what
build leg an image is built in. This can cause problems when build image and base image don't match
up. For example, building a .NET app on Windows Server 2025 and copying the artifacts into a
Windows Server 2019 base image won't work, because the build matrix generation will attempt to
build the image on the Server 2019 build leg (which can't run Server 2025 images).

To fix this, set the optional `buildOsVersion` field in order to override only the OS used in the
build matrix generation. Here is an example of building a Windows Server 2019 image using Windows
Server 2025:

```jsonc
{
// ...
"os": "windows",
"osVersion": "windowsservercore-ltsc2019",
"buildOsVersion": "windowsservercore-ltsc2025"
// ...
}
```

### Image Info Files: The Build's Memory

Image info files (defined by [`ImageArtifactDetails`](https://github.com/dotnet/docker-tools/blob/main/src/ImageBuilder/Models/Image/ImageArtifactDetails.cs)) are the mechanism that tracks what was built:
Expand Down
Loading