protect-main requires signed commits (required_signatures), and the build(packaging): … pull request the packages job opens is committed by peter-evans/create-pull-request without a signature. #82 added the DCO sign-off, but the v1.0.1 packaging PR still could not merge on its own: GitHub's "update branch" re-created the commit unsigned (#83), and the merged #84 was cherry-picked and signed by hand.
sign-commits: true on the action only signs when the token is a bot token; with a PAT (DEPS_PAT) it explicitly does not sign (action docs, "Commit signature verification for bots"). The fix, matching the KofTwentyTwo standards repository's own release automation: mint a short-lived GitHub App token in the job (actions/create-github-app-token, RELEASE_APP_CLIENT_ID variable + RELEASE_APP_PRIVATE_KEY environment secret) and open the PR with it and sign-commits: true. The commit is then signed by GitHub, authored by the App's [bot] user (exempt from the DCO check), and the PR still triggers the required checks. DEPS_PAT is no longer needed by the release workflow.
Owner steps (one time): create a GitHub App installed only on this repository with Contents and Pull requests write and no ruleset bypass; store its client id as the Actions variable RELEASE_APP_CLIENT_ID and its private key as RELEASE_APP_PRIVATE_KEY in the release environment.
`protect-main` requires signed commits (`required_signatures`), and the `build(packaging): …` pull request the `packages` job opens is committed by `peter-evans/create-pull-request` without a signature. #82 added the DCO sign-off, but the v1.0.1 packaging PR still could not merge on its own: GitHub's "update branch" re-created the commit unsigned (#83), and the merged #84 was cherry-picked and signed by hand.
`sign-commits: true` on the action only signs when the token is a bot token; with a PAT (`DEPS_PAT`) it explicitly does not sign (action docs, "Commit signature verification for bots"). The fix, matching the KofTwentyTwo standards repository's own release automation: mint a short-lived GitHub App token in the job (`actions/create-github-app-token`, `RELEASE_APP_CLIENT_ID` variable + `RELEASE_APP_PRIVATE_KEY` environment secret) and open the PR with it and `sign-commits: true`. The commit is then signed by GitHub, authored by the App's `[bot]` user (exempt from the DCO check), and the PR still triggers the required checks. `DEPS_PAT` is no longer needed by the release workflow.
Owner steps (one time): create a GitHub App installed only on this repository with Contents and Pull requests **write** and no ruleset bypass; store its client id as the Actions variable `RELEASE_APP_CLIENT_ID` and its private key as `RELEASE_APP_PRIVATE_KEY` in the `release` environment.
Part of #62. Follows #81.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
protect-mainrequires signed commits (required_signatures), and thebuild(packaging): …pull request thepackagesjob opens is committed bypeter-evans/create-pull-requestwithout a signature. #82 added the DCO sign-off, but the v1.0.1 packaging PR still could not merge on its own: GitHub's "update branch" re-created the commit unsigned (#83), and the merged #84 was cherry-picked and signed by hand.sign-commits: trueon the action only signs when the token is a bot token; with a PAT (DEPS_PAT) it explicitly does not sign (action docs, "Commit signature verification for bots"). The fix, matching the KofTwentyTwo standards repository's own release automation: mint a short-lived GitHub App token in the job (actions/create-github-app-token,RELEASE_APP_CLIENT_IDvariable +RELEASE_APP_PRIVATE_KEYenvironment secret) and open the PR with it andsign-commits: true. The commit is then signed by GitHub, authored by the App's[bot]user (exempt from the DCO check), and the PR still triggers the required checks.DEPS_PATis no longer needed by the release workflow.Owner steps (one time): create a GitHub App installed only on this repository with Contents and Pull requests write and no ruleset bypass; store its client id as the Actions variable
RELEASE_APP_CLIENT_IDand its private key asRELEASE_APP_PRIVATE_KEYin thereleaseenvironment.Part of #62. Follows #81.