release event triggers with an empty github.ref, silently skipping sign/release jobs (broke 10.1.0 and 10.1.1 publishing)

[adrianhall]

Summary

The last two releases (10.1.0 and 10.1.1) failed to publish signed NuGet packages because the sign and release jobs in build-library.yml and build-template.yml were silently skipped — not failed — on the release: published trigger.

Root cause

Both jobs gate on github.ref:

sign:    if: ${{ github.ref == 'refs/heads/main' || startsWith(github.ref, 'refs/tags/') }}
release: if: ${{ startsWith(github.ref, 'refs/tags/') }}

On run 28783150142 (the 10.1.1 release), $GITHUB_REF was empty in the build job (verified byte-for-byte in the raw log), even though GitHub's docs state GITHUB_REF for a release event should be refs/tags/<tag_name>.

This isn't a one-off: the 10.1.0 release (27936434216) hit the identical bug on build-template.yml. Releases before that (10.0.1 and earlier) worked correctly — github.ref genuinely resolved to the tag. The regression's timing lines up with GitHub's June 18, 2026 "Control who and what triggers GitHub Actions workflows" change, though this couldn't be fully confirmed without org-admin access to check for enterprise/org rulesets. Notably, every release in this repo tags the exact tip of main, which may be a contributing factor to whatever ambiguity is being hit.

Impact

• 10.1.0: library packages were manually recovered via workflow_dispatch (ref=10.1.0), but CommunityToolkit.Datasync.Server.Template.CSharp never published — nuget.org is still stuck at 10.0.1 for the template package.
• 10.1.1: both library and template packages were skipped; being manually recovered via workflow_dispatch on ref=10.1.1 (see recent runs).
• The attempted manual recovery for 10.1.0's template package also surfaced a second, unrelated issue: the old NUGET_PACKAGE_PUSH_TOKEN-based push started failing with a 403 (expired/invalid key), which is what motivated the move to NuGet Trusted Publishing in build: enable NuGet trusted publishing for release workflows #494/Enable Trusted Publishing #486.

Recommended fix

In both build-library.yml and build-template.yml:

1. Stop gating sign/release on github.ref string matching. Use the triggering event instead, which doesn't depend on ref resolution:

   sign:
     if: ${{ (github.event_name == 'push' && github.ref == 'refs/heads/main') || github.event_name == 'release' }}
   release:
     if: ${{ github.event_name == 'release' }}

   (Leave workflow_dispatch working as-is for manual recovery.)
2. Stop relying on $env:GITHUB_REF in tools/GetBuildVersion.psm1 for release events. Pass github.event.release.tag_name explicitly (e.g., build VersionString as refs/tags/${{ github.event.release.tag_name }} when github.event_name == 'release', else fall back to $env:GITHUB_REF), so a blank ref can't silently produce a wrong package version even if the gating logic is fixed.
3. Fail loudly instead of skipping silently. Add a guard step in release (gated on github.event_name == 'release') that asserts github.ref_name == github.event.release.tag_name and emits ::error:: + exits non-zero if not — turning this into a visible red ❌ instead of a quiet "skipped" that went unnoticed for a week last time.
4. Optional: a scheduled workflow that compares the latest git tag to the latest published NuGet.org version and opens an issue on drift, to catch this class of failure automatically.
5. Optional: file a GitHub Support ticket / community discussion referencing runs 28783150142 and 27936434216 as evidence, since an empty GITHUB_REF for release events contradicts documented platform behavior.

Known gap (accepted)

CommunityToolkit.Datasync.Server.Template.CSharp@10.1.0 will remain unpublished on nuget.org. Backfilling it isn't a simple re-dispatch, since workflow_dispatch on ref=10.1.0 would run the pre-OIDC workflow (same expired-token 403). Decided to leave this gap rather than rotate the old token for a superseded version.

[adrianhall]

Note to self: by way of test, we will release 10.1.2 to test the release.