Release on push so fork contributions can publish

[woksin]

Summary

A pull request from a fork cannot cut a release, and the run reports success anyway — so a merged, labeled contribution silently publishes nothing.

Added

• A check requiring exactly one major, minor or patch label before a pull request can be merged.

Changed

• Releases are cut on push to main instead of on the pull request closing, so contributions from forks publish like any other.
• The Publish run now fails when a merge releases nothing because the version label was missing, instead of reporting success.

[woksin]

Reviewer context. Part of an org-wide migration; Cratis/cli is already migrated and has cut a release this way (v2.8.1).

Why. A fork pull request runs with a read-only GITHUB_TOKEN and no secrets even on merge, so the release job cannot tag and the publish jobs have no credentials — while the run still reports success. Cratis/cli#72 merged with a minor label and released nothing. On push the token is full-permission, and the action resolves the pull request and its label live from the commit instead of from the event payload, which also closes the label-added-just-after-merge race.

Not pull_request_target. NuGet rejects it — GitHubTokenPolicyValidator checks event_name against BannedGitHubActionsEvents. push is not on that list, and cli published on push successfully.

cancel-in-progress must be false. Under pull_request each run had its own github.ref; on push every merge shares refs/heads/main, so leaving it true lets the next merge cancel a release possibly mid-publish.

Depends on release-action v1.2.0, which added the reason output. @v1 already points at it.

The paths filter is kept deliberately, against the action README's advice: the new check fails an unlabeled merge, and docs-only pull requests carry no label by design, so without the filter every docs merge would go red on main.

No concurrency block in this workflow, so there is nothing to cancel and none was added.

Specifications-specific. There is no separate release job here — the action runs as a step inside publish — so the released-nothing check is a final step keyed on steps.release.outputs.reason rather than a separate job. The trigger also had no branch filter at all, so it released from any base branch; it is now scoped to main.

Verification. Parses as YAML; trigger resolves to push on main; no github.event.pull_request or event_name == 'pull_request' references remain; the release job exposes reason. Not merged — over to you.