fix(ci): reliable CLI→PyPI publishing — stable-only gate + stop desktop deleting CLI assets#6433
Merged
Conversation
The `librefang` PyPI project has a 10 GB total-size quota. Each release uploads ~8 per-platform CLI binary wheels (~250 MB), and because every beta/rc tag published too, 46 accumulated pre-releases consumed 10.35 GB and pushed the project over quota — the v2026.7.10 stable `CLI / PyPI` job then failed with `400 Project size too large`. Gate the `cli_pypi` job (in both release.yml and the manual release-cli.yml re-run path) to stable and LTS tags only. A tag is treated as a pre-release when it carries any `-suffix` (e.g. `-beta.10`, `-rc.1`); `-lts` is the sole non-pre-release suffix, matching create_release's existing `-lts` special-casing. Pre-release CLI binaries are still attached to the GitHub Release, and `librefang-sdk` (a separate PyPI project) is unaffected.
github-actions
Bot
added
no-rust-required
Rewrap the new cli_pypi guard comments in release.yml and release-cli.yml to one sentence per line, per CLAUDE.md's prose-wrapping rule (new prose must break only at sentence boundaries, not at a fixed column width) — the same fix #6418 applied to a similar release-workflow comment. Add the missing [Unreleased] CHANGELOG entry for this fix, matching the established convention of every other CI-only fix PR in this repo (#6410, #6389, #6416, #6418) recording a changelog line.
added 2 commits
July 10, 2026 22:05
The desktop job's "Delete existing assets for this target" step matched `*<rust_target>*`, and the cli_* jobs name their uploads `librefang-<rust_target>.tar.gz|.zip` (+ `.sha256`) with the SAME target triple. So when a desktop job re-ran after its CLI counterpart had already uploaded, it deleted the CLI binary tarball as collateral. This is why the v2026.7.10 macOS CLI tarballs (`librefang-x86_64-apple-darwin.tar.gz`, `librefang-aarch64-apple-darwin.tar.gz`) disappeared after the desktop macOS jobs re-ran for notarization, which then made the `CLI / PyPI` job fail with a 404 when it tried to download them to build the wheels. Skip CLI-owned assets (`librefang-*`, `SHA256SUMS*`) before the target-glob delete. Desktop bundles use Tauri's own naming (`LibreFang_<ver>_<x64|aarch64|amd64|arm64>…`) which never contains the triple, so the guard costs the desktop nothing while protecting the CLI artifacts on every platform.
houko
changed the title
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Two related fixes to the CLI → PyPI release path, both surfaced by the
v2026.7.10release whoseCLI / PyPIjob failed.1. Gate
cli_pypito stable/LTS tags onlyThe
v2026.7.10CLI / PyPIjob first failed with:The
librefangPyPI project has a 10 GB total-size quota. Each release uploads ~8 per-platform CLI binary wheels (~250 MB) viacargo xtask publish-pypi-binaries. Becausecli_pypiran on everyv*tag — including beta/rc pre-releases — 46 accumulated pre-releases consumed 10.35 GB and pushed the project over quota (measured: 48 versions / 10.73 GB, of which 46 pre-releases were 10.35 GB).Gate
cli_pypito stable and LTS tags only, in bothrelease.yml(tag-push pipeline) andrelease-cli.yml(manual re-run path).--ltsv2026.7.10(stable)v2026.6.26-beta.24v2026.5.8-rc.1v2026.3.0-ltsPre-release CLI binaries stay on the GitHub Release;
librefang-sdk(separate PyPI project) is untouched.2. Stop desktop re-release from deleting CLI binary assets
After the PyPI quota was freed,
CLI / PyPIkept failing — now with a 404 downloadinglibrefang-x86_64-apple-darwin.tar.gz. Root cause: the desktop job's "Delete existing assets for this target" step matched*<rust_target>*, and thecli_*jobs name their uploadslibrefang-<rust_target>.tar.gz(+.sha256) with the same target triple. So when a desktop job re-ran after its CLI counterpart had already uploaded — exactly what the macOS desktop jobs do when they re-run for notarization — it deleted the CLI mac tarballs as collateral, andcli_pypithen 404'd downloading them to build the wheels.Skip CLI-owned assets (
librefang-*,SHA256SUMS*) before the target-glob delete. Desktop bundles use Tauri's ownLibreFang_<ver>_<x64|aarch64|amd64|arm64>…naming, which never contains the triple, so the guard costs the desktop nothing and protects the CLI artifacts on every platform.Verification
python3 -c "import yaml; ...").release.yml+release-cli.ymlare the only two workflows publishing CLI wheels to PyPI; no third site.cli_mac, absent after the macOS desktop jobs re-ran, andcli_pypi404'd on them.Out of scope (separate follow-up)
v2026.7.10's CLI wheels are not on PyPI (itscli_pypinever completed). With this merged, the next stable release publishes them cleanly.