Conversation
…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.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Reverts #183. Restores the release-please workflow to the default
GITHUB_TOKENflow so version tags / GitHub Releases get created again.Why
PR #183 changed
release-please.ymlto 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:The most visible symptom: the release PR #181 (
chore(main): release 1.3.0) merged successfully — main was bumped to1.3.0in.release-please-manifest.jsonandCHANGELOG.md— but the post-merge release-please run failed, so nov1.3.0git tag and no GitHub Release were ever created.After this PR merges
Releases will be created by release-please using the default
GITHUB_TOKENagain, which restores the v0.x → v1.2.0 working state.There are two leftover items to handle separately:
v1.3.0manually at5bcc094(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.CI_APP_ID/CI_APP_PRIVATE_KEYfirst, then re-apply the App-token approach in a follow-up PR.Test plan
release-please.ymlmatches the pre-ci(release-please): use GitHub App token to trigger required checks #183 content (default token, no App token step)