Rebuild track promotion engine to honor 2-week maintenance-window cadence

[sfreudenthaler]

Rebuild track promotion engine to honor 2-week maintenance-window cadence

Parent epic: #35693 · Workstream A (Launch mechanics) · Target: Jul 22

Background

This is a follow-on to the existing promotion engine built in #36160, which lives in the repo at core/cicd/evergreen-tracks/ (planner/executor/markers with taint + hold + forward-only). That engine currently advances standard and trailing on a daily age check (age ≥ ~14 / ~28 days). The launch decision is that Standard and Trailing recalculate every two weeks on the existing maintenance-window schedule, not continuously. The engine's planner and cron need to be reworked so a track only moves on a scheduled maintenance window, giving customers a predictable "your next possible update is on window date Y" answer.

Scope

• Change the promotion trigger from a daily cron to the existing maintenance-window schedule (every two weeks); latest may continue to advance on each release cut.
• Rework the planner so standard/trailing compute their target as of the maintenance window, not the calendar day — a release only becomes eligible for a track on a window boundary.
• Preserve existing forward-only, taint, and hold semantics from Floating Docker tags for Release Tracks: latest/standard/trailing promotion engine #36160.
• Emit/log the next scheduled window date so downstream comms (doc, picker) can surface it.
• Update cicd/evergreen-tracks/ planner tests and fixtures for window-based eligibility.
• Validate end-to-end against the dotcms/dotcms-test sandbox.

Out of scope

• The registry/executor mechanics themselves (built in Floating Docker tags for Release Tracks: latest/standard/trailing promotion engine #36160).
• Customer-selectable cadence (explicitly deferred by the epic).
• Any control-plane/API work (Workstream B).

Acceptance criteria

• standard/trailing only re-point on a maintenance-window boundary, verified in the sandbox across at least two simulated windows.
• Planner is deterministic for a given window date and set of tags; unit tests cover the boundary cases.
• Forward-only / taint / hold behavior from Floating Docker tags for Release Tracks: latest/standard/trailing promotion engine #36160 still holds under the new schedule.
• The next scheduled window date is exposed in the promotion run output/logs.
• README in cicd/evergreen-tracks/ updated to describe the 2-week cadence.

Depends on

• Builds directly on Floating Docker tags for Release Tracks: latest/standard/trailing promotion engine #36160 (promotion engine). This is the first launch task.

Blocks

• Finalize and publish the Release Tracks doc-site announcement #36521 (windows described in docs), dotCMS/private-issues#653 (enablement), dotCMS/infrastructure-as-code#7987 (canary move), dotCMS/dotusage#71 (telemetry).

Overlap note: closely related to existing issue #36160 — this is a follow-on cadence change, not a duplicate.

Part of the Evergreen Release Tracks epic. Parent: #35693.

---

Concrete scope (from Steve, 2026-07-11)

1. Cron schedule: adjust the promotion schedule so tag re-points cannot cause updates to deploy outside the maintenance window (no unexpected off-window deployments).
2. Floating-tag drift detection: build a tool — like the one in the OVH cloud-control cluster — that detects a SHA change under a floating tag and ensures the cluster actually picks it up.
3. Release-job isolation + regression test: when the release job triggers the floating-tag move, it must move latest only — never standard/trailing (moving those could trigger a deployment/pod roll). Cover this with a test so it can't regress later.

[github-actions]

PRs linked to this issue

• feat(evergreen-tracks): manual-only standard/trailing promotion, drop daily cron by @sfreudenthaler

[sfreudenthaler]

Completed by #36652 (merged 2026-07-21). The launch decision superseded the cron rework: standard/trailing move only on manual evergreen-tracks-promote dispatch — a human running the action at the maintenance window is the cadence gate, so tracks can never re-point off-window; latest still advances per release. Validated end-to-end against dotcms/dotcms-test (run 29797307325). Follow-ons split out: returning to a cron once reconciler crons are trusted → #36705; floating-tag drift detection → #36653.