Tag and release from a version bump that reaches main

[MAUstaoglu]

The last manual step in the release chain was pushing the tag after main synced. Forgetting it is silent: main carries a bumped version, no release exists, and nothing reports anything.

Tag release runs after Sync main, reads the version from main's pubspec, and does nothing unless there is no matching tag — which is the case for most merges, so the quiet path is the common one. The version is the trigger deliberately: bumping it is already a considered decision made in a reviewed pull request, and this carries that decision out rather than making a new one. Nothing here decides whether to release.

The part that would have made it silently useless

GitHub suppresses workflow triggers for pushes made with GITHUB_TOKEN, so a tag pushed by a workflow cannot start Release the way a hand-pushed one does. Left implicit, the tag would land on the repository with no release built and no failure reported — the exact gap this exists to close, reintroduced one level up.

So Release gained a workflow_call entry point and is invoked explicitly. The suppression then works in our favour: the two entry points cannot race to create the same release. A hand-pushed tag still behaves exactly as before.

Release also takes the tag as an input now. Under workflow_call the caller's ref is checked out by default — main — which would build whatever main had become by then rather than the tagged commit.

No new secrets. A PAT would also have worked, at the cost of an expiry that fails this the same silent way.

Tag naming

Tags here are v<flutter>-tvos.<cli> (v3.47.1-tvos.1.7.0), as every release since 3.41.4 has been. The CLI version alone drops the one thing the scheme records — which Flutter release the CLI and artifacts pair with — and the two move independently, so the pairing is not recoverable afterwards.

Only the Flutter commit is pinned in the repo, so the version is resolved back from it against flutter/flutter's tags rather than duplicated into a second file that could drift from the pin. A pin with no release tag pointing at it is a hard failure: it means the pair cannot be named, and guessing would produce a tag that misdescribes what shipped.

Verified against the current tree: pin 6655482e resolves to 3.47.1, pubspec reads 1.7.0, and the composed tag is v3.47.1-tvos.1.7.0 — the tag 1.7.0 actually shipped under.

What happens when this lands

It runs for the first time on its own merge, finds main at 1.7.0 with v3.47.1-tvos.1.7.0 already present, and exits without doing anything — which is the behaviour to expect from most merges, and a harmless first exercise.

[MAUstaoglu]

Folded into #72 rather than merged on its own.

Both commits here (ea4ca86, e814718) are ancestors of that branch, so nothing is lost by closing this — tag-release.yml and the release.yml changes ship there unchanged.

The reason for combining them: #72 bumps the version to 1.8.0, and this workflow is what turns a version bump reaching main into a tag and a release. Landing them separately would have meant the merge order decided whether 1.8.0 released. Together, merging #72 releases it, which is what this workflow was built to do.

They merged clean — both touch .github/workflows/release.yml, but in different places, and the merged file keeps the workflow_call entry point from here alongside a tightened analyze step from #72.

The ci/auto-tag-release branch is left in place.