Skip to content

ci: let release-please use a real token so release PRs stop stalling - #112

Closed
KRoperUK wants to merge 2 commits into
mainfrom
ci/release-please-token
Closed

KRoperUK wants to merge 2 commits into
mainfrom
ci/release-please-token

Conversation

@KRoperUK

Copy link
Copy Markdown
Owner

Summary

Release-please runs as github-actions[bot], and bot-authored commits put their workflow runs into action_required with zero jobs created. ci is a required status check, so the release PR sat BLOCKED with an empty statusCheckRollup until someone approved the runs by hand — which is what happened to #100, and to the integration's release PR four times over (KRoperUK/dimplex-controller-hass#200).

The workflow now uses secrets.RELEASE_PLEASE_TOKEN when it is defined and falls back to the default token otherwise, so this is safe to merge before the secret exists and nothing changes for anyone who does not add one. CONTRIBUTING.md says what to create and why.

Refs KRoperUK/dimplex-controller-hass#200.

Type of change

  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Breaking change
  • Documentation / chore

Checklist

  • ruff check . passes
  • ruff format --check . passes
  • mypy passes — the config is strict (no library code changed; run anyway)
  • pytest passes (196 tests, no library code changed)
  • I have updated the README / docstrings / docs/ where relevant

Behaviour changes worth calling out

None to the library. The workflow keeps working exactly as it does today until RELEASE_PLEASE_TOKEN is added, at which point release PRs stop needing manual run approval. actionlint is clean, and pre-commit run --all-files passes.

KRoperUK and others added 2 commits September 18, 2026 14:02
Release-please ran as `github-actions[bot]`, and bot-authored commits put their
workflow runs into `action_required` with zero jobs created. `ci` is a required
status check, so the release PR sat BLOCKED with an empty `statusCheckRollup`
until someone approved the runs by hand — which is what happened to #100, and to
the integration's release PR four times over
(KRoperUK/dimplex-controller-hass#200).

The workflow now uses `secrets.RELEASE_PLEASE_TOKEN` when it is defined and falls
back to the default token otherwise, so this is safe to merge before the secret
exists and nothing changes for anyone who does not add one. CONTRIBUTING says what
to create and why.

Co-authored-by: CommandCodeBot <noreply@commandcode.ai>
@KRoperUK

Copy link
Copy Markdown
Owner Author

Closing this: the token approach is not wanted — release-please runs are triggered and approved deliberately when a release is wanted, so there is no need for a PAT here.

@KRoperUK KRoperUK closed this Sep 18, 2026
@KRoperUK
KRoperUK deleted the ci/release-please-token branch September 18, 2026 15:48
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