ci: anaconda.org rejects the 1.5.0b12 conda uploads (402, storage limit), so every later Create Release run on main fails at the #1634 guard

Describe the bug
The 1.5.0b12 conda release never completed. In Create Release run 38458884224, the run that tagged 2025da5e5:

9 of the 10 Conda deployment (release) legs failed at "Upload conda packages to Anaconda" with BinstarError: ('Storage requirements exceeded (3221225472 bytes).', 402);
the tenth failed with ConnectionResetError.

Retry run 38464293447 hit the same 402 on the same 9 legs. Only osx-64/pypcapkit-1.5.0b12-py312_0.tar.bz2 reached anaconda.org.

Because the conda release stays incomplete, every later Create Release run on main reaches the conda legs. The #1634 guard then refuses each one: v1.5.0b12 resolves to '2025da5e5…', but this run was created for <later commit>. That guard is working as releasing.rst:139-141 documents, but main shows a red run after every successful Vendor Update, and each one spends about 18 minutes on the test gate plus 10 conda runners. Runs 38474821457, 38479011058, 38480896925 and 38497299656 (8035434a2) all failed this way. Nothing was published by any of them.

Reproduction
curl -s https://api.anaconda.org/package/jarryshaw/pypcapkit lists 1,295 files, about 9.5 GiB across 79 versions: main 1,144 files / 7.92 GiB, dev-only 151 files / 1.56 GiB. The account's limit is 3 GiB (3,221,225,472 bytes). Measured 2026-10-14.

Expected behavior
The conda release finishes, which is your call. The options, as I understand them:

Delete old builds until under 3 GiB. The dev-only files alone (1.56 GiB) are not enough.
Raise the account's storage limit.
Stop publishing to anaconda.org.

Then re-run the failed jobs of run 38458884224. Each conda leg skips a file that is already uploaded.

A separate design question is whether version_check should skip quietly, and name the run to re-run, when the v* tag names another commit, instead of the documented loud refusal.

take 1

Recorded: option 1, delete old builds to get under the 3 GiB limit. Deleting from anaconda.org cannot be undone, so here is an exact list for you to confirm.

Measured now: 79 versions, 9.48 GiB. 1.5.0b12 needs about 0.16 GiB more for its 14 missing files.

Policy	Keeps	Size after b12	Headroom
A. Newest 15 versions	1.5.0b3–b12, 1.4.0, 1.4.1, 1.4.1.post1, 1.4.1.post2, 1.3.5.post43	about 2.69 GiB	about 0.3 GiB, roughly 1–2 more betas
B. Latest release of each minor line plus the last 3 betas (recommended)	1.5.0b10, b11, b12, 1.4.1.post2, 1.3.5.post43, 1.2.2.post2, 1.1.1.post2, 1.0.3.post3	about 1.19 GiB	about 1.8 GiB, roughly 10 more betas

Both delete everything else. B deletes 71 versions; A deletes 64.

It needs the ANACONDA_TOKEN, which I do not hold. I recommend running it yourself, once:

anaconda login
keep='1.5.0b10 1.5.0b11 1.5.0b12 1.4.1.post2 1.3.5.post43 1.2.2.post2 1.1.1.post2 1.0.3.post3'
for v in $(curl -s https://api.anaconda.org/package/jarryshaw/pypcapkit | python3 -c 'import json,sys; print(*json.load(sys.stdin)["versions"])'); do
  case " $keep " in *" $v "*) ;; *) anaconda remove -f "jarryshaw/pypcapkit/$v" ;; esac
done

(Corrected: the first version of this loop parsed anaconda show, whose lines start +, so it would have matched nothing. This one reads the API's versions list. With echo in place of anaconda remove I dry-ran it under bash: it keeps the 8 versions of policy B and removes 71. anaconda remove USER/PACKAGE/VERSION -f removes a release and all its files, per anaconda-client's commands/remove.py. Swap the keep list for policy A.)

Then re-run the failed jobs of Create Release run 38458884224. Each conda leg skips a file that is already uploaded. Alternatively I can open a PR with a workflow_dispatch job that does this with the secret. Say which policy.

remove done

Confirmed: anaconda.org now holds policy B, 8 versions (1.0.3.post3, 1.1.1.post2, 1.2.2.post2, 1.3.5.post43, 1.4.1.post2, 1.5.0b10–b12), 117 files, 1.03 GiB, under the 3 GiB limit.

1.5.0b12 still has only osx-64/pypcapkit-1.5.0b12-py312_0.tar.bz2. One step remains, and it is yours, since Create Release runs are yours: re-run the failed jobs of run 38458884224, the run that tagged 2025da5e5 (gh run rerun 38458884224 --failed). Each conda leg checks for its own file first, so the one that is already up skips. Once all 10 files are up, later Create Release runs see b12 as complete and stop going red. I will check anaconda.org after the re-run and close this.

i say we skip the rerun. it's all good.

Recorded: the re-run is skipped. The storage limit is fixed (1.03 GiB of 3 GiB). One effect to be aware of: 1.5.0b12 stays at 1 of 10 conda files, so until the next version bump every Create Release run after a successful Vendor Update will still reach the conda legs and stop at the #1634 guard. Those runs will show red, and they publish nothing. The next version releases normally.

Navigation Menu

Repository navigation

ci: anaconda.org rejects the 1.5.0b12 conda uploads (402, storage limit), so every later Create Release run on main fails at the #1634 guard #1704

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

ci: anaconda.org rejects the 1.5.0b12 conda uploads (402, storage limit), so every later Create Release run on main fails at the #1634 guard #1704

Description

Activity

JarryShaw commented on Oct 14, 2026

JarryShaw commented on Oct 14, 2026

JarryShaw commented on Oct 14, 2026

JarryShaw commented on Oct 14, 2026

JarryShaw commented on Oct 14, 2026

JarryShaw commented on Oct 14, 2026

Metadata

Metadata

Assignees

Labels

Projects

Milestone

Relationships

Development

Issue actions