4 Commits

Include renames

Author	SHA1	Message	Date
rmancinasandClaude Opus 5	e589bda28b	ci(build): skip the redundant master build when a release is cut ... release.yml pushes the release commit and its tag in a single `git push`, so Gitea created two build.yml runs for the same commit. Only the tag run matters: it emits the X.Y.Z and X.Y image tags, and since it is the same commit it publishes `latest` and `sha-<short>` as well. The master run was pure duplicate work that had to be waited out or cancelled by hand. Guard the build job with an `if` that skips a branch push whose head commit message starts with `chore(release):`. Ordinary pushes to master are unaffected, and tag pushes and manual dispatches always build. The skipped master run keeps the release commit's sha, which would have let release.yml's "Verify build.yml started" check go green on it alone even if the tag run were never created — the exact failure that check exists to catch. It now also requires the run's ref to be the tag, falling back to the sha match only when the API reports no ref. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 02:28:09 -07:00
rmancinasandClaude Opus 5	1934470d53	ci(release): dispatch the fallback build with a fully qualified ref ... Gitea's workflow dispatch API 404s on a bare `v1.0.3` and accepts only `refs/tags/v1.0.3`, so the fallback added in fdbe9fd would have failed the release instead of rescuing it. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 02:00:23 -07:00
rmancinasandClaude Opus 5	fdbe9fdb88	ci(release): fail the release when the build never starts ... Gitea creates workflow runs from the post-receive hook. When that hook errors the refs still land, git prints `remote: error: Internal Server Error` and exits 0 — a post-receive failure does not fail a push. v1.0.3 was cut exactly that way: tag pushed, no build run created, no images published, and the release step green. It surfaced two steps later as a 404 when the deploy tried to pull 1.0.3. Capture the push output and warn on `remote: error`, then verify a build.yml run actually exists for the new commit, dispatching it against the tag if not. Fail the release if that does not take either, so a release that publishes nothing is red instead of green. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 01:58:10 -07:00
rmancinasandClaude Opus 5	a8afd87c3f	ci: add a "Cut release" dispatch workflow ... Stamps every package.json, commits chore(release): vX.Y.Z, tags and pushes both refs in one dispatch — patch/minor/major, or an explicit number. Cutting a release from a laptop is how a manifest bump gets forgotten or a tag lands on an unpushed commit; the only input here is the number. Guards: refuses a version that already exists as a tag (releases are immutable), a no-op bump, a leading `v`, and a malformed number. Checkout is full-depth because the duplicate-tag check is meaningless against a shallow clone. Pushes with a RELEASE_TOKEN PAT rather than the built-in Actions token — whether a push made with that token re-triggers build.yml depends on the Gitea version, and a release that quietly publishes no images is worse than one that fails outright. Builds and deploys stay separate: the tag push triggers build.yml, and deploying remains a deliberate dispatch. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-01 01:21:13 -07:00