Problem
When the 2026-08-12 release cut failed to move latest (#37025 — Hub started refusing anonymous tag pagination), there was no supported way to repoint it:
cicd_evergreen-tracks-promote.yml hardcodes --tracks standard,trailing and has no input to change that.cicd_evergreen-tracks-admin.yml only does taint / untaint / hold / release-hold.- Re-running the failed release job replays the pre-fix commit, so it just fails again.
The only route left was cutting a throwaway release to repoint a tag — which is what we did (26.08.12-02, code-identical to -01 apart from the CI fix). That works, but rebuilding artifacts, redeploying to Artifactory, regenerating release notes and publishing a changelog entry to dev.dotcms.com is a lot of blast radius for moving one floating tag, and it puts a phantom release in front of customers.
Proposal
Add a tracks dispatch input to the promote workflow, defaulting to standard,trailing.
- The daily cron and every existing dispatch behave exactly as today — a
schedule event carries no inputs at all, which the || fallback covers.
tracks=latest becomes the break-glass path, behind the same evergreen-tracks-apply required-reviewer gate as any other manual move.- The apply job still holds the
evergreen-tracks-registry lock, so it cannot race the release pipeline's latest-promote. If a GA cut repoints latest while an approval sits, the existing drift check makes apply refuse rather than fight the release pipeline — the correct outcome.
Also fixes a latent bug
The moved-summary grep matches only ^(standard|trailing):
MOVES=$(printf '%s\n' "$CURRENT_PLAN" | grep -E '^(standard|trailing) (\(held\) )?-> ' ...)
So a latest move would apply correctly but report moved=false and post no Slack notice. Silent success is the one outcome this workflow is built to avoid. Widened to include latest.
Related: #37025, #37028.
Problem
When the 2026-08-12 release cut failed to move
latest(#37025 — Hub started refusing anonymous tag pagination), there was no supported way to repoint it:cicd_evergreen-tracks-promote.ymlhardcodes--tracks standard,trailingand has no input to change that.cicd_evergreen-tracks-admin.ymlonly does taint / untaint / hold / release-hold.The only route left was cutting a throwaway release to repoint a tag — which is what we did (
26.08.12-02, code-identical to-01apart from the CI fix). That works, but rebuilding artifacts, redeploying to Artifactory, regenerating release notes and publishing a changelog entry to dev.dotcms.com is a lot of blast radius for moving one floating tag, and it puts a phantom release in front of customers.Proposal
Add a
tracksdispatch input to the promote workflow, defaulting tostandard,trailing.scheduleevent carries no inputs at all, which the||fallback covers.tracks=latestbecomes the break-glass path, behind the sameevergreen-tracks-applyrequired-reviewer gate as any other manual move.evergreen-tracks-registrylock, so it cannot race the release pipeline's latest-promote. If a GA cut repointslatestwhile an approval sits, the existing drift check makes apply refuse rather than fight the release pipeline — the correct outcome.Also fixes a latent bug
The moved-summary grep matches only
^(standard|trailing):So a
latestmove would apply correctly but reportmoved=falseand post no Slack notice. Silent success is the one outcome this workflow is built to avoid. Widened to includelatest.Related: #37025, #37028.