chadtmiller.com/knotless
git that lives in your Atmosphere account
1
10
A workflow keeps a release pull open as change files land
Merged Approved
This adds release-pull.yml, which cuts the Release <version> pull daily from main's change files, force-pushes it to release/next, and opens or updates the pull. It queues nothing. The docs, AGENTS.md and release.yml's header are updated with it.
I read the workflow against the CLI docs and release.yml, and found nothing that must change:
- The version rule gives the right result. A
minorormajorbumps 0.x's minor, and from 1.0 each bumps its own part. - The
pull listoutput is tab-separated with the URI third and the title fourth, as the workflow's awk expects. pull retarget --headto the branch a pull already names is tested to succeed, so the update path is safe on every rebuild.- The step-level
on: {refs: [refs/heads/main]}follows release.yml.
Two things to watch on the first scheduled run, since the pull step has not run yet:
- A rebuild force-pushes
release/nextwhenever the set of change files differs. If the pull is already queued, the push restarts its checks. That fits the design, but expect it. set -- .changeset/*.mdcounts any.mdfile in.changeset/. If a README.md or similar ever lands there, it would count as a change file.
All checks have passed
8 passed, 3 skipped
Merged as 2de4f08
Adds release-pull.yml: each day at 06:00 UTC, when main has change files, it cuts the
Release <version>pull itself and keeps it up to date, so releasing is queueing that pull. It queues nothing on its own. Worth a look at the version rule and at how it finds the open pull.Claude Opus 5.5 · low
What changes
release-pull.yml. Runs on a schedule (
0 6 * * *) and when asked for by name, on ci.knotless.dev with release.yml'sRELEASE_PASSWORD. With change files on main, it downloads knope 0.23.2 (pinned by SHA-256) and the latest client from/install.sh, works out the version, runsknope release --override-version, commitsRelease <version>asknotless, force-pushes it torelease/next, and opens the pull, or edits the open one's title and body. The body is the template's, with the version's changelog section in it.The version. A
minorormajorchange file bumps 0.x's minor, apatchthe patch; from 1.0 on each bumps its own part. This is the rule 0.12.0 and 0.13.0 were cut by with--override-version, since knope alone bumps a 0.x minor change as a patch.Finding the open pull. By title: an open pull by the owner titled
Release x.y.z. One cut by hand is taken over, its head pointed atrelease/nextwithpull retarget --head.When it pushes. Only when the open pull's release commit was cut from a different set of change files than main's (compared as
.changesettrees), or no longer merges with main (git merge-tree). Otherwise the pull's checks would run again every day for nothing.Asked for on any other branch it makes the release commit and prints the body, pushing nothing.
Docs: docs/design/packages.md (How knotless versions itself), release.yml's header and AGENTS.md's Versioning.
Why
Releases were cut by hand nearly every day (0.2.0 to 0.13.0 in twelve days), each a
knope release --override-versionand a body written from the template. release-please, changesets' bot and webpack's release flow all keep one standing release pull and leave merging it to a person, which fits how this repository already lands everything through the queue.How it was checked
The
changesandrelease commitsteps run locally in a clone at main before 0.13.0 produced the same CHANGELOG.md, Cargo.toml, Cargo.lock and.changesetchanges as the hand-cut 0.13.0, and the version 0.13.0. The skip test says skip for that commit against the main it was cut from, and rebuild against an older main. The title filter picks the thirteenRelease x.y.zpulls out ofpull list's 117 matches. A run asked for at a trial branch with one change file exercised the steps in the container on ci.knotless.dev. Thepullstep itself runs only at main, so its push,pull createandpull editare first exercised by the first scheduled run.Shortcomings
The open pull is found by title through the appview, so a pull just opened and not yet indexed would be opened again; at one run a day that doesn't come up. If someone retitles the pull, it stops being found and a new one is opened.