ci: ensure the auto-created release-please action runs CI

[lumirlumir]

Prerequisites checklist

• I have read the contributing guidelines.

What is the purpose of this pull request?

This PR follows up on eslint/css#330.

In this PR, I've ensured the auto-created release-please action triggers CI.

Problem

Currently, the auto-created PR from the release-please action does not trigger CI, as shown below:

For example: eslint/rewrite#336

This can result in CI not running and may lead to issues like eslint/rewrite#308 if the check is missing.

Solution

I've used secrets.WORKFLOW_PUSH_BOT_TOKEN instead of the default secrets.GITHUB_TOKEN, following the same approach described in eslint/css#330.

Also, the permissions for contents and pull-requests is no longer necessary because secrets.WORKFLOW_PUSH_BOT_TOKEN already grants the required permissions, so I removed it.

FYI: the token input reference: https://github.com/googleapis/release-please-action?tab=readme-ov-file#action-inputs

Test

I've tested it in my forked repository (using rewrite repository), and it works as expected:

lumirlumir/fork-rewrite#9

• Before: CI wasn't running

• After: CI is running

What changes did you make? (Give an overview)

This PR follows up on eslint/css#330.

In this PR, I've ensured the auto-created release-please action triggers CI.

Related Issues

Ref: eslint/css#330

Is there anything you'd like reviewers to focus on?

N/A

[Copilot]

Pull request overview

This PR updates the release-please workflow to ensure that automatically created release PRs trigger CI checks. By switching from the default GITHUB_TOKEN to WORKFLOW_PUSH_BOT_TOKEN, PRs created by the release-please action will now properly trigger CI workflows, preventing releases from being created without proper validation.

Key Changes:

• Replaced GITHUB_TOKEN with WORKFLOW_PUSH_BOT_TOKEN for the release-please action
• Removed explicit contents: write and pull-requests: write permissions (redundant with bot token)
• Maintained id-token: write permission for npm provenance support

---

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

[mdjermanovic]

I'm not sure about this, but per https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#permissions, "If you specify the access for any of these permissions, all of those that are not specified are set to none", which means contents will be none for steps that use GITHUB_TOKEN? Docs for trusted publishing (https://docs.npmjs.com/trusted-publishers#step-2-configure-your-cicd-workflow) have contents: read in the example, so perhaps it would be safer to change write -> read instead of just removing the line?

[lumirlumir]

I think it would still work well if we remove contents: write or contents: read for the following reasons:

---

You can use permissions to modify the default permissions granted to the GITHUB_TOKEN

According to https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#permissions, the permissions field applies to GITHUB_TOKEN, not to Personal Access Tokens (fine-grained or classic) such as WORKFLOW_PUSH_BOT_TOKEN. (This change now removes the use of GITHUB_TOKEN.)

As far as I know, the permissions for WORKFLOW_PUSH_BOT_TOKEN are set when the token is created, not by the explicit permissions field in GitHub Actions. For example, with the following token settings (the example below shows a classic token):

---

Docs for trusted publishing (https://docs.npmjs.com/trusted-publishers#step-2-configure-your-cicd-workflow) have contents: read in the example, so perhaps it would be safer to change write -> read instead of just removing the line?

As far as I know, content: write or contents: read aren't related to OIDC; only id-token is:

For example, when I publish my personal open-source packages, I only use id-token: write, and it works fine without contents: read.

Ref: https://github.com/lumirlumir/npm-clang-format-node/blob/5eeae2da116c405395eaf13391500c18e416f421/.github/workflows/publish.yml#L7-L8

---

Also, in https://github.com/eslint/css/pull/330/changes, we removed the contents: write field as shown below, yet the auto-created workflow was generated correctly and the CI ran successfully.

---

Given the reasons above, I think this would work well; however, if you’re still unsure, I’m happy to follow your guidance and update the workflow to use contents: read.

[mdjermanovic]

According to https://docs.github.com/en/actions/reference/workflows-and-actions/workflow-syntax#permissions, the permissions field applies to GITHUB_TOKEN, not to Personal Access Tokens (fine-grained or classic) such as WORKFLOW_PUSH_BOT_TOKEN. (This change now removes the use of GITHUB_TOKEN.)

Yes, but only one step uses WORKFLOW_PUSH_BOT_TOKEN, while the others still use GITHUB_TOKEN?

Also, in https://github.com/eslint/css/pull/330/changes, we removed the contents: write field as shown below, yet the auto-created workflow was generated correctly and the CI ran successfully.

In that change, we entirely removed permissions, in which case I believe contents defaults to read. Also, the steps are different than here and maybe those steps don't require contents: read.

For example, when I publish my personal open-source packages, I only use id-token: write, and it works fine without contents: read.

Ref: https://github.com/lumirlumir/npm-clang-format-node/blob/5eeae2da116c405395eaf13391500c18e416f421/.github/workflows/publish.yml#L7-L8

Then maybe it isn't true that trusted publishing requires contents: read or that specifying any permissions automatically sets the others to none. However, I think it's safer to go by the docs and specify contents: read.

[lumirlumir]

However, I think it's safer to go by the docs and specify contents: read.

First of all, I followed your suggestion and updated it in 9dc5ae9.

Just a small note: contents: read would matters for private repositories (since the read permission is also restricted in private repositories) and can affect some resuable GitHub Actions workflows or OIDC. However, since the repositories where we publish packages are public, the behavior would be the same whether it’s specified as contents: read or not. That said, being explicit could also be a good option :)

[nzakas]

LGTM. Thanks.