Skip to content

ci: use PAT for release-please so release PRs trigger CI#287

Merged
fan-zhang-sv merged 1 commit intomasterfrom
ci/release-please-pat
Apr 27, 2026
Merged

ci: use PAT for release-please so release PRs trigger CI#287
fan-zhang-sv merged 1 commit intomasterfrom
ci/release-please-pat

Conversation

@fan-zhang-sv
Copy link
Copy Markdown
Collaborator

Summary

Release PRs opened by release-please-action are authored by the default GITHUB_TOKEN, and per GitHub's docs events triggered by GITHUB_TOKEN do not start new workflow runs:

When you use the repository's GITHUB_TOKEN to perform tasks, events triggered by the GITHUB_TOKEN, with the exception of workflow_dispatch and repository_dispatch, will not create a new workflow run.

That's why the current open release PR (#286) shows only Heimdall + StepSecurity checks — none of Lint Check, Format Check, Type Check, Tests, or PR Title ever ran.

This PR switches release-please-action to read its token from a RELEASE_PLEASE_TOKEN secret instead. With a PAT (or GitHub App installation token) backing it, the resulting pull_request events fire normally and CI runs on every release PR.

Required setup before merging

  1. Create a token with contents: read/write, pull-requests: read/write, and issues: read/write on base/account-sdk. Either:
    • Classic PAT with the repo scope, or
    • Fine-grained PAT scoped to this repo, or
    • GitHub App installation token via actions/create-github-app-token.
  2. If base enforces SAML SSO, authorize the token for the base org.
  3. Add it as a repo secret named RELEASE_PLEASE_TOKEN at https://github.com/base/account-sdk/settings/secrets/actions.

Post-merge

The next push to master will (re)open the release PR under the new token's identity, and CI will run on it. The currently-open #286 was created under the old GITHUB_TOKEN identity; closing and reopening it (or letting release-please recreate it after this lands) will make CI run there too.

Test plan

  • RELEASE_PLEASE_TOKEN secret is configured on the repo
  • After merging, confirm the next release PR (or a re-opened chore(master): release account 2.5.5 #286) shows Lint Check, Format Check, Type Check, Tests (Node 20/22/24), and PR Title checks
  • Confirm the release PR is authored by the token's owner (not github-actions[bot])

Made with Cursor

Release PRs opened by `release-please-action` were authored by the
default `GITHUB_TOKEN`, and per GitHub's docs events triggered by
`GITHUB_TOKEN` do not start new workflow runs. As a result the lint,
format, typecheck, and test workflows never ran on the release PR.

Switch the action to a `RELEASE_PLEASE_TOKEN` secret (a classic or
fine-grained PAT, or a GitHub App installation token) so that PR
events fire normally and CI runs on each release PR.

Setup notes (one-time):
- Create a token with contents, pull-requests, and issues read/write
  on this repo.
- Save it as the `RELEASE_PLEASE_TOKEN` repo secret.
- The next push to master will reopen the release PR under the new
  identity and CI will run on it.

Made-with: Cursor
@cb-heimdall
Copy link
Copy Markdown
Collaborator

cb-heimdall commented Apr 27, 2026

✅ Heimdall Review Status

Requirement Status More Info
Reviews 2/1
Denominator calculation
Show calculation
1 if user is bot 0
1 if user is external 0
2 if repo is sensitive 0
From .codeflow.yml 1
Additional review requirements
Show calculation
Max 0
0
From CODEOWNERS 0
Global minimum 0
Max 1
1
1 if commit is unverified 0
Sum 1

@fan-zhang-sv fan-zhang-sv merged commit 734b9e0 into master Apr 27, 2026
12 checks passed
@fan-zhang-sv fan-zhang-sv deleted the ci/release-please-pat branch April 27, 2026 20:44
@github-actions
Copy link
Copy Markdown
Contributor

Review Summary

PR title: Valid conventional commit format (ci: ...). No changes needed.

Change: Replaces GITHUB_TOKEN with a configurable RELEASE_PLEASE_TOKEN secret in the release-please workflow so that release PRs trigger CI checks.

Findings: None.

  • The change is minimal and scoped to a single workflow file.
  • The on: push: branches: [master] trigger means this workflow only runs on trusted pushes, not on fork PRs — no risk of secret exfiltration.
  • The RELEASE_PLEASE_TOKEN secret is only referenced in the release-please job; publish jobs use their own permissions-scoped GITHUB_TOKEN and don't have access to the PAT.
  • Note that the top-level permissions block (lines 8-10) constrains the GITHUB_TOKEN, not the PAT. The PAT's effective permissions are determined at token creation time. This is standard and expected for this pattern.
  • The PR description clearly documents the required setup steps and post-merge verification, which is good since the secret must exist before the workflow can succeed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants