Skip to content

ci(release): push the version bump with a deploy key, and restrict who can release - #75

Merged
VonAlphaBisZulu merged 1 commit into
mainfrom
release-deploy-key
Jul 25, 2026
Merged

ci(release): push the version bump with a deploy key, and restrict who can release#75
VonAlphaBisZulu merged 1 commit into
mainfrom
release-deploy-key

Conversation

@VonAlphaBisZulu

Copy link
Copy Markdown
Contributor

Fixes the failed 1.19 dispatch (run 30177587416).

What happened

push code to main was rejected with GH013: the ruleset Main edits only by PR requires changes to arrive via pull request, and the workflow pushes the version bump directly.

Nothing was lost. Because the release steps were reordered in #74, the failure landed before anything irreversible: PyPI never saw 1.19 (the version is still free) and no tag or release was created. Under the old ordering this would have left a v1.19 tag advertising a version that does not exist on PyPI.

The fix

The ruleset already lists DeployKey as a bypass actor, so it needs no change:

actor_type=DeployKey       mode=always
actor_type=RepositoryRole  mode=always   (admin)

Checking out over SSH with a write deploy key is therefore sufficient. actions/checkout supports this directly, so the existing git push step is unchanged.

Why a deploy key rather than github-actions[bot]

Ruleset bypasses are per actor, not per workflow. Adding github-actions[bot] would let every workflow in the repo with contents: write push to main unreviewed. The deploy key's private half is an environment secret of build_and_publish, and only jobs declaring that environment can read it — so the bypass is confined to this one workflow.

Approach Scope of the exception
github-actions[bot] bypass every workflow, indefinitely
Deploy key in the environment only jobs declaring build_and_publish

Honest caveat: this is a long-lived credential, and a write deploy key may push to any branch in this repo. What is scoped is who can read it, not what it can do.

Restricting dispatch

Any collaborator with write access can start a workflow_dispatch, and this one publishes to PyPI where a version number cannot be reused once taken. The run now fails unless dispatched by VonAlphaBisZulu. It fails rather than skips — a dispatch that quietly does nothing looks too much like one that worked.

Required before the next dispatch

  1. A write deploy key registered on the repository.
  2. Its private half stored as RELEASE_DEPLOY_KEY in the build_and_publish environment.

🤖 Generated with Claude Code

…o can release

The 1.19 dispatch failed at "push code to main" with GH013: the ruleset "Main
edits only by PR" requires changes to arrive by pull request, and the workflow
pushes the version bump directly. Nothing was lost -- the reordering means the
build and the upload had not run, so PyPI never saw 1.19 and no tag or release
was created.

The ruleset already lists DeployKey as a bypass actor, so checking out over SSH
with a write deploy key is enough; the ruleset itself needs no change. The key
lives as an environment secret of build_and_publish, and only jobs declaring that
environment can read it, so the bypass is confined to this workflow. Adding
github-actions[bot] to the bypass list would have been simpler and much broader:
every workflow in the repository with contents: write could then push to main
unreviewed.

Note this is a long-lived credential and a write deploy key may push to any
branch here. What is scoped is who can read it, not what it can do.

Dispatch is also restricted to the maintainer. Any collaborator with write access
can start a workflow_dispatch, and this one publishes to PyPI, where a version
number cannot be reused once taken. The check fails rather than skipping the job:
a dispatch that quietly does nothing looks too much like one that worked.

Requires, before the next dispatch:
  - a write deploy key registered on the repository
  - its private half stored as RELEASE_DEPLOY_KEY in the build_and_publish
    environment

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@VonAlphaBisZulu
VonAlphaBisZulu merged commit c155519 into main Jul 25, 2026
20 checks passed
@VonAlphaBisZulu
VonAlphaBisZulu deleted the release-deploy-key branch July 25, 2026 23: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