ci: adopt release-please for release workflow

[michaelfaith]

This change breaks releases out to its own workflow and switches from semantic releases to release-please.

This is consistent with eslint-plugin-eslint-plugin, and will allow for more strategic release workflows. Rather than every change being released immediately, release please will create a release please PR, based on the nature of the commits that haven't been released before. It uses the same conventional commit commit format, so there's no need to change any existing conventions. Release please will manage if the release pr should be major, minor, or patch, based on the list of unreleased commits. At the point where you're ready to move forward with the release, you just have to merge the release PR, and release please will handle creating the GH release, updating the CHANGELOG and creating the repo tag. The workflow will then run the build and npm publish when a release was successfully created.

Important

In order for this work to be complete the following will need to be done by a maintainer:

• Update NPM Trusted Publishing configuration to point to release.yml instead of ci.yml
• Create a PAT for Release Please to use and add it as a repo secret, so that downstream workflows will be triggered successfully (https://github.com/googleapis/release-please-action?tab=readme-ov-file#other-actions-on-release-please-prs) - Name: RELEASE_PLEASE_TOKEN)

After merging this PR, the alpha branch should be merged into main, which will create the new major version release PR. But make sure it is not a squash merge, or else the commits won't be preserved for the changelog.

Closes #273
Closes #236

[michaelfaith]

Example of release PR in one of the repos that I migrated last week: michaelfaith/eslint-plugin-package-json#1482

Successful release: https://github.com/JoshuaKGoldberg/eslint-plugin-package-json/releases/tag/v0.87.1

PR that made it happen: michaelfaith/eslint-plugin-package-json#1478

[michaelfaith]

Another note: the semantic release flow used the same format for repo tags as release-please, so that'll "just work" the same as before, and users won't notice any difference in that regard.

I just noticed there's not a CHANGELOG in the repo, so I guess it won't do anything there. Is that something that you'd want to change? Would you want to add a CHANGELOG.md? This would do the changelog updates if there was one.

[MichaelDeBoey]

This is consistent with eslint-plugin-eslint-plugin

@michaelfaith Looking at eslint-community/eslint-plugin-eslint-plugin/[...]/release-please.yml, this workflow seems to be totally different

• Update NPM Trusted Publishing configuration to point to release.yml instead of ci.yml

That shouldn't be a problem

• Create a PAT for Release Please to use and add it as a repo secret, so that downstream workflows will be triggered successfully (https://github.com/googleapis/release-please-action?tab=readme-ov-file#other-actions-on-release-please-prs) - Name: RELEASE_PLEASE_TOKEN)

Again looking at eslint-community/eslint-plugin-eslint-plugin/[...]/release-please.yml, this PAT isn't used.

Looking at other @eslint-community repos that are using release-please (see eslint-community/eslint-plugin-n/[...]/release-please.yml, eslint-community/eslint-plugin-promise/[...]/release-please.yml & eslint-community/eslint-plugin-security/[...]/release-please.yml), they also don't use a PAT

PR that made it happen: JoshuaKGoldberg/eslint-plugin-package-json#1478

This PR also isn't using a PAT, so I guess we can get rid of using the PAT as well?

After merging this PR, the alpha branch should be merged into main, which will create the new major version release PR. But make sure it is not a squash merge, or else the commits won't be preserved for the changelog.

That shouldn't be a problem either

I just noticed there's not a CHANGELOG in the repo, so I guess it won't do anything there. Is that something that you'd want to change?

Releases will still have the same info as they currently have, I suppose?
If so, I think it's fine to not have a CHANGELOG.md, because people can just look at the GitHub releases to see what changed

[Copilot]

Pull request overview

This PR migrates the release workflow from semantic-release to release-please, enabling more strategic control over releases through pull requests. Instead of automatic releases on every push, release-please creates a release PR that aggregates unreleased commits and determines the appropriate version bump (major, minor, or patch) based on conventional commit messages.

Key changes:

• Adoption of release-please for managing releases via PRs
• Separation of release logic into a dedicated workflow triggered only on the main branch
• Creation of a reusable composite action for common setup tasks (checkout, Node.js setup, dependency installation)

Reviewed changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 6 comments.

Show a summary per file

File	Description
release-please-config.json	Configures release-please with changelog sections and release type
.release-please-manifest.json	Tracks the current version (4.9.1) for release-please
package.json	Updates version from semantic-release placeholder to actual version 4.9.1
.github/workflows/release.yml	New workflow for release-please execution and npm publishing
.github/workflows/post-release.yml	New workflow to comment on issues/PRs when included in a release
.github/workflows/ci.yml	Removes release job and refactors to use reusable setup action
.github/workflows/GHPages.yml	Refactors to use reusable setup action
.github/actions/setup/action.yml	New composite action consolidating checkout, Node setup, and npm install

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[michaelfaith]

This is consistent with eslint-plugin-eslint-plugin

@michaelfaith Looking at eslint-community/eslint-plugin-eslint-plugin/[...]/release-please.yml, this workflow seems to be totally different

Yeeeah, I've been meaning to address that. I just meant that release-please as a tool is consistent, not that our implementation is necessarily consistent. They didn't do the v3 -> v4 update properly. The variables they have declared in the workflow were moved to a config file (https://github.com/googleapis/release-please-action?tab=readme-ov-file#upgrading-from-v3-to-v4). If you look in their release workflow, it's complaining about those variables not existing anymore (https://github.com/eslint-community/eslint-plugin-eslint-plugin/actions/runs/19239812037/job/54999370466)

This PR also isn't using a PAT, so I guess we can get rid of using the PAT as well?

I had to add it in a follow-up PR here: michaelfaith/eslint-plugin-package-json#1486
Because the CI workflows weren't triggering without it (as described in the docs I linked)

You will want to configure a GitHub Actions secret with a Personal Access Token if you want GitHub Actions CI checks to run on Release Please PRs.

I'm not sure how the eslint-community repos are getting by without it, unless they're just not running CI on the release PRs?

Releases will still have the same info as they currently have, I suppose?

They will 👍

[michaelfaith]

Btw, i would love to not have to use a PAT, so i'm totally OK with removing it. But i suspect that if we do that, that ci won't run on those PRs.(at which case you could just add it separately like i did). What do you think?

[michaelfaith]

Another data point from a different repo: https://github.com/yargs/yargs/blob/main/.github/workflows/release-please.yml

[michaelfaith]

The copilot feedback is valid. I'll need to adjust that action. I'll have to do that tomorrow (along with any adjustments you'd like)

[MichaelDeBoey]

@michaelfaith I think the main "problem" here is needing the PAT as we finally got rid of any tokens needed in all our repos since we're using trusted publishing, so I'm not a fan of introducing any tokens again if we really don't need them.

If you could have a look at the other @eslint-community repos and try to figure out why it's not necessary there, we could bring this PR in line with that.

I'm fine with having the separate files for config, as that's what we have with eslint-community/eslint-plugin-n/[...]/release-please & https://github.com/eslint-community/eslint-plugin-security/[...]/release-please as well

[michaelfaith]

@michaelfaith I think the main "problem" here is needing the PAT as we finally got rid of any tokens needed in all our repos since we're using trusted publishing, so I'm not a fan of introducing any tokens again if we really don't need them.

If you could have a look at the other @eslint-community repos and try to figure out why it's not necessary there, we could bring this PR in line with that.

It looks like they're just not running CI on release PRs.

Regular PR Checks:

Release PR Checks:

I think that's a valid approach, but I'd don't have visibility to their repo settings to see what they have defined for that. So that might be something you'd have to configure, and then I should be able to pull the token?

[michaelfaith]

Ok, I think I understand now. Not running CI will only be a problem if you have branch protections that require specific CI steps to pass in order for a PR to merge. Josh has specific CI steps required to pass on all PRs, so when CI didn't run in our repos, it didn't satisfy those conditions and so the PR wasn't mergeable. But the community repos don't appear to have any of the CI steps set as "required". If that's the case for this repo too, then I should be able to remove the token, and it'd work the same.

Notice how these steps from our repo has "Required" on the right. And the screenshots above don't.

[michaelfaith]

Removed the token and adjusted the action from copilot's feedback

[michaelfaith]

I think we could actually get the best of both worlds. I looked a bit more into how yargs is doing it, since they do still have some required CI steps like Josh and my repos. But they're just using the default token that doesnt trigger CI. However they have a slightly different trigger on their CI workflow that will kick it off when a label is applied to the release PR. So when the maintainer is ready to move forward with the release and they want CI to run on the PR they apply a "ci" label, which triggers the workflow. I'm going to make those updates this afternoon in Josh's repos, so we can remove the PAT too. What do you think about that for this change?

[MichaelDeBoey]

@michaelfaith I don't think I fully understand what you're talking about tbh

Can you please explain a bit more in detail the workflow you're mentioning above?

[michaelfaith]

@michaelfaith I don't think I fully understand what you're talking about tbh

Can you please explain a bit more in detail the workflow you're mentioning above?

For sure, let me explain it all from the top, since I'm not sure that I've done a good job of explaining it little by little as I've figured it out.

So, the repos I work with Josh on and yargs both have specific CI steps that are required to be successful before a PR is mergeable. This is set up in the repo's ruleset settings as a condition on the main branch ruleset. You can see in the CI steps of PRs in our repos that some subset of the steps are marked as "Required"

Additionally, any actions (including creating PRs) that are performed by a bot using the default GITHUB_TOKEN token, rather than a PAT, will not trigger any downstream workflows. That's by design so that workflows can't get into some kind of infinite loop situation.

So, the combination of those two things creates a problem for PRs created by release-please if a PAT isn't being used. The CI workflow isn't triggered, but the repo settings still expect those required steps before the PR is mergeable. You can see that behavior in yargs' latest release PR: yargs/yargs#2475

The required steps are in this limbo pending state, because CI was never triggered.

yargs overcame this by including labeled in the triggers of their ci workflow, and so when a maintainer is ready to merge the PR, they'll add a ci label to the PR, which triggers the CI workflow, satisfies those required steps, and allows them to merge the PR. You can see that in this release PR for their 18.0 release: yargs/yargs#2325

The eslint-community repos don't have to deal with this issue, because they don't have any CI steps designated as Required.

So, the fact that CI doesn't trigger doesn't matter for them, because the repo doesn't need any of those steps to run for the PR to merge. This repo also doesn't appear to have any required steps, so what I have in the PR now will work the same way that the eslint-community repos do today.

However, if you do want to run CI before merging the release PR, which I'd recommend (mainly just to do a sanity check), then I could tweak the triggers in the same way so that you could just add a ci label to the release PR to trigger CI before merging. I'm about to do that to the repos I work on with Josh, since we do have Required steps, and I'd like to remove that PAT. Does that make sense?

[MichaelDeBoey]

@michaelfaith I think I understand it now.

Let's keep it without the ci label trigger (for now) so it's consistent with all other @eslint-community repos.

I would however like to hear @eslint-community/core-team @eslint-community/eslint-plugin-eslint-plugin, @eslint-community/eslint-plugin-node, @eslint-community/eslint-plugin-promise & @eslint-community/eslint-plugin-security if they would want to have this.
If there's enough consensus around this, I'm happy to have this implemented in all repos.

[michaelfaith]

@MichaelDeBoey I believe that should be everything. Let me know if there's anything else.

[MichaelDeBoey]

@michaelfaith This got me wondering: with semantic release, we can create alpha/beta releases by pushing commits to their respective branches

How would we create alpha/beta releases with release-please?

[michaelfaith]

How would we create alpha/beta releases with release-please?

I don't really have that set up here. But if you want to do that, there are a couple ways you can achieve it, depending on how complex you want to get. The easiest way to do it, would be to merge the alpha branch into main, and add two fields to the release-please config:

"prerelease": true,
"prerelease-type": "alpha", // or beta, or next, etc

That'll pick up where you left off with the alpha series.

If you want something more complex, where you're still running the alpha releases out of a dedicated branch, I set something like that up here, for testing: michaelfaith/package-json-validator#629, with a 1.x.x branch. I just have those two settings in the 1.x.x branch, but not in main. The complication with that approach is then keeping the 1.x.x / alpha branch in sync, which I don't have a great solution for yet. I started drafting a sort of auto-rebase workflow to see if that could help: michaelfaith/package-json-validator#639, but haven't gotten far enough along with that to feel good about recommending it.

So, I'd recommend just keeping it simple, and at whatever point you're ready to switch main over to prepping for the next major, update the settings, go through whatever prerelease cycles you want, and then remove them when you're ready to do the actual major. How much longer are you planning to keep the alpha changes in alpha? At least for this release, it may make sense to just go ahead and start getting the actual 5.0 release PR going?

[MichaelDeBoey]

@michaelfaith It's just the fact that right now people can already use this package while we're still working on v5 by using our alpha release

This way they could test things out and maybe even find bugs that we can still fix before cutting an actual v5 release
If we don't catch these in time, we'll have to release a minor release

In my experience, this isn't a problem most of the times, but sometimes a bug has major consequences in how things work, so you could have a situation where you need to cut another major release a few days later

But most important reasoning why I think we could benefit from being able to do alpha/beta releases is that you could still keep pushing to main while you're working on the next major in a separate branch

[michaelfaith]

But most important reasoning why I think we could benefit from being able to do alpha/beta releases is that you could still keep pushing to main while you're working on the next major in a separate branch

I understand the value. I don't think it's always necessary, but I understand it. But I'm just trying to get a sense of the urgency. v5 has been in alpha for over a year now; is it going to just continue to be in alpha for another year? I got the sense from previous conversations that you were wanting to get to a release state quickly, so you could have at least a little space before doing the next major when eslint v10 comes out later this month. So, if you're aiming to cut v5 in the next week or so, then I don't think getting alpha publishable is particularly urgent. You can just merge the changes into main, let release please create the 5.0 release branch, and then get the release out the door. In that world, then the work to get the prerelease channel wired up could be in a fast followup change. But if v5's going to remain in alpha indefinitely, and you're planning to do a lot more work, then it's more urgent to get it it in with this PR.