Tag pushes do not trigger the major-tag workflow

[Project516]

release.yml ("Move major tag") is supposed to run on push of a v* tag and repoint v1 at the newest stable release in the series. It has never run: gh api repos/Project516/setup-flutter/actions/workflows/release.yml/runs returns total_count: 0.

Observed today while cutting v1.0.2:

• git push origin v1.0.2 created the tag (the ref exists via the API) and produced no workflow run.
• A follow-up git push --force origin refs/tags/v1 also produced no run.
• Pushes to main in the same session did trigger verify, so Actions is enabled and working in this repo.
• Repo Actions permissions are enabled: true, allowed_actions: all.

v1 was moved by hand to 0bb915d so consumers of Project516/setup-flutter@v1 get the lockfile cache-key fix from #6. The automation is still broken, so the next release will strand v1 again.

Worth checking:

• Whether the tag ref that triggers the run needs the workflow file present at that ref (it is: the tag's commit contains release.yml).
• Whether the push credential matters here, and whether pushing the tag from the Actions side (a release-publish trigger instead of a tag-push trigger) is the more reliable shape. on: release: [published] would fire from the release step that already happens, rather than from a bare tag push.

[Project516]

Update: the diagnosis behind PR #9 needs a caveat. GitHub Actions had a major outage starting 2026-08-26T15:11 UTC (githubstatus.com: Actions major_outage, Pages degraded). Every probe recorded above ran inside or right before that window: v1.0.2 at 15:01, the forced v1 push a few minutes later, and a follow-up v0.0.1-triggertest probe at ~15:16. Queued-and-never-started runs and startup_failure results are exactly what this outage produces elsewhere in the org, so "tag pushes never trigger this workflow" may be an artifact of the outage rather than a real defect in the push: tags: trigger.

What still stands: the workflow has never produced a run, on any tag push so far, including before today. What no longer stands, until re-checked outside an outage window: the conclusion that the trigger itself is broken.

PR #9 (switching the trigger to release: published/released) is on hold pending a clean re-probe once Actions is confirmed healthy again. The probe tag v0.0.1-triggertest is kept on the remote for that re-probe.

[Project516]

Not a defect. Tag pushes do trigger the workflow.

Cutting v1.0.3 at 17:10 UTC pushed the tag; Move major tag fired on that push and logged v1 now points at v1.0.3, which the ref confirms. Nothing in the workflow needed changing, so the trigger-swap PR (#9) is closed.

What the original report actually caught was the GitHub Actions incident opened at 15:11 UTC. The v0.0.1-triggertest push did create a run, id 32984585210, but no runner ever acquired the job: the run has no steps and a null job conclusion. The v1.0.2 push minutes earlier produced no run at all, inside the same degraded window. The total_count: 0 in the original report was true and still misleading, because the workflow had simply never been exercised before today.

One gap worth knowing about, surfaced by CodeRabbit on #9 and not fixed: promoting an existing prerelease to stable emits released and pushes no tag, so v1 would not move for that path. This repo publishes stable releases directly, so there is nothing to do now. If prereleases ever get used here, add release: types: [released] alongside the push trigger.

The probe tag is deleted.