ci: stop artifact storage from failing CI, and cap release artifact retention - #10
Conversation
The nightly release run uploads four desktop builds totalling ~880 MB and inherits the repository's default 90-day artifact retention, so a few active days accumulate GBs. This repository reached ~14.8 GB, 99.9% of it `desktop-*`, and exhausted the account's Actions artifact storage quota. That failure is not contained to releases: once the quota is gone, every upload in the org fails, so an unrelated pull request goes red on "Failed to CreateArtifact" in a step that has nothing to do with its diff. PR #9 hit exactly that in the thread-transfer-report upload while its own tests passed. These artifacts are intra-run handoff — `publish_release` downloads `desktop-*` and attaches them to the GitHub Release, which is the durable copy. Seven days keeps a window wide enough to re-run a failed publish job against the same build while capping steady state near 6 GB. The resource monitors get the same treatment for the same reason; the tracing config already used `retention-days: 1`. Storage was also pruned manually: 68 desktop artifacts from 2026-08-06 through 2026-08-08 were deleted, freeing 13.93 GB and leaving the most recent set.
Thread transfer impact
This comment will update automatically after the next completed run. |
The thread-transfer upload is a few KB of JSON whose only consumer is thread-transfer-report.yml, which turns it into a PR comment. Account artifact storage is shared and org-wide, so anything can exhaust it — and once it is exhausted every upload fails. A fatal step here therefore lets an unrelated storage condition fail a run whose tests passed, which is exactly what happened to #9 twice: step "Test" succeeded and the job went red on "Failed to CreateArtifact: Artifact storage quota has been hit". Losing the transfer comment is the right way to degrade. Blocking code review on shared storage headroom is not.
|
Added a second, related commit: #9 made the case for it concretely. Its That upload is a few KB of JSON, and its only consumer is So this PR now does two complementary things:
Sequencing note: |
Problem
The nightly
Releaserun builds four desktop platforms and uploads ~880 MB of artifacts per run, with noretention-days— so they inherit the repository default of 90 days (which is also the maximum GitHub allows). A few active days accumulate GBs.This repository had reached 14.8 GB of live artifacts, 99.9% of it
desktop-*, and exhausted the account's Actions artifact storage quota:The failure does not stay in the release lane. Once the quota is gone, every artifact upload in the org fails — so an unrelated PR goes red on
Failed to CreateArtifact: Artifact storage quota has been hitin a step that has nothing to do with its diff. #9 hit exactly that: itsTeststep passed and the job still failed, in the thread-transfer-report upload.What this does
Sets
retention-days: 7on the desktop build and resource-monitor uploads.These are intra-run handoff, not deliverables:
publish_releasedownloadsdesktop-*and attaches them to the GitHub Release, and that Release is the durable copy. Seven days is a deliberate middle — long enough to re-run a failedpublish_releaseagainst the same build, short enough to cap steady state near 6 GB rather than ~78 GB. The tracing-config upload in the same workflow already usedretention-days: 1, so the pattern was established.Storage was also pruned by hand alongside this: 68 desktop artifacts from 2026-08-06 through 2026-08-08 deleted, 13.93 GB freed (14.80 GB → 0.87 GB), keeping the most recent set.
Worth considering separately
The repository-wide retention default is still 90 days (Settings → Actions → "Artifact and log retention"). Lowering it to ~14 days would give every current and future workflow a sane ceiling without needing a per-step change each time. That is a settings change rather than a code change, so it is not in this PR.
Verification
No behavior change to what gets built or published — only how long the intermediates are kept.
vp fmt --checkclean; the two new keys sit at the same indent as their siblingwith:entries. The real proof is the next nightly still publishing its Release normally.Model: Claude Opus 5 via Claude Code.
Need help on this PR? Tag
@codesmithwith what you need. Autofix is disabled.