[main] Update common Docker engineering infrastructure with latest

.github/workflows/update-dependencies-tests.yml

@@ -23,7 +23,7 @@ jobs:
       - name: Setup .NET
         uses: actions/setup-dotnet@v4
         with:
-          dotnet-version: '9.0.x'
+          dotnet-version: '10.0.x'
 
       - name: Restore dependencies
         run: >

eng/docker-tools/CHANGELOG.md

@@ -4,6 +4,56 @@ All breaking changes and new features in `eng/docker-tools` will be documented i
 
 ---
 
+## 2026-10-05: Lifecycle metadata commands combined
+
+- Pull request: [#2252](https://github.com/dotnet/docker-tools/pull/2252)
+- Issues: [#2153](https://github.com/dotnet/docker-tools/issues/2153), [#2066](https://github.com/dotnet/docker-tools/issues/2066)
+
+ImageBuilder now uses one command, `attachLifecycleMetadata`, to add lifecycle metadata to images.
+The shared publish and cleanup templates use the new command. Repositories that only use these
+templates do not need to make any changes.
+
+Repositories that call ImageBuilder commands directly must use these replacements:
+
+| Old command | New command |
+| --- | --- |
+| `generateEolAnnotationDataForPublish` and `annotateEolDigests` | `attachLifecycleMetadata unsupported` |
+| `generateEolAnnotationDataForAllImages` and `annotateEolDigests` | `attachLifecycleMetadata all` |
+| `annotateEolDigests` with a data file | `attachLifecycleMetadata file` |
+| `waitForMarAnnotationIngestion` | Add `--wait-for-ingestion` to an `attachLifecycleMetadata` command |
+
+The publish job no longer creates lifecycle metadata data files before it attaches the metadata.
+Update any automation that reads those intermediate files.
+
+Lifecycle metadata can now be marked as internal. Internal metadata is never published.
+
+---
+
+## 2026-08-10: Pre-ImageBuilder build customization
+
+Build pipeline templates now accept `customPreImageBuilderBuildSteps`. These steps run after
+ImageBuilder is available but before repository content is copied into the Linux ImageBuilder
+image. Repositories can use the hook to stage files into Docker build contexts, such as shared
+`eng/common` content required by Dockerfiles.
+
+---
+
+## 2026-07-28: Publish stage artifacts consolidated
+
+The Publish stage now uploads `$(Build.ArtifactStagingDirectory)` once as
+`publish-attempt-$(System.JobAttempt)`. This replaces these separate artifacts:
+
+- `image-info-final-$(System.JobAttempt)`
+- `eol-annotation-data-$(System.JobAttempt)`
+- `annotation-digests-<registry>-$(System.JobAttempt)`
+- `source-build-id`
+
+Consumers of those artifact names must download the consolidated artifact instead. Files retain
+their staging-directory paths, including `imageInfo/`, `eol-annotation-data/`,
+`annotation-digests/`, and `sourceBuildId/source-build-id.txt`.
+
+---
+
 ## 2026-06-11: Configurable per-registry referrer-lookup rate limit
 
 - Issue: [#2141](https://github.com/dotnet/docker-tools/issues/2141)

eng/docker-tools/DEV-GUIDE.md

@@ -302,7 +302,7 @@ The publish stage does more than just push images. Here's the sequence:
 5. **Wait for Doc Ingestion** — Ensures README changes are live
 6. **Merge & Publish Image Info** — Updates the versions repo with new image metadata
 7. **Ingest Kusto Image Info** — Sends telemetry to Kusto for analytics
-8. **Generate & Apply EOL Annotations** — Marks images with end-of-life dates
+8. **Attach Lifecycle Metadata** - `attachLifecycleMetadata unsupported` marks unsupported images with end-of-life dates
 9. **Post Publish Notification** — Creates GitHub issues/notifications about the publish
 
 ### Dry-Run Mode
@@ -352,12 +352,10 @@ The system has built-in retry logic but requires manual intervention after repea
 
 Once you've fixed the underlying problem (Dockerfile change, test fix, etc.) and have a successful build:
 
-1. Navigate to the successful pipeline run in Azure DevOps
-2. Add the `autobuilder` label to that run
-3. This signals to the infrastructure that a successful build has occurred
-4. The system will resume automatic rebuilds for that image as needed
+1. Manually queue a build for the affected image paths
+2. After the build succeeds, the system will resume automatic rebuilds for that image as needed
 
-The `autobuilder` label is how the infrastructure tracks that the failure cycle has been broken and normal operations can resume.
+The infrastructure considers the three most recent pipeline runs, so any successful run breaks the failure cycle.
 
 ---
 
@@ -391,6 +389,22 @@ To force a rebuild regardless of cache state, set the `noCache` parameter to `tr
 
 ## Common Customization Patterns
 
+### Pattern: Staging Files into Docker Build Contexts
+
+Use `customPreImageBuilderBuildSteps` to modify repository content immediately before the
+repository is copied into the Linux ImageBuilder image. For example, a repository can stage
+shared `eng/common` files next to Dockerfiles whose build contexts cannot access the repository
+root:
+
+```yaml
+customPreImageBuilderBuildSteps:
+- powershell: ./eng/Stage-EngCommon.ps1
+  displayName: Stage eng/common in Docker Build Contexts
+```
+
+The steps run once per Linux build job, after ImageBuilder is available and before the
+`Dockerfile.WithRepo` image is built.
+
 ### Pattern: Adding Build Arguments
 
 Pass Dockerfile `ARG` values via ImageBuilder:

eng/docker-tools/Install-DotNetSdk.ps1

@@ -20,7 +20,7 @@ param(
     [string]
     $InstallPath,
     [string]
-    $Channel = "9.0"
+    $Channel = "10.0"
 )
 
 Set-StrictMode -Version Latest

eng/docker-tools/Update-ImageBuilder.ps1

@@ -0,0 +1,89 @@
+#!/usr/bin/env pwsh
+
+<#
+.SYNOPSIS
+Example script that updates the bundled docker-tools infrastructure in the current repo to a specific
+ImageBuilder image.
+
+.DESCRIPTION
+ImageBuilder ships a copy of the eng/docker-tools infrastructure and writes it back to disk via its
+'update' command. The reference that 'update' records into
+eng/docker-tools/templates/variables/docker-images.yml is supplied as an argument rather than being
+baked into the build, so the caller decides exactly which image the repo should pin to.
+
+This example resolves the multi-platform (manifest list / image index) digest of an ImageBuilder image
+(the published 'latest' tag by default) and passes that digest reference to the 'update' command, which
+runs inside the same image with the repository mounted so it can rewrite eng/docker-tools on disk.
+
+.PARAMETER ImageBuilderImage
+The ImageBuilder image to resolve and run. Defaults to the published 'latest' tag.
+
+.PARAMETER RepoRoot
+The root of the git repository to update. Defaults to the current directory.
+
+.NOTES
+To exercise an unpublished ImageBuilder (for example, the 'update' command before it is released),
+build the image, push it to a registry it can be pulled from, and pass its reference via
+-ImageBuilderImage. The digest is read from the registry, so the image must be pushed first.
+#>
+[CmdletBinding()]
+param(
+    [string]
+    $ImageBuilderImage = "mcr.microsoft.com/dotnet-buildtools/image-builder:latest",
+
+    [string]
+    $RepoRoot = (Get-Location).Path
+)
+
+Set-StrictMode -Version Latest
+$ErrorActionPreference = 'Stop'
+
+function Exec {
+    param ([string] $Cmd)
+
+    Write-Output "Executing: '$Cmd'"
+    Invoke-Expression $Cmd
+    if ($LASTEXITCODE -ne 0) {
+        throw "Failed: '$Cmd'"
+    }
+}
+
+# Strip any existing tag or digest so the resolved digest can be appended to the bare repository name.
+# A tag is a ':' within the final path segment; a registry host's ':port' precedes the last '/', so it
+# must not be mistaken for a tag.
+function Get-RepositoryName {
+    param ([string] $Reference)
+
+    $withoutDigest = $Reference.Split('@')[0]
+    $lastSlash = $withoutDigest.LastIndexOf('/')
+    $lastColon = $withoutDigest.LastIndexOf(':')
+    if ($lastColon -gt $lastSlash) {
+        return $withoutDigest.Substring(0, $lastColon)
+    }
+
+    return $withoutDigest
+}
+
+# Resolve the multi-platform digest. 'docker buildx imagetools inspect' reads the top-level manifest
+# straight from the registry, so for a multi-arch image this is the manifest list (image index) digest
+# rather than a single platform's digest. Pinning the index keeps the reference valid on every
+# platform the pipeline runs on.
+$digest = (docker buildx imagetools inspect $ImageBuilderImage --format '{{.Manifest.Digest}}')
+if ($LASTEXITCODE -ne 0 -or [string]::IsNullOrWhiteSpace($digest)) {
+    throw "Unable to resolve a multi-platform digest for '$ImageBuilderImage'."
+}
+
+$repository = Get-RepositoryName $ImageBuilderImage
+$imageBuilderRef = "$repository@$($digest.Trim())"
+
+Write-Output "Resolved ImageBuilder reference: $imageBuilderRef"
+
+# Run 'update' from the resolved digest, mounting the repository so it can write eng/docker-tools to
+# disk. The command must run from the repository root, which is why $RepoRoot is the mounted working
+# directory. Running by the same digest that gets recorded keeps the writer and the pinned reference
+# identical.
+Exec ("docker run --rm " `
+    + "-v `"${RepoRoot}:/repo`" " `
+    + "-w /repo " `
+    + "$imageBuilderRef " `
+    + "update $imageBuilderRef")

eng/docker-tools/templates/jobs/build-images.yml

@@ -10,6 +10,8 @@ parameters:
   # Custom steps that run after ImageBuilder is set up but before the build starts.
   # Use for build-specific initialization (e.g., setting variables, additional setup).
   customBuildInitSteps: []
+  # Custom steps that modify repository content before it is copied into the ImageBuilder image.
+  customPreImageBuilderBuildSteps: []
   publishConfig: null
   versionsRepoRef: ""
   noCache: false
@@ -41,6 +43,7 @@ jobs:
       versionsRepoRef: ${{ parameters.versionsRepoRef }}
       cleanupDocker: true
       customInitSteps: ${{ parameters.customInitSteps }}
+      customPreImageBuilderBuildSteps: ${{ parameters.customPreImageBuilderBuildSteps }}
   - ${{ parameters.customBuildInitSteps }}
   - template: /eng/docker-tools/templates/steps/reference-service-connections.yml@self
     parameters:
@@ -140,4 +143,4 @@ jobs:
         displayName: Publish SBOM
         internalProjectName: ${{ parameters.internalProjectName }}
         publicProjectName: ${{ parameters.publicProjectName }}
-        condition: ne(variables['BuildImages.builtImages'], '')
+        condition: and(succeeded(), ne(variables['BuildImages.builtImages'], ''))

eng/docker-tools/templates/jobs/cg-build-projects.yml

@@ -15,7 +15,7 @@ parameters:
 # See https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-install-script#options for possible Channel values
 - name: dotnetVersionChannel
   type: string
-  default: '9.0'
+  default: '10.0'
   displayName: .NET Version
 # Additional steps to run before building projects (e.g. custom SDK installation).
 - name: initSteps

eng/docker-tools/templates/jobs/post-build.yml

@@ -11,7 +11,6 @@ jobs:
   variables:
     imageInfosSubDir: "/image-infos"
     imageInfosHostDir: "$(Build.ArtifactStagingDirectory)$(imageInfosSubDir)"
-    imageInfosContainerDir: "$(artifactsPath)$(imageInfosSubDir)"
     imageInfosOutputSubDir: "/output"
     sbomOutputDir: "$(Build.ArtifactStagingDirectory)/sbom"
   steps:
@@ -73,11 +72,10 @@ jobs:
         exit 0
       }
 
-      New-Item -ItemType Directory -Path $(imageInfosHostDir)$(imageInfosOutputSubDir) -Force
       $(runImageBuilderCmd) mergeImageInfo `
         --manifest $(manifest) `
-        $(imageInfosContainerDir) `
-        $(imageInfosContainerDir)$(imageInfosOutputSubDir)/image-info.json `
+        image-infos `
+        image-infos/output/image-info.json `
         $(manifestVariables)
     name: MergeImageInfoFiles
     displayName: Merge Image Info Files
@@ -89,7 +87,7 @@ jobs:
         condition: and(succeeded(), ne(variables['MergeImageInfoFiles.noImageInfos'], 'true'), ne(variables['Build.Reason'], 'PullRequest'))
         args: >-
           createManifestList
-          '$(imageInfosContainerDir)$(imageInfosOutputSubDir)/image-info.json'
+          'image-infos/output/image-info.json'
           --repo-prefix '${{ parameters.publishConfig.BuildRegistry.repoPrefix }}'
           --os-type '*'
           --architecture '*'