From 26f01c0a291a855c612e0c0bffb0d74e1b4b6aca Mon Sep 17 00:00:00 2001 From: Trevor Walker Date: Wed, 12 Aug 2026 10:45:14 -0600 Subject: [PATCH 1/2] ci: cap release build artifact retention at 7 days MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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. --- .github/workflows/release.yml | 10 ++++++++++ 1 file changed, 10 insertions(+) diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml index a93b6bb73..dd820bc5d 100644 --- a/.github/workflows/release.yml +++ b/.github/workflows/release.yml @@ -706,12 +706,21 @@ jobs: mkdir -p "$target_dir" cp "$source_path" "$target_dir/$binary_name" + # These are intra-run handoff to `publish_release`, which downloads + # `desktop-*` and attaches them to the GitHub Release — that Release is the + # durable copy, not the artifact. At the repository default of 90 days a + # daily nightly retains ~880 MB per run across the four platforms, which + # reached ~14 GB and exhausted the account's artifact storage quota; once + # that happens *every* upload in the org fails, reddening unrelated PRs. + # A week is long enough to re-run a failed publish job against the same + # build and short enough to cap steady state near 6 GB. - name: Upload build artifacts uses: actions/upload-artifact@v7 with: name: desktop-${{ matrix.platform }}-${{ matrix.arch }} path: release-publish/* if-no-files-found: error + retention-days: 7 - name: Upload resource monitor uses: actions/upload-artifact@v7 @@ -719,6 +728,7 @@ jobs: name: resource-monitor-${{ matrix.resource_key }} path: resource-monitor-publish/${{ matrix.resource_key }}/* if-no-files-found: error + retention-days: 7 publish_cli: name: Publish CLI to npm From b260397933f9cd2d5462036cb0642b97a65f2252 Mon Sep 17 00:00:00 2001 From: Trevor Walker Date: Wed, 12 Aug 2026 11:02:08 -0600 Subject: [PATCH 2/2] ci: stop artifact storage limits from failing the test job MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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. --- .github/workflows/ci.yml | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/.github/workflows/ci.yml b/.github/workflows/ci.yml index 1240fa919..4b32f7acc 100644 --- a/.github/workflows/ci.yml +++ b/.github/workflows/ci.yml @@ -98,8 +98,16 @@ jobs: echo "Transfer budget report was not produced." >> "$GITHUB_STEP_SUMMARY" fi + # Non-fatal on purpose. This 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 a shared, org-wide resource that something else can + # exhaust, and when it is exhausted every upload fails — so leaving this + # step fatal lets an unrelated storage condition fail a run whose tests + # passed, which is what happened to #9. Losing the transfer comment is the + # correct way to degrade; blocking code review is not. - name: Upload thread transfer result if: always() + continue-on-error: true uses: actions/upload-artifact@v7 with: name: thread-transfer-results