Repository navigation
fix(ci): Create Release replaces a published release's conda assets on every main push #1640
Description
Every Create Release run since 1.5.0b9 was published has rebuilt the linux-64 conda tarballs and replaced them on the published GitHub Release v1.5.0b9. The latest replacement was at 02:39-02:40Z on 2026-10-13, by run 38335468075. The same thing happened in runs 38333737458 and 38335274073.
Why it reruns. Check Version finds 8 of the 10 conda platform/Python pairs on anaconda.org; the missing two are the py310 legs that #1633 fails. So PCAPKIT_CONDA_COMPLETE stays false, and conda (create-release.yml:675-680) runs all ten legs again on every main push that gets through Vendor Update. The Anaconda upload is skipped per leg (check_leg, :878), but Upload package to GitHub Release (:886-893) is gated only on matrix.os == 'ubuntu-latest'. softprops/action-gh-release logs overwrite_files: true, then deletes and re-uploads each asset.
Effect. Each rebuild runs pip download -r conda/requirements.txt against live PyPI (:795), so the result is not byte-identical. The four GitHub assets now differ from the anaconda.org files of the same name (py311: 12,323,830 vs 12,357,661 bytes; py313: 12,046,095 vs 11,997,102 bytes). Nothing on anaconda.org was overwritten: every 1.5.0b9 file there has upload_time 01:43-01:47Z.
Fix. Gate the GitHub upload on the same steps.check_leg.outputs.PCAPKIT_LEG_EXISTS != 'true' as the Anaconda upload, or upload without overwrite. A test should fail on the current file. Under #1633's KTLO split, the completeness count must also stop waiting on legs that may fail, or these runs never converge.
Whether to restore the four assets from the anaconda.org copies is your call.
Blocked until the #1634 PR merges, because both edit create-release.yml's conda job.
Activity
JarryShaw commentedon Oct 13, 2026
Unblocked: the #1634 fix now moves this job's GitHub Release uploads off the update-a-release path, and that touches exactly these lines. So the fix lands in the same PR, gating the upload on
check_legthe way the Anaconda upload is gated.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
Fixed on
mainby #1656 (edada31dd).pypiandcondanow attach files withgh release uploadand leave any asset already in stateuploadedalone, and conda's GitHub upload is gated oncheck_leg, as the Anaconda upload is (create-release.yml:1236-1280). The convergence half landed with #1645: there is no conda 3.10 leg any more, and PyPI completeness counts only the supported files.Restoring the four replaced
v1.5.0b9assets from the anaconda.org copies is still your call. It is tracked on #1657, together with the lost release notes.