Misc | CI: Add tag-driven npm release workflow

[50rayn]

What

• Add .github/workflows/release.yml — triggers on version tag pushes ([0-9]*, not v* — see note below)
• Stable tag (1.2.3) → publish:all; beta tag (1.2.3-beta.N) → publish:all:beta; anything else fails loudly
• After publish, creates a GitHub Release with auto-generated notes from merged PRs (softprops/action-gh-release)
• Adds --provenance --access public to publish:dist / publish:angular for npm package provenance — supply-chain attestation linking each release back to this repo and workflow
• Marks @unovis/dev as private (examples app, should never be published)

Why

Manual publish flow is error-prone. This wires up a standard tag → publish → release pipeline.

Note on tag format

unovis uses bare X.Y.Z tags (not v-prefixed) — the one v1.4.5 in history is a stray. The trigger glob is [0-9]* intentionally. A v1.6.6 tag would not trigger this workflow. If the team switches to v-prefixed tags later, the trigger glob and the validation regex in the publish step both need to be updated.

Setup

Needs an NPM_TOKEN repo secret with publish + provenance permissions before this can run.

[rokotyan]

This is nice!

After publish, creates a GitHub Release with auto-generated notes from merged PRs (softprops/action-gh-release)

Question: can we make GitHub releases for stable tags only? Otherwise the releases log can get noisy.

[50rayn]

It simplifies everything, agreed. I was actually thinking about recent beta releases (e.g. 1.6.6-beta.1) — we could generate a GitHub Release for those too, just tagged as pre-release. It would give betas a visible changelog, which might motivate users actually to test them. It could be a good way to build some community around pre-releases.

[rokotyan]

@50rayn Good point. We can try that and see if we like it or not

[lee00678]

@50rayn we are considering this, trying to figure out what's the best approach for the setup. Will get back to you. Thanks for the contribution!

[50rayn]

Sounds great, take your time! Happy to adjust the workflow once you've settled on an approach — just let me know what direction you'd prefer.

A few thoughts while you're at it:

• Personally, I prefer the v prefix on version tags (e.g. v1.7.0), but I know that's more the Vue community convention 😃
• I also updated the workflow to drop NPM_TOKEN in favour of npm's Trusted Publisher (OIDC) — no secret needed, provenance comes for free. Here's how I have it set up in one of my own projects: poveste/release.yml, and the npm side just needs a Trusted Publisher entry pointing to release.yml.

• One thing I'm not fully happy with in the current file is the if/elif branching to detect stable vs beta tags. The cleaner alternative might be two separate workflow files — release.yml (triggered by X.Y.Z tags) and release-beta.yml (triggered by X.Y.Z-beta.N tags) — each dead simple, no shell logic. Happy to restructure if that direction appeals to you!