Publish multiple docker version tags

[hallipr]

What does this PR do?

To allow for previous version patching without bumping everyone to a patch of a previous minor, we'll start publishing multiple tags like 2.0.1-amd64, 2.0-amd64, 2.0, latest

GitHub issue number?

#1495

Pre-merge Checklist

• Required for All PRs
  • Read contribution guidelines
  • PR title clearly describes the change
  • Commit history is clean with descriptive messages (cleanup guide)
  • Added comprehensive tests for new/modified functionality
  • Created a changelog entry if the change falls among the following: new feature, bug fix, UI/UX update, breaking change, or updated dependencies. Follow the changelog entry guide
• For MCP tool changes:
  • One tool per PR: This PR adds or modifies only one MCP tool for faster review cycles
  • Updated servers/Azure.Mcp.Server/README.md and/or servers/Fabric.Mcp.Server/README.md documentation
  • Validate README.md changes running the script ./eng/scripts/Process-PackageReadMe.ps1. See Package README
  • For new or modified tool descriptions, ran ToolDescriptionEvaluator and obtained a score of 0.4 or more and a top 3 ranking for all related test prompts
  • For tools with new names, including new tools or renamed tools, update consolidated-tools.json
  • For renamed tools, follow the Tool Rename Checklist and tag the PR with the breaking-change label
  • For new tools associated with Azure services or publicly available tools/APIs/products, add URL to documentation in the PR description
• Extra steps for Azure MCP Server tool changes:
  • Updated command list in servers/Azure.Mcp.Server/docs/azmcp-commands.md
  • Ran ./eng/scripts/Update-AzCommandsMetadata.ps1 to update tool metadata in azmcp-commands.md (required for CI)
  • Updated test prompts in servers/Azure.Mcp.Server/docs/e2eTestPrompts.md
  • 👉 For Community (non-Microsoft team member) PRs:
    • Security review: Reviewed code for security vulnerabilities, malicious code, or suspicious activities before running tests (crypto mining, spam, data exfiltration, etc.)
    • Manual tests run: added comment /azp run mcp - pullrequest - live to run Live Test Pipeline

[Copilot]

Pull request overview

Updates the Docker release pipeline and manifest publishing script to emit additional “minor version” tags (e.g., 2.0) alongside the full version and latest, enabling consumers to pin to a minor line while still receiving patch updates.

Changes:

• Add logic to publish multi-arch manifests for ${major}.${minor} tags when the version is a stable SemVer.
• Update the Docker release pipeline to also push ${major}.${minor}-<arch> tags for stable versions.
• Improve script output messaging around when minor-version tags are skipped.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
eng/scripts/Publish-DockerManifests.ps1	Publishes an additional minor-version multi-arch manifest tag (stable versions only).
eng/pipelines/templates/jobs/docker/release-docker.yml	Pushes additional minor-version arch tags and wires them into the release job.

[jongio]

One open question on the 1ES.PushContainerImage@1 task's remoteImage input - see inline comment. The inconsistent stability predicate between YAML and PS1 was already flagged in the Copilot review.

[jongio]

[INFO] API Contract: For stable releases, Amd64RemoteImages resolves to a comma-separated pair (e.g., repo:2.0.0-amd64,repo:2.0-amd64). Does 1ES.PushContainerImage@1 handle comma-separated remoteImage inputs? If it only accepts a single tag, the minor version arch images won't get pushed.