Skip to content

ci: prepare releases with Release Please - #287

Draft
qw-in wants to merge 11 commits into
mainfrom
quinn/release-please
Draft

qw-in wants to merge 11 commits into
mainfrom
quinn/release-please

Conversation

@qw-in

@qw-in qw-in commented Oct 29, 2026

Copy link
Copy Markdown
Member

Switch to release please to manage releases to bring this in line with arcjet-js.

Will require a GitHub app to be configured before merging

qw-in and others added 7 commits October 29, 2026 08:25
Replace the hand-edited release PR with Release Please. On each push to
main it keeps a `chore: Release <version>` PR open that bumps all six
lockstep locations: both pyproject versions, the reciprocal `==` pins
(via `x-release-please-version` markers), and the two editable entries in
uv.lock (via TOML jsonpath, so no `uv lock` run with a write token).
`simple` is used rather than `python` because the python strategy also
rewrites every `version.py` found anywhere in the repository.

Merging the release PR creates the `vX.Y.Z` tag and GitHub release with a
GitHub App token, so the existing tag-triggered release.yml starts on its
own and still waits for the `pypi` environment's reviewers. release.yml
is unchanged, which keeps the PyPI trusted publisher identity intact.

The App credentials are read from a `release-please` environment limited
to main, the token is scoped to contents and pull-requests write, and the
job runs with no GITHUB_TOKEN permissions and a harden-runner egress
block list of api.github.com only.

A Release Please updater that stops matching only logs a warning, so CI's
lint job now runs tools/check_release_lockstep.py to fail a release PR
whose versions, pins and lock entries disagree. The manifest starts at
1.4.0, the latest published release.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
1.5.0 was released by hand (#285, tag v1.5.0) after the Release Please
draft was written, so a manifest at 1.4.0 would propose 1.5.0 again and
try to release onto the existing tag. Start the manifest at 1.5.0.

A release.yml run started by the Release Please App's tag has the App as
its triggering actor, so the pypi environment's prevent-self-review no
longer excludes the person who merged the release. Say so in the release
steps.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Release Please now runs with the default token instead of a GitHub App, so
the tag it creates on merge does not start the release workflow. Drop the
lockstep script: release preflight checks versions and pins, and
`uv lock --check` catches a stale lockfile. Remove config keys that only
restated defaults.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A person dispatches the workflow, so the pypi environment's prevent
self-review stops them approving their own publish. Preflight fails a
dispatch on a branch before approval is requested.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
…merges

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The simple type writes a version.txt; the python type updates
pyproject.toml itself, so its explicit toml updater is dropped.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
@qw-in qw-in self-assigned this Oct 29, 2026
qw-in and others added 4 commits October 29, 2026 08:51
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
gh release view can report a draft as not found when its draft lookup
fails, which skipped publishing after PyPI succeeded. The list endpoint
includes drafts, and a failed request fails the step.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

This branch has not been deployed

No deployments
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