chore: Automate releases

[mcollina]

Automate releases for Fastify main package.

If the approach works, we can automate all modules using this GitHub script and org-wide release token.

Checklist

• documentation is changed or added
• commit message and code follows the Developer's Certification of Origin
  and the Code of conduct

[mcollina]

PTAL

[mcollina]

You can see it in action at https://github.com/mcollina/test-publish/actions/runs/8579478592

[jsumners]

Looks good to me.

[mcollina]

Unfortunately this is not compatible with protected branches.
Basically we need a more complex workflow, which I don't have time to develop atm.

Ideas would be welcomed at this point... I'm not entirely sure how to work around this.
A possible flow could be:

1. action creates a PR
2. human approves and merge the PR
3. action releases to GH and NPM

[jsumners]

Yep. This has been the big blocker the whole time.

[gurgunday]

Not sure if it's doable but we could maybe do:

• human creates a prerelease
• action makes the PR
• human merges
• action makes full release on GH and npm

Edit: this might be confusing

[Uzlopak]

I implemented releases actually differently:

https://github.com/cthulhu-oidc/workflows/blob/master/.github/workflows/release.yml
https://github.com/cthulhu-oidc/license-manager/blob/master/.github/workflows/release.yml

It uses the github release feature to commit the release and set the tags correctly.

It also contained the npm publish once cthulhu-oidc/workflows@5bdf367

So yeah, maybe instead triggering the release manually via a workflow dispatch, using the release feature is sexier?

[mcollina]

So yeah, maybe instead triggering the release manually via a workflow dispatch, using the release feature is sexier?

How does it work? The release feature require you to point to a commit, which must be added to main.

[mcollina]

@Uzlopak https://github.com/cthulhu-oidc/workflows/blob/f9892125c8bae3eac6f66576fde57cca61bb0f3f/.github/workflows/release.yml#L53 your branch is not protected.

[Eomm]

Suggested change

	releasenotes:
	release-notes:

[Eomm]

Unfortunately this is not compatible with protected branches

I think we do allow force push

[voxpelli]

If you protect the branches using the new ruleset feature rather than the old branch protection feature, then you can grant certain apps / roles a bypass: https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-rulesets/creating-rulesets-for-a-repository#granting-bypass-permissions-for-your-branch-or-tag-ruleset

[mcollina]

@voxpelli how that has anything to do with secrets access?

[voxpelli]

how that has anything to do with secrets access?

@mcollina It doesn't, it was in regards to protected branches and not being able to push to them:

Unfortunately this is not compatible with protected branches

[mcollina]

I've pushed a fix done in Undici.
This:

1. creates a PR
2. once that lands, it ships a release
3. one of the leads approves the release

[jsumners]

I remembered the new protections feature a bit ago but kept forgetting to revisit this thread. Thanks @voxpelli.

[Uzlopak]

See the pull request by @voxpelli actions/checkout#1184

Suggested change

	git config --global user.email "github-actions@github.com"
	git config --global user.name "github-actions"
	git config --global user.name "github-actions[bot]"
	git config --global user.email "41898282+github-actions[bot]@users.noreply.github.com"

[Eomm]

v6?

Maybe:
releases.map(r => r.tag_name).sort().at(-1)

[Eomm]

this script does not exist here

[Eomm]

Why do we run npm publish twice?
I would add a name to this step for clarity

[mcollina]

I would go back to this work after we ship v5, right now it's probably a lot of bespoke work.