Skip to content

revert: ci(release-please): use GitHub App token to trigger required checks (#183)#184

Merged
wadakatu merged 1 commit intomainfrom
revert/release-please-app-token
May 8, 2026
Merged

revert: ci(release-please): use GitHub App token to trigger required checks (#183)#184
wadakatu merged 1 commit intomainfrom
revert/release-please-app-token

Conversation

@wadakatu
Copy link
Copy Markdown
Collaborator

@wadakatu wadakatu commented May 8, 2026

Summary

Reverts #183. Restores the release-please workflow to the default GITHUB_TOKEN flow so version tags / GitHub Releases get created again.

Why

PR #183 changed release-please.yml to authenticate via a GitHub App token (secrets.CI_APP_ID / secrets.CI_APP_PRIVATE_KEY). Those secrets are not configured in this repository, so every release-please workflow run since #183 merged has failed at the "Generate GitHub App token" step:

Error: The 'client-id' (or deprecated 'app-id') input must be set to a non-empty string.

The most visible symptom: the release PR #181 (chore(main): release 1.3.0) merged successfully — main was bumped to 1.3.0 in .release-please-manifest.json and CHANGELOG.md — but the post-merge release-please run failed, so no v1.3.0 git tag and no GitHub Release were ever created.

After this PR merges

Releases will be created by release-please using the default GITHUB_TOKEN again, which restores the v0.x → v1.2.0 working state.

There are two leftover items to handle separately:

  1. v1.3.0 tag/release: main is already at 1.3.0 but the tag is missing. We may need to either (a) create v1.3.0 manually at 5bcc094 (the release-please merge commit), or (b) let release-please open a fresh release PR. I'll handle this as a follow-up depending on what release-please does after this PR lands.
  2. The original problem ci(release-please): use GitHub App token to trigger required checks #183 was solving (status checks not retriggered when release-please merges its own PR) is back. To re-address it, we need to provision CI_APP_ID / CI_APP_PRIVATE_KEY first, then re-apply the App-token approach in a follow-up PR.

Test plan

…checks (#183)

This reverts commit 33e6c6d.

The App token approach requires `CI_APP_ID` / `CI_APP_PRIVATE_KEY` secrets
which are not configured in this repository. As a result, the release-please
workflow failed at the "Generate GitHub App token" step on every push to main
after #183 merged, including the merge of release PR #181 — so the v1.3.0 git
tag and GitHub Release were never created despite main already being on 1.3.0
in `.release-please-manifest.json` and CHANGELOG.md.

Reverting to the default `GITHUB_TOKEN` flow restores release tag/release
creation. The original problem #183 was solving (status checks not being
re-triggered when release-please merges its own PR) can be re-addressed in
a follow-up once the App secrets are provisioned.
@wadakatu wadakatu merged commit 0bf8fe5 into main May 8, 2026
12 of 13 checks passed
@wadakatu wadakatu deleted the revert/release-please-app-token branch May 8, 2026 14:08
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.

1 participant