Skip to content

chore: publish only the Arc chart from the MCR workflow - #1373

Merged
Yoo Bin Shin (nibooy) merged 2 commits into
Azure:mainfrom
nibooy:update-arc-charts
Oct 13, 2026
Merged

Yoo Bin Shin (nibooy) merged 2 commits into
Azure:mainfrom
nibooy:update-arc-charts

Conversation

@nibooy

Copy link
Copy Markdown
Member

Description

Agent images are now built and published to MCR by a separate pipeline, with tags of the form <release tag>-<revision> (e.g. v0.18.16-1). This removes the image-building responsibility from build-publish-mcr.yml, leaving it to resolve the already-published tags and package the Arc member cluster agents Helm chart.

Workflow — dropped publish-images-amd64, publish-images-arm64 and create-image-manifest-bundle, leaving a single publish-arc-helm-chart job.

Tags are resolved from the public MCR registry API (/v2/<repo>/tags/list) by selecting the highest revision for a release tag:

  • RELEASE_TAG — from aks/v2/fleet/member-agent, based on the latest Azure/fleet tag (or the releaseTag input)
  • FLEET_NETWORKING_VERSION — from aks/v2/fleet/mcs-controller-manager, based on the latest Azure/fleet-networking tag (or the new fleetNetworkingReleaseTag input)

The member agent, refresh token and CRD installer share a revision, as do the two networking images, so one lookup per family is sufficient. A missing image now fails the run with the available tags listed, rather than producing a chart that points at a nonexistent tag. Checkout uses the plain release tag, since the revision suffix has no corresponding git tag.

Chart — repointed to the mcr.microsoft.com/aks/v2/fleet repository path where the new pipeline publishes, with the test fixtures kept in sync. Added a README covering the publishing flow and the values whose behavior does not match their names. Added *_test.go to .helmignore, which was shipping charts_test.go inside the published chart.

Verification

Dry-ran the prepare-variables script against live MCR:

release_tag=v0.18.16-1
git_ref=v0.18.16
fleet_networking_version=v0.3.44-2
arc_helmchart_version=0.18.16-1

Packaged the chart with those values and confirmed all five rendered image references return HTTP 200 from MCR:

mcr.microsoft.com/aks/v2/fleet/member-agent:v0.18.16-1
mcr.microsoft.com/aks/v2/fleet/refresh-token:v0.18.16-1
mcr.microsoft.com/aks/v2/fleet/crd-installer:v0.18.16-1
mcr.microsoft.com/aks/v2/fleet/mcs-controller-manager:v0.3.44-2
mcr.microsoft.com/aks/v2/fleet/member-net-controller-manager:v0.3.44-2

actionlint and go test ./charts/member-agent-arc/... both pass.

Notes for reviewers

  • The chart version 0.18.16-1 is a semver pre-release of 0.18.16. This is safe for the Arc consumer: ClusterConfigDP persists only major/minor/patch and orders by c.MajorVersion desc, c.MinorVersion desc, c.PatchVersion desc, c._ts desc, so the revision sorts equal to the base tag and ties break on write time. It would not be safe for helm search/helm install, which skip pre-releases without --devel.
  • Image tags are resolved from the MCR registry API rather than the MCR status portal; the portal is an AAD-authenticated SPA and cannot be queried from CI.

🤖 Generated with Claude Code

yoobinshin and others added 2 commits October 13, 2026 14:06
Agent images are now built and published to MCR by a separate pipeline, with
tags of the form <release tag>-<revision> (e.g. v0.18.16-1). Drop the image
build, arch-specific publish and manifest bundling jobs, leaving the workflow
to resolve the already-published tags and package the Arc chart.

Tags are resolved from the MCR registry API by selecting the highest revision
for a release tag. The chart is checked out at the plain release tag, since the
revision suffix has no corresponding git tag.

Point the Arc chart at the aks/v2/fleet repository path, where the new pipeline
publishes, and add a README covering the publishing flow and the chart values
whose behavior does not match their names.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
git describe reads tags from the checked-out repository, which a fork does not
have: GitHub does not copy tags when forking, so the workflow failed with
"fatal: No names found, cannot describe anything" on any fork.

Read both release tags from the GitHub API instead, matching how the
fleet-networking tag was already resolved, and fail with a clear message when
a tag cannot be resolved rather than passing "null" downstream. The
prepare-variables job no longer needs a checkout.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@nibooy
Yoo Bin Shin (nibooy) merged commit 854a5c5 into Azure:main Oct 13, 2026
25 of 30 checks passed
@nibooy
Yoo Bin Shin (nibooy) deleted the update-arc-charts branch October 13, 2026 23:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants