feat: add new image tags, git tags, dry run for testing

[NeethuESim]

STESOL-507 - Arm MCP Server environment versioning improvements

Docker image tags

The verified multi-arch image is published to Docker Hub with:

• latest — the prod image.
• A semantic version tag X.Y.Z (e.g. 2.3.0), auto-computed (not hardcoded). The highest existing X.Y.Z tag from git version is the source of truth; the next version is derived from it:
  • minor (X.Y+1.0) — automatic on weekly knowledge-base rebuilds (workflow_run).
  • major (X+1.0.0) / hotfix (X.Y.Z+1) — selected manually via the bump_type input.
• An immutable dated tag YYYY-MM-DD-github.run_number (e.g. 2026-06-15-1234) — the stage image.

latest/version aliases are applied only after the dated manifest is created and verified to contain both linux/amd64 and linux/arm64.

Git tags & release

• Pushes a matching annotated git tag vX.Y.Z for each published Docker version.
• Creates a GitHub Release with an auto-generated changelog (.github/release.yml).

server.json

• Bump mcp-local/server.json (version + OCI package identifier) to the computed version & directly merge into the main.

Safety / testing

• dry_run flag builds/validates without pushing images, manifests, git tags, or releases.
• Publishing is gated to main; non-main runs must use dry_run=true (fail-fast guard).

[Copilot]

Pull request overview

This PR enhances the MCP Docker image build workflow to support improved versioning and safer testing, by adding additional Docker tags, creating matching Git tags, and introducing a dry-run mode to avoid publishing artifacts during validation.

Changes:

• Adds a workflow_dispatch dry_run input to build without pushing images/manifests/Git tags.
• Extends multi-arch manifest publishing to also tag latest and a version tag.
• Adds a step to create and push a matching annotated Git tag for the published version.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

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

[Copilot]

Pull request overview

Copilot reviewed 1 out of 1 changed files in this pull request and generated 3 comments.

[Copilot]

Pull request overview

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

[brikin01]

I think we might also need to update mcp-local/server.json with the latest version tag?

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

[brikin01]

Thanks for all these changes! I just have two points:

1. It might be worth blocking publishing reruns. Rerunning the same workflow can calculate a new semver tag and publish another production version for the same build. Since we probably don’t want full release-repair logic, the simple fix is to fail publishing reruns and ask people to start a fresh workflow run instead.

2. I think we should rearrange a few steps. After determining TAG_VERSION, we should commit the server.json changes before creating the git tag/GitHub Release, so the release points to the commit with matching metadata. We should also move the production Docker tags to the end, so if something fails midway, we only have a dated staged image to retry or clean up, not a partially promoted production release.

Suggested flow:

1. Build/push arch images: DATE_TAG-amd64, DATE_TAG-arm64
2. Create the multi-arch staged image: IMAGE:DATE_TAG
3. Determine TAG_VERSION
4. Bump and commit server.json
5. Create the git tag and GitHub Release
6. Promote IMAGE:DATE_TAG to IMAGE:${TAG_VERSION} and IMAGE:latest

[NeethuESim]

Thanks for all these changes! I just have two points:

1. It might be worth blocking publishing reruns. Rerunning the same workflow can calculate a new semver tag and publish another production version for the same build. Since we probably don’t want full release-repair logic, the simple fix is to fail publishing reruns and ask people to start a fresh workflow run instead.
2. I think we should rearrange a few steps. After determining TAG_VERSION, we should commit the server.json changes before creating the git tag/GitHub Release, so the release points to the commit with matching metadata. We should also move the production Docker tags to the end, so if something fails midway, we only have a dated staged image to retry or clean up, not a partially promoted production release.

Suggested flow:

1. Build/push arch images: DATE_TAG-amd64, DATE_TAG-arm64
2. Create the multi-arch staged image: IMAGE:DATE_TAG
3. Determine TAG_VERSION
4. Bump and commit server.json
5. Create the git tag and GitHub Release
6. Promote IMAGE:DATE_TAG to IMAGE:${TAG_VERSION} and IMAGE:latest

Thanks for the review. 2 is a valid concern. However if steps 5 or 6 fail then we will have to revert server.json & additional clean ups will be needed. Working on re-ordering these steps for correct updation.

[NeethuESim]

Current order is as below -

1. Create dated multi-arch manifest
2. Determine version tag → TAG_VERSION
3. Bump server.json on main (commits first, exports bump_sha)
4. Add latest + TAG_VERSION Docker aliases
5. Create git tag + GitHub Release (at bump_sha), last

Now, git tag is the version cursor, and it's created last, so anything failing before it leaves the cursor unmoved and a re-run recomputes the same version (self-healing). So we need to make sure if this gh action fails at any step, it needs to be re-run to get everything updated.

This last scenario here can be ignored, since it is very rare case as window is very tiny. This could also be recovered manually by deleting the orphan tag or creating the missing release.

@brikin01 please review & let me know if this logic makes sense.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 4 comments.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

[brikin01]

Thanks for iterating on this. The updated ordering makes sense to me as a reasonable tradeoff: the git tag remains the version cursor, and failures before that point can be recovered with a fresh workflow run rather than GitHub’s rerun button.

I left a couple of small comments, mostly to clarify the workflow comments/error text so the recovery path is explicit. I also agree with the two minor Copilot comments (ignoring the “no existing version tag” one).

With just those minor changes, happy to approve. Really appreciate all the back and forth on this; there are definitely a bunch of edge cases in this type of workflow.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated no new comments.

[NeethuESim]

Thanks for iterating on this. The updated ordering makes sense to me as a reasonable tradeoff: the git tag remains the version cursor, and failures before that point can be recovered with a fresh workflow run rather than GitHub’s rerun button.

I left a couple of small comments, mostly to clarify the workflow comments/error text so the recovery path is explicit. I also agree with the two minor Copilot comments (ignoring the “no existing version tag” one).

With just those minor changes, happy to approve. Really appreciate all the back and forth on this; there are definitely a bunch of edge cases in this type of workflow.

Thanks for your review @brikin01, need to get as many eyes on this as possible to not miss any corner case. I have fixed all the open issues.

Stale after recent changes

[brikin01]

LGTM!