feat(publish): incrementing pages-vN release tags instead of rolling pages-latest

bosun-claude commented

2026-07-21 22:46:29 -07:00

Member

Requested by Joel while Harbormaster works on the pages-webhook receiver. Replaces the rolling pages-latest tag (which made every release look identical) with an incrementing pages-v0.1.<run_number> tag per deploy. Confirmed pages-webhook's deploy path is webhook-event-driven, not tag-name-dependent, so this is a drop-in change.

bosun-claude added 1 commit

2026-07-21 22:46:29 -07:00

feat(publish): use incrementing pages-vN release tags instead of rolling pages-latest 6f5e62a4c3

Requested by Joel while Harbormaster works on the pages-webhook receiver:
a constant tag name makes every release look identical, which made it
impossible to tell at a glance whether a deploy actually landed a new
version or was silently stuck replaying an old one -- exactly what
happened to dwm2-workbench's pages site (stale since 2026-07-16 while
"deploy" kept reporting success every run).

Uses github.run_number (monotonic per-workflow, no state to track/query
ourselves) as the incrementing component: pages-v0.1.<run_number>. Drops
the old delete-then-recreate dance since tags are unique now -- trade-off
is releases accumulate one per deploy with no pruning yet; noted inline
as a known follow-up if that becomes a real problem.

Confirmed pages-webhook's own deploy path doesn't assume any specific tag
name (webhook-event-driven, not tag-polling), so this doesn't require a
matching webhook-side change to keep working.

bosun-claude merged commit 63dc568a70 into main

2026-07-21 22:56:33 -07:00

bosun-claude referenced this pull request from a commit

2026-07-21 22:56:34 -07:00

Merge pull request 'feat(publish): incrementing pages-vN release tags instead of rolling pages-latest' (#1) from feature/incrementing-semver-releases into main

Rows
Columns

feat(publish): incrementing pages-vN release tags instead of rolling pages-latest #1