feat: add reusable release workflow

[Eomm]

What

Replaces .github/workflows/release.yml with a reusable (workflow_call) release workflow that fastify repositories can call to publish a new version.

The workflow:

1. validates the semver input (patch | minor | major)
2. bumps the version and commits it as Bumped vX.Y.Z
3. installs dependencies with --ignore-scripts
4. runs npm run --if-present release:build
5. publishes to npm with --provenance (OIDC, no NPM_TOKEN needed)
6. pushes the release commit and creates the GitHub release with generated notes

All actions are pinned by commit SHA, using the same actions/checkout and actions/setup-node versions already declared in plugins-ci.yml.

Notes

• The workflow deliberately does not run the test suite: CI is expected to have already validated the commit being released.
• persist-credentials: true is required here (and commented as such) because the job pushes the release commit and tag.
• Consuming packages must be configured as npm trusted publishers for the OIDC publish to succeed.
• The previous content of release.yml (the optic-release-automation-action pipeline used to release this repository itself) is removed by this PR. Releases of fastify/workflows need to be handled separately.

README.md documents the inputs, the required permissions and a ready-to-copy caller snippet.

[Eomm]

Added a release deployment environment gate (configurable via the new environment input) so repositories can restrict who is allowed to release: workflow_dispatch alone is available to anyone with write access, while an environment with required reviewers pauses the job before any step runs.

Documented in the README, including the npm trusted publisher Environment field that can be pinned to the same name.

[Tony133]

Two questions came to mind:

1. npm publish runs before git push: what happens if the push is rejected? I'm thinking of cases where main is protected by rules blocking direct pushes via GITHUB_TOKEN, a common scenario in most Fastify repositories. Wouldn't we risk ending up with the version published on npm but without the corresponding commit or tag in the repository, with any retry failing because the version would already exist? Should the repositories grant the bot a bypass, or would it be safer to push first?

2. Regarding "Releases of fastify/workflows need to be handled separately": do we already have a plan for this? The README references @v7, so someone will need to create that tag once this change is merged. Would it make sense to name this file plugins-release.yml (aligning with plugins-ci.yml) and keep the current release.yml for this repository, or am I missing something? 😅

[Fdawgs]

This should be its own workflow called reusable-release.yml.

The current release workflow is just for releasing new shared/reusable workflow versions.
The sync-semver-tags option is used with the nearform release action so when, for example, v7.0.1 is released, it then moves the v7 and v7.0 tags to the v7.0.1 release.

[Eomm]

This should be its own workflow called reusable-release.yml.

The current release workflow is just for releasing new shared/reusable workflow versions. The sync-semver-tags option is used with the nearform release action so when, for example, v7.0.1 is released, it then moves the v7 and v7.0 tags to the v7.0.1 release.

Nobody is using that release.yml. I added it for an experiment than I left it there.

[Fdawgs]

This should be its own workflow called reusable-release.yml.
The current release workflow is just for releasing new shared/reusable workflow versions. The sync-semver-tags option is used with the nearform release action so when, for example, v7.0.1 is released, it then moves the v7 and v7.0 tags to the v7.0.1 release.

Nobody is using that release.yml. I added it for an experiment than I left it there.

I'm using it for this repo! 😆

See #224

[Eomm]

This should be its own workflow called reusable-release.yml.
The current release workflow is just for releasing new shared/reusable workflow versions. The sync-semver-tags option is used with the nearform release action so when, for example, v7.0.1 is released, it then moves the v7 and v7.0 tags to the v7.0.1 release.

Nobody is using that release.yml. I added it for an experiment than I left it there.

I'm using it for this repo! 😆

See #224

OPS fixed

[Tony133]

I think the first point is still open: npm publish still runs before git push origin HEAD. In repositories where main is protected against direct pushes via GITHUB_TOKEN, the push would fail after the version is already on npm, leaving no commit or tag in the repo and making any retry fail.

Could we move the "Push release commit" step before "Publish to npm"? If the push fails, nothing gets published. It would also be worth adding a note to the README about allowing GitHub Actions to bypass branch protection (e.g. via a ruleset).

Suggested change

	- name: Publish to npm
	run: npm publish --provenance --access public
	- name: Push release commit
	run: git push origin HEAD
	- name: Push release commit
	run: git push origin HEAD
	- name: Publish to npm
	run: npm publish --provenance --access public