Repository navigation
fix(ci): Create Release tags main's tip at approval time, not the commit it was created for #1634
Description
Create Release run 38008819343 was created for b6b95bc8e ("Bumped version to 1.5.0b9", 2026-10-10). It waited on the github-release approval until 2026-10-13 ~01:38Z, and then tagged main's tip at that moment instead of b6b95bc8e. Both v1.5.0b9 and conda-1.5.0b9+0 point at 2c0008c3c, a commit made 3 days later. That commit's own Unit Tests run was still in progress.
Repro (job 115087308551, "Conda Tag (release)"):
- It checks out
b6b95bc8e, whereconda/buildis already 0, so the reset commits nothing ("nothing to commit"). - It fast-forwards
b6b95bc8e..2c0008c3cand tagsconda-1.5.0b9+0there. git show 2c0008c3c:conda/buildis3, so the tag labelled+0sits on a tree that says build 3. The next bump will write 4.- The build-0 packages were therefore built with the pins from builds 1–3.
Decision needed:
- Tag and build exactly the sha the run was created for, and do the
conda/buildreset as its own commit on top. - Keep releasing
main's tip at approval time, but resetconda/buildon that tip, so tag and tree agree.
Activity
JarryShaw commentedon Oct 13, 2026
Option 1
JarryShaw commentedon Oct 13, 2026
Taking option 1: Create Release tags and builds exactly the commit the run was created for. The
conda/buildreset goes on top as its own commit, so the tag, the tree and the built pins agree whenever approval lands. A worker is on it. The already-publishedv1.5.0b9andconda-1.5.0b9+0tags stay where they are; moving them is your call.JarryShaw commentedon Oct 13, 2026
And I think conda version bumps do not need manual approvals. They can happen automatically by themselves once their build version is bumped.
JarryShaw commentedon Oct 13, 2026
Agreed, and
cron-conda.ymlalready works that way: its build-bump tag and upload jobs name noenvironment:, so they need no approval. Only a version release through Create Release waits ongithub-release. Bumps have not been publishing because of the skipped-job cascade in #1632, whose fix is in review. No change is needed in #1634 for this.JarryShaw commentedon Oct 13, 2026
#1656 is up and reviewed. It needs your call on the
GITHUB_TOKENrelease-target question before merge: merge as is, add a PAT, or push the tag with the deploy key. The options are in its body.JarryShaw commentedon Oct 13, 2026
what needs my decision?
7 remaining items
JarryShaw commentedon Oct 13, 2026
done
JarryShaw commentedon Oct 13, 2026
Thanks. Checked through the API:
RELEASE_APP_PRIVATE_KEYis in thegithub-releaseenvironment, added 16:16Z.pypcapkit-release[bot], with id342101269.RELEASE_APP_BOT_IDis now set to that.One value I cannot read:
RELEASE_APP_CLIENT_ID. The App is private, andgh's OAuth token cannot see a private App's metadata (GET /apps/pypcapkit-releasereturns 404) or list its installations. Please paste the Client ID here. It is near the top of https://github.com/settings/apps/pypcapkit-release and starts withIv. It is not a secret, and I will set the variable.This token cannot check the installation either. The first approved Create Release run will: its token step fails loudly if the App is not installed on PyPCAPKit.
Nothing reads these variables until #1656 merges, so there is no hurry.
JarryShaw commentedon Oct 13, 2026
Thanks.
RELEASE_APP_CLIENT_IDis now set, alongsideRELEASE_APP_BOT_ID=342101269, and the private key is in thegithub-releaseenvironment, so the App side is complete.Nothing reads any of these until #1656 merges. That PR is being reworked to mint the token from them, and
mainis being merged in to clear its conflicts. Its first approved Create Release run is also the check that the App is installed on PyPCAPKit, which this token cannot see.ci(release): Create Release tags and builds the commit its run was cr…
ci(release): Create Release tags and builds the commit its run was cr…
JarryShaw commentedon Oct 13, 2026
Verified on the first App-token run, Create Release 38441545640 for 1.5.0b10:
v1.5.0b10was created bypypcapkit-release[bot]attarget_commitish85e4198c8. That is the run's own commit, notmain's tip1a307967c, and the tag points there too.Nothing to releasenotice.That settles the two points the #1656 review left unmeasured: the App-created tag does fire
push, andgithub.actor_idis the bot.ci(release): key a run with nothing to release on its own run id (#1705…
ci(release): a push that releases nothing stays green when its versio…
test(project): keep the #1634 scratch repositories' clones off auto-m…