mirror of
https://github.com/rcourtman/Pulse.git
synced 2026-09-10 02:25:56 +00:00
rcourtman
3566a4d61d
promote-floating-tags.yml's `workflow_run` chain off publish-docker.yml silently stopped firing for rc.3 → rc.5 because publish-docker failed at the now-removed pulse-agent push step. Customers pulling rcourtman/pulse:latest, :6, or :6.0 stayed on whatever the previous successful release had tagged — there was no warning anywhere that the floating tags were stale. Same fix pattern as install-sh-smoke (commit7c0f65425) and publish-helm-chart (commit14c79a28e): add a workflow_call trigger to promote-floating-tags.yml and call it explicitly from create-release.yml after validate_release_assets succeeds. Gating on validate_release_assets is intentional: that workflow waits for the docker image to be pullable from the registry (with retry backoff), so by the time it succeeds the image manifest exists and re-tagging it to latest/major/minor cannot point at vapor. The legacy workflow_run trigger stays as the primary path; this just guarantees promotion even when the chain doesn't fire. Tag-resolver step now accepts inputs from workflow_call / workflow_dispatch and only falls back to the workflow_run derivation when inputs are absent, so all three entry paths converge on the same identity. Pinned in build_release_assets_test.go: - new TestPromoteFloatingTagsReachableViaWorkflowCall pins the trigger declaration and the input-priority resolver - existing TestCreateReleaseUploadsPowerShellInstaller extended to pin the promote_floating_tags job wiring (uses, tag, prerelease) Contract delta in deployment-installability.md Extension Point 7 documents the same explicit-workflow_call requirement that applies to publish-helm-chart, extended to promote-floating-tags.