ci: add a manual disk-consumption stress workflow by aryanku-dev · Pull Request #2408 · percy/cli

aryanku-dev · 2026-08-27T14:52:40Z

Adds a workflow_dispatch-only job that measures how much scratch disk a large Percy snapshot build consumes on a stock CI runner.

Why

A local 250-page build exhausted a laptop and died with Browser not connected — not a disk error, which is what makes this worth catching. Measured rate was ~30 MB of scratch per snapshot, so:

build size	projected scratch
250 pages	~7–8 GB
500 pages	~15 GB

A stock ubuntu-latest runner has ~14 GB free. So a large Percy build plausibly cannot complete on a standard runner — and the failure mode is a confusing browser error rather than ENOSPC. This workflow answers that directly.

Leaked Chromium profile dirs ($TMPDIR/percy-browser-*, ~88 MB each, never cleaned up) accounted for only about a third of the local consumption. The rest is unexplained, which is the main reason for the 15s df/du sampler — it produces the timeline the local run could not.

Design notes

Manual trigger only. It consumes Percy quota (snapshots × browsers) and has no business running on push.
free_disk defaults to off, so the first run measures a stock runner. That is the customer-relevant number; enable it only to force a full-size run.
Needs a new PERCY_STRESS_TOKEN secret pointing at a throwaway project — deliberately notPERCY_REGRESSION_TOKEN, so stress builds never pollute the nightly regression baseline.
Inputs are passed through env: rather than interpolated into run: blocks.
Emits a step summary (snapshots taken, MB consumed, per-snapshot rate, whether the browser was lost) and uploads disk-timeline.csv + the Percy log as an artifact.

Merge note

workflow_dispatch workflows are only dispatchable once they exist on the default branch, so this has to merge before it can run.

Found while stress-testing the Node 20 CLI (#2386), but unrelated to that migration — the behaviour is not Node-version specific.

🤖 Generated with Claude Code

A local 250-page snapshot build exhausted a laptop's disk and died with "Browser not connected" rather than a disk error, at roughly 30 MB of scratch per snapshot. Leaked Chromium profile dirs explained only about a third of it, so the rest is unaccounted for. This runs the same build on a stock ubuntu runner and samples df/du every 15s, producing the timeline the local run could not: where the bytes actually land, and whether a large Percy build survives ~14 GB of runner disk at all. Both the URL count and an optional runner-disk reclaim are inputs; reclaim defaults off so the first run measures a stock runner, which is the customer-relevant case. workflow_dispatch only — it consumes Percy quota (snapshots x browsers) and has no business running on push. Needs a PERCY_STRESS_TOKEN secret pointing at a throwaway project, deliberately not the nightly PERCY_REGRESSION_TOKEN. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

workflow_dispatch is not dispatchable until the file reaches the default branch (gh returned HTTP 404), so add a push trigger scoped to this branch — the same mechanism the regression job uses — to get results before merge. URL_COUNT falls back to 250 because `inputs` does not exist on push. Both should come back out once this merges and dispatch works. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

@v4

semgrep's github-actions-mutable-action-tag rule blocked the branch on three floating @v4 tags; every other workflow here pins to a full SHA, so match that convention using the SHAs already in use. Verified locally with semgrep 1.173.0 (the version CI runs): 0 findings. Also removes the push trigger now that it has served its purpose — run 33086755284 captured the pre-merge result. Dispatch-only from here, so this push does not start another 250-URL build. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

aryanku-dev · 2026-08-27T14:52:40Z

Adds a workflow_dispatch-only job that measures how much scratch disk a large Percy snapshot build consumes on a stock CI runner.

Why

A local 250-page build exhausted a laptop and died with Browser not connected — not a disk error, which is what makes this worth catching. Measured rate was ~30 MB of scratch per snapshot, so:

build size	projected scratch
250 pages	~7–8 GB
500 pages	~15 GB

A stock ubuntu-latest runner has ~14 GB free. So a large Percy build plausibly cannot complete on a standard runner — and the failure mode is a confusing browser error rather than ENOSPC. This workflow answers that directly.

Leaked Chromium profile dirs ($TMPDIR/percy-browser-*, ~88 MB each, never cleaned up) accounted for only about a third of the local consumption. The rest is unexplained, which is the main reason for the 15s df/du sampler — it produces the timeline the local run could not.

Design notes

Manual trigger only. It consumes Percy quota (snapshots × browsers) and has no business running on push.
free_disk defaults to off, so the first run measures a stock runner. That is the customer-relevant number; enable it only to force a full-size run.
Needs a new PERCY_STRESS_TOKEN secret pointing at a throwaway project — deliberately notPERCY_REGRESSION_TOKEN, so stress builds never pollute the nightly regression baseline.
Inputs are passed through env: rather than interpolated into run: blocks.
Emits a step summary (snapshots taken, MB consumed, per-snapshot rate, whether the browser was lost) and uploads disk-timeline.csv + the Percy log as an artifact.

Merge note

workflow_dispatch workflows are only dispatchable once they exist on the default branch, so this has to merge before it can run.

Found while stress-testing the Node 20 CLI (#2386), but unrelated to that migration — the behaviour is not Node-version specific.

🤖 Generated with Claude Code

A local 250-page snapshot build exhausted a laptop's disk and died with "Browser not connected" rather than a disk error, at roughly 30 MB of scratch per snapshot. Leaked Chromium profile dirs explained only about a third of it, so the rest is unaccounted for. This runs the same build on a stock ubuntu runner and samples df/du every 15s, producing the timeline the local run could not: where the bytes actually land, and whether a large Percy build survives ~14 GB of runner disk at all. Both the URL count and an optional runner-disk reclaim are inputs; reclaim defaults off so the first run measures a stock runner, which is the customer-relevant case. workflow_dispatch only — it consumes Percy quota (snapshots x browsers) and has no business running on push. Needs a PERCY_STRESS_TOKEN secret pointing at a throwaway project, deliberately not the nightly PERCY_REGRESSION_TOKEN. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

workflow_dispatch is not dispatchable until the file reaches the default branch (gh returned HTTP 404), so add a push trigger scoped to this branch — the same mechanism the regression job uses — to get results before merge. URL_COUNT falls back to 250 because `inputs` does not exist on push. Both should come back out once this merges and dispatch works. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

@v4

semgrep's github-actions-mutable-action-tag rule blocked the branch on three floating @v4 tags; every other workflow here pins to a full SHA, so match that convention using the SHAs already in use. Verified locally with semgrep 1.173.0 (the version CI runs): 0 findings. Also removes the push trigger now that it has served its purpose — run 33086755284 captured the pre-merge result. Dispatch-only from here, so this push does not start another 250-URL build. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

aryanku-dev · 2026-08-27T14:52:40Z

Adds a workflow_dispatch-only job that measures how much scratch disk a large Percy snapshot build consumes on a stock CI runner.

Why

A local 250-page build exhausted a laptop and died with Browser not connected — not a disk error, which is what makes this worth catching. Measured rate was ~30 MB of scratch per snapshot, so:

build size	projected scratch
250 pages	~7–8 GB
500 pages	~15 GB

A stock ubuntu-latest runner has ~14 GB free. So a large Percy build plausibly cannot complete on a standard runner — and the failure mode is a confusing browser error rather than ENOSPC. This workflow answers that directly.

Leaked Chromium profile dirs ($TMPDIR/percy-browser-*, ~88 MB each, never cleaned up) accounted for only about a third of the local consumption. The rest is unexplained, which is the main reason for the 15s df/du sampler — it produces the timeline the local run could not.

Design notes

Manual trigger only. It consumes Percy quota (snapshots × browsers) and has no business running on push.
free_disk defaults to off, so the first run measures a stock runner. That is the customer-relevant number; enable it only to force a full-size run.
Needs a new PERCY_STRESS_TOKEN secret pointing at a throwaway project — deliberately notPERCY_REGRESSION_TOKEN, so stress builds never pollute the nightly regression baseline.
Inputs are passed through env: rather than interpolated into run: blocks.
Emits a step summary (snapshots taken, MB consumed, per-snapshot rate, whether the browser was lost) and uploads disk-timeline.csv + the Percy log as an artifact.

Merge note

workflow_dispatch workflows are only dispatchable once they exist on the default branch, so this has to merge before it can run.

Found while stress-testing the Node 20 CLI (#2386), but unrelated to that migration — the behaviour is not Node-version specific.

🤖 Generated with Claude Code

A local 250-page snapshot build exhausted a laptop's disk and died with "Browser not connected" rather than a disk error, at roughly 30 MB of scratch per snapshot. Leaked Chromium profile dirs explained only about a third of it, so the rest is unaccounted for. This runs the same build on a stock ubuntu runner and samples df/du every 15s, producing the timeline the local run could not: where the bytes actually land, and whether a large Percy build survives ~14 GB of runner disk at all. Both the URL count and an optional runner-disk reclaim are inputs; reclaim defaults off so the first run measures a stock runner, which is the customer-relevant case. workflow_dispatch only — it consumes Percy quota (snapshots x browsers) and has no business running on push. Needs a PERCY_STRESS_TOKEN secret pointing at a throwaway project, deliberately not the nightly PERCY_REGRESSION_TOKEN. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

workflow_dispatch is not dispatchable until the file reaches the default branch (gh returned HTTP 404), so add a push trigger scoped to this branch — the same mechanism the regression job uses — to get results before merge. URL_COUNT falls back to 250 because `inputs` does not exist on push. Both should come back out once this merges and dispatch works. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

@v4

semgrep's github-actions-mutable-action-tag rule blocked the branch on three floating @v4 tags; every other workflow here pins to a full SHA, so match that convention using the SHAs already in use. Verified locally with semgrep 1.173.0 (the version CI runs): 0 findings. Also removes the push trigger now that it has served its purpose — run 33086755284 captured the pre-merge result. Dispatch-only from here, so this push does not start another 250-URL build. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

aryanku-dev · 2026-08-27T14:52:40Z

Adds a workflow_dispatch-only job that measures how much scratch disk a large Percy snapshot build consumes on a stock CI runner.

Why

A local 250-page build exhausted a laptop and died with Browser not connected — not a disk error, which is what makes this worth catching. Measured rate was ~30 MB of scratch per snapshot, so:

build size	projected scratch
250 pages	~7–8 GB
500 pages	~15 GB

A stock ubuntu-latest runner has ~14 GB free. So a large Percy build plausibly cannot complete on a standard runner — and the failure mode is a confusing browser error rather than ENOSPC. This workflow answers that directly.

Leaked Chromium profile dirs ($TMPDIR/percy-browser-*, ~88 MB each, never cleaned up) accounted for only about a third of the local consumption. The rest is unexplained, which is the main reason for the 15s df/du sampler — it produces the timeline the local run could not.

Design notes

Manual trigger only. It consumes Percy quota (snapshots × browsers) and has no business running on push.
free_disk defaults to off, so the first run measures a stock runner. That is the customer-relevant number; enable it only to force a full-size run.
Needs a new PERCY_STRESS_TOKEN secret pointing at a throwaway project — deliberately notPERCY_REGRESSION_TOKEN, so stress builds never pollute the nightly regression baseline.
Inputs are passed through env: rather than interpolated into run: blocks.
Emits a step summary (snapshots taken, MB consumed, per-snapshot rate, whether the browser was lost) and uploads disk-timeline.csv + the Percy log as an artifact.

Merge note

workflow_dispatch workflows are only dispatchable once they exist on the default branch, so this has to merge before it can run.

Found while stress-testing the Node 20 CLI (#2386), but unrelated to that migration — the behaviour is not Node-version specific.

🤖 Generated with Claude Code

A local 250-page snapshot build exhausted a laptop's disk and died with "Browser not connected" rather than a disk error, at roughly 30 MB of scratch per snapshot. Leaked Chromium profile dirs explained only about a third of it, so the rest is unaccounted for. This runs the same build on a stock ubuntu runner and samples df/du every 15s, producing the timeline the local run could not: where the bytes actually land, and whether a large Percy build survives ~14 GB of runner disk at all. Both the URL count and an optional runner-disk reclaim are inputs; reclaim defaults off so the first run measures a stock runner, which is the customer-relevant case. workflow_dispatch only — it consumes Percy quota (snapshots x browsers) and has no business running on push. Needs a PERCY_STRESS_TOKEN secret pointing at a throwaway project, deliberately not the nightly PERCY_REGRESSION_TOKEN. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

workflow_dispatch is not dispatchable until the file reaches the default branch (gh returned HTTP 404), so add a push trigger scoped to this branch — the same mechanism the regression job uses — to get results before merge. URL_COUNT falls back to 250 because `inputs` does not exist on push. Both should come back out once this merges and dispatch works. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

@v4

semgrep's github-actions-mutable-action-tag rule blocked the branch on three floating @v4 tags; every other workflow here pins to a full SHA, so match that convention using the SHAs already in use. Verified locally with semgrep 1.173.0 (the version CI runs): 0 findings. Also removes the push trigger now that it has served its purpose — run 33086755284 captured the pre-merge result. Dispatch-only from here, so this push does not start another 250-URL build. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

aryanku-dev · 2026-08-27T14:52:40Z

Adds a workflow_dispatch-only job that measures how much scratch disk a large Percy snapshot build consumes on a stock CI runner.

Why

A local 250-page build exhausted a laptop and died with Browser not connected — not a disk error, which is what makes this worth catching. Measured rate was ~30 MB of scratch per snapshot, so:

build size	projected scratch
250 pages	~7–8 GB
500 pages	~15 GB

A stock ubuntu-latest runner has ~14 GB free. So a large Percy build plausibly cannot complete on a standard runner — and the failure mode is a confusing browser error rather than ENOSPC. This workflow answers that directly.

Leaked Chromium profile dirs ($TMPDIR/percy-browser-*, ~88 MB each, never cleaned up) accounted for only about a third of the local consumption. The rest is unexplained, which is the main reason for the 15s df/du sampler — it produces the timeline the local run could not.

Design notes

Manual trigger only. It consumes Percy quota (snapshots × browsers) and has no business running on push.
free_disk defaults to off, so the first run measures a stock runner. That is the customer-relevant number; enable it only to force a full-size run.
Needs a new PERCY_STRESS_TOKEN secret pointing at a throwaway project — deliberately notPERCY_REGRESSION_TOKEN, so stress builds never pollute the nightly regression baseline.
Inputs are passed through env: rather than interpolated into run: blocks.
Emits a step summary (snapshots taken, MB consumed, per-snapshot rate, whether the browser was lost) and uploads disk-timeline.csv + the Percy log as an artifact.

Merge note

workflow_dispatch workflows are only dispatchable once they exist on the default branch, so this has to merge before it can run.

Found while stress-testing the Node 20 CLI (#2386), but unrelated to that migration — the behaviour is not Node-version specific.

🤖 Generated with Claude Code

A local 250-page snapshot build exhausted a laptop's disk and died with "Browser not connected" rather than a disk error, at roughly 30 MB of scratch per snapshot. Leaked Chromium profile dirs explained only about a third of it, so the rest is unaccounted for. This runs the same build on a stock ubuntu runner and samples df/du every 15s, producing the timeline the local run could not: where the bytes actually land, and whether a large Percy build survives ~14 GB of runner disk at all. Both the URL count and an optional runner-disk reclaim are inputs; reclaim defaults off so the first run measures a stock runner, which is the customer-relevant case. workflow_dispatch only — it consumes Percy quota (snapshots x browsers) and has no business running on push. Needs a PERCY_STRESS_TOKEN secret pointing at a throwaway project, deliberately not the nightly PERCY_REGRESSION_TOKEN. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

workflow_dispatch is not dispatchable until the file reaches the default branch (gh returned HTTP 404), so add a push trigger scoped to this branch — the same mechanism the regression job uses — to get results before merge. URL_COUNT falls back to 250 because `inputs` does not exist on push. Both should come back out once this merges and dispatch works. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

@v4

semgrep's github-actions-mutable-action-tag rule blocked the branch on three floating @v4 tags; every other workflow here pins to a full SHA, so match that convention using the SHAs already in use. Verified locally with semgrep 1.173.0 (the version CI runs): 0 findings. Also removes the push trigger now that it has served its purpose — run 33086755284 captured the pre-merge result. Dispatch-only from here, so this push does not start another 250-URL build. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

aryanku-dev · 2026-08-27T14:52:40Z

Adds a workflow_dispatch-only job that measures how much scratch disk a large Percy snapshot build consumes on a stock CI runner.

Why

A local 250-page build exhausted a laptop and died with Browser not connected — not a disk error, which is what makes this worth catching. Measured rate was ~30 MB of scratch per snapshot, so:

build size	projected scratch
250 pages	~7–8 GB
500 pages	~15 GB

A stock ubuntu-latest runner has ~14 GB free. So a large Percy build plausibly cannot complete on a standard runner — and the failure mode is a confusing browser error rather than ENOSPC. This workflow answers that directly.

Leaked Chromium profile dirs ($TMPDIR/percy-browser-*, ~88 MB each, never cleaned up) accounted for only about a third of the local consumption. The rest is unexplained, which is the main reason for the 15s df/du sampler — it produces the timeline the local run could not.

Design notes

Manual trigger only. It consumes Percy quota (snapshots × browsers) and has no business running on push.
free_disk defaults to off, so the first run measures a stock runner. That is the customer-relevant number; enable it only to force a full-size run.
Needs a new PERCY_STRESS_TOKEN secret pointing at a throwaway project — deliberately notPERCY_REGRESSION_TOKEN, so stress builds never pollute the nightly regression baseline.
Inputs are passed through env: rather than interpolated into run: blocks.
Emits a step summary (snapshots taken, MB consumed, per-snapshot rate, whether the browser was lost) and uploads disk-timeline.csv + the Percy log as an artifact.

Merge note

workflow_dispatch workflows are only dispatchable once they exist on the default branch, so this has to merge before it can run.

Found while stress-testing the Node 20 CLI (#2386), but unrelated to that migration — the behaviour is not Node-version specific.

🤖 Generated with Claude Code

A local 250-page snapshot build exhausted a laptop's disk and died with "Browser not connected" rather than a disk error, at roughly 30 MB of scratch per snapshot. Leaked Chromium profile dirs explained only about a third of it, so the rest is unaccounted for. This runs the same build on a stock ubuntu runner and samples df/du every 15s, producing the timeline the local run could not: where the bytes actually land, and whether a large Percy build survives ~14 GB of runner disk at all. Both the URL count and an optional runner-disk reclaim are inputs; reclaim defaults off so the first run measures a stock runner, which is the customer-relevant case. workflow_dispatch only — it consumes Percy quota (snapshots x browsers) and has no business running on push. Needs a PERCY_STRESS_TOKEN secret pointing at a throwaway project, deliberately not the nightly PERCY_REGRESSION_TOKEN. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

workflow_dispatch is not dispatchable until the file reaches the default branch (gh returned HTTP 404), so add a push trigger scoped to this branch — the same mechanism the regression job uses — to get results before merge. URL_COUNT falls back to 250 because `inputs` does not exist on push. Both should come back out once this merges and dispatch works. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

@v4

semgrep's github-actions-mutable-action-tag rule blocked the branch on three floating @v4 tags; every other workflow here pins to a full SHA, so match that convention using the SHAs already in use. Verified locally with semgrep 1.173.0 (the version CI runs): 0 findings. Also removes the push trigger now that it has served its purpose — run 33086755284 captured the pre-merge result. Dispatch-only from here, so this push does not start another 250-URL build. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

aryanku-dev · 2026-08-27T14:52:40Z

Adds a workflow_dispatch-only job that measures how much scratch disk a large Percy snapshot build consumes on a stock CI runner.

Why

A local 250-page build exhausted a laptop and died with Browser not connected — not a disk error, which is what makes this worth catching. Measured rate was ~30 MB of scratch per snapshot, so:

build size	projected scratch
250 pages	~7–8 GB
500 pages	~15 GB

A stock ubuntu-latest runner has ~14 GB free. So a large Percy build plausibly cannot complete on a standard runner — and the failure mode is a confusing browser error rather than ENOSPC. This workflow answers that directly.

Leaked Chromium profile dirs ($TMPDIR/percy-browser-*, ~88 MB each, never cleaned up) accounted for only about a third of the local consumption. The rest is unexplained, which is the main reason for the 15s df/du sampler — it produces the timeline the local run could not.

Design notes

Manual trigger only. It consumes Percy quota (snapshots × browsers) and has no business running on push.
free_disk defaults to off, so the first run measures a stock runner. That is the customer-relevant number; enable it only to force a full-size run.
Needs a new PERCY_STRESS_TOKEN secret pointing at a throwaway project — deliberately notPERCY_REGRESSION_TOKEN, so stress builds never pollute the nightly regression baseline.
Inputs are passed through env: rather than interpolated into run: blocks.
Emits a step summary (snapshots taken, MB consumed, per-snapshot rate, whether the browser was lost) and uploads disk-timeline.csv + the Percy log as an artifact.

Merge note

workflow_dispatch workflows are only dispatchable once they exist on the default branch, so this has to merge before it can run.

Found while stress-testing the Node 20 CLI (#2386), but unrelated to that migration — the behaviour is not Node-version specific.

🤖 Generated with Claude Code

A local 250-page snapshot build exhausted a laptop's disk and died with "Browser not connected" rather than a disk error, at roughly 30 MB of scratch per snapshot. Leaked Chromium profile dirs explained only about a third of it, so the rest is unaccounted for. This runs the same build on a stock ubuntu runner and samples df/du every 15s, producing the timeline the local run could not: where the bytes actually land, and whether a large Percy build survives ~14 GB of runner disk at all. Both the URL count and an optional runner-disk reclaim are inputs; reclaim defaults off so the first run measures a stock runner, which is the customer-relevant case. workflow_dispatch only — it consumes Percy quota (snapshots x browsers) and has no business running on push. Needs a PERCY_STRESS_TOKEN secret pointing at a throwaway project, deliberately not the nightly PERCY_REGRESSION_TOKEN. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

workflow_dispatch is not dispatchable until the file reaches the default branch (gh returned HTTP 404), so add a push trigger scoped to this branch — the same mechanism the regression job uses — to get results before merge. URL_COUNT falls back to 250 because `inputs` does not exist on push. Both should come back out once this merges and dispatch works. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

@v4

semgrep's github-actions-mutable-action-tag rule blocked the branch on three floating @v4 tags; every other workflow here pins to a full SHA, so match that convention using the SHAs already in use. Verified locally with semgrep 1.173.0 (the version CI runs): 0 findings. Also removes the push trigger now that it has served its purpose — run 33086755284 captured the pre-merge result. Dispatch-only from here, so this push does not start another 250-URL build. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

aryanku-dev · 2026-08-27T14:52:40Z

Adds a workflow_dispatch-only job that measures how much scratch disk a large Percy snapshot build consumes on a stock CI runner.

Why

A local 250-page build exhausted a laptop and died with Browser not connected — not a disk error, which is what makes this worth catching. Measured rate was ~30 MB of scratch per snapshot, so:

build size	projected scratch
250 pages	~7–8 GB
500 pages	~15 GB

A stock ubuntu-latest runner has ~14 GB free. So a large Percy build plausibly cannot complete on a standard runner — and the failure mode is a confusing browser error rather than ENOSPC. This workflow answers that directly.

Leaked Chromium profile dirs ($TMPDIR/percy-browser-*, ~88 MB each, never cleaned up) accounted for only about a third of the local consumption. The rest is unexplained, which is the main reason for the 15s df/du sampler — it produces the timeline the local run could not.

Design notes

Manual trigger only. It consumes Percy quota (snapshots × browsers) and has no business running on push.
free_disk defaults to off, so the first run measures a stock runner. That is the customer-relevant number; enable it only to force a full-size run.
Needs a new PERCY_STRESS_TOKEN secret pointing at a throwaway project — deliberately notPERCY_REGRESSION_TOKEN, so stress builds never pollute the nightly regression baseline.
Inputs are passed through env: rather than interpolated into run: blocks.
Emits a step summary (snapshots taken, MB consumed, per-snapshot rate, whether the browser was lost) and uploads disk-timeline.csv + the Percy log as an artifact.

Merge note

workflow_dispatch workflows are only dispatchable once they exist on the default branch, so this has to merge before it can run.

Found while stress-testing the Node 20 CLI (#2386), but unrelated to that migration — the behaviour is not Node-version specific.

🤖 Generated with Claude Code

A local 250-page snapshot build exhausted a laptop's disk and died with "Browser not connected" rather than a disk error, at roughly 30 MB of scratch per snapshot. Leaked Chromium profile dirs explained only about a third of it, so the rest is unaccounted for. This runs the same build on a stock ubuntu runner and samples df/du every 15s, producing the timeline the local run could not: where the bytes actually land, and whether a large Percy build survives ~14 GB of runner disk at all. Both the URL count and an optional runner-disk reclaim are inputs; reclaim defaults off so the first run measures a stock runner, which is the customer-relevant case. workflow_dispatch only — it consumes Percy quota (snapshots x browsers) and has no business running on push. Needs a PERCY_STRESS_TOKEN secret pointing at a throwaway project, deliberately not the nightly PERCY_REGRESSION_TOKEN. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

workflow_dispatch is not dispatchable until the file reaches the default branch (gh returned HTTP 404), so add a push trigger scoped to this branch — the same mechanism the regression job uses — to get results before merge. URL_COUNT falls back to 250 because `inputs` does not exist on push. Both should come back out once this merges and dispatch works. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

@v4

semgrep's github-actions-mutable-action-tag rule blocked the branch on three floating @v4 tags; every other workflow here pins to a full SHA, so match that convention using the SHAs already in use. Verified locally with semgrep 1.173.0 (the version CI runs): 0 findings. Also removes the push trigger now that it has served its purpose — run 33086755284 captured the pre-merge result. Dispatch-only from here, so this push does not start another 250-URL build. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

aryanku-dev requested a review from a team as a code owner August 27, 2026 14:52

aryanku-dev requested review from Shivanshu-07 and ninadbstack August 27, 2026 14:52

github-advanced-securityBot found potential problems Aug 27, 2026
View reviewed changes

Comment thread.github/workflows/stress-disk.yml Fixed
Comment thread.github/workflows/stress-disk.yml Fixed
Comment thread.github/workflows/stress-disk.yml Fixed

aryanku-devand others added 2 commits August 27, 2026 20:44

aryanku-dev closed this Aug 28, 2026

aryanku-dev requested a review from a team as a code owner August 27, 2026 14:52

aryanku-dev requested review from Shivanshu-07 and ninadbstack August 27, 2026 14:52

github-advanced-securityBot found potential problems Aug 27, 2026
View reviewed changes

Comment thread.github/workflows/stress-disk.yml Fixed
Comment thread.github/workflows/stress-disk.yml Fixed
Comment thread.github/workflows/stress-disk.yml Fixed

aryanku-devand others added 2 commits August 27, 2026 20:44

aryanku-dev closed this Aug 28, 2026

aryanku-dev requested a review from a team as a code owner August 27, 2026 14:52

aryanku-dev requested review from Shivanshu-07 and ninadbstack August 27, 2026 14:52

github-advanced-securityBot found potential problems Aug 27, 2026
View reviewed changes

Comment thread.github/workflows/stress-disk.yml Fixed
Comment thread.github/workflows/stress-disk.yml Fixed
Comment thread.github/workflows/stress-disk.yml Fixed

aryanku-devand others added 2 commits August 27, 2026 20:44

aryanku-dev closed this Aug 28, 2026

aryanku-dev requested a review from a team as a code owner August 27, 2026 14:52

aryanku-dev requested review from Shivanshu-07 and ninadbstack August 27, 2026 14:52

github-advanced-securityBot found potential problems Aug 27, 2026
View reviewed changes

Comment thread.github/workflows/stress-disk.yml Fixed
Comment thread.github/workflows/stress-disk.yml Fixed
Comment thread.github/workflows/stress-disk.yml Fixed

aryanku-devand others added 2 commits August 27, 2026 20:44

aryanku-dev closed this Aug 28, 2026

aryanku-dev requested a review from a team as a code owner August 27, 2026 14:52

aryanku-dev requested review from Shivanshu-07 and ninadbstack August 27, 2026 14:52

github-advanced-securityBot found potential problems Aug 27, 2026
View reviewed changes

Comment thread.github/workflows/stress-disk.yml Fixed
Comment thread.github/workflows/stress-disk.yml Fixed
Comment thread.github/workflows/stress-disk.yml Fixed

aryanku-devand others added 2 commits August 27, 2026 20:44

aryanku-dev closed this Aug 28, 2026

aryanku-dev requested a review from a team as a code owner August 27, 2026 14:52

aryanku-dev requested review from Shivanshu-07 and ninadbstack August 27, 2026 14:52

github-advanced-securityBot found potential problems Aug 27, 2026
View reviewed changes

Comment thread.github/workflows/stress-disk.yml Fixed
Comment thread.github/workflows/stress-disk.yml Fixed
Comment thread.github/workflows/stress-disk.yml Fixed

aryanku-devand others added 2 commits August 27, 2026 20:44

aryanku-dev closed this Aug 28, 2026

aryanku-dev requested a review from a team as a code owner August 27, 2026 14:52

aryanku-dev requested review from Shivanshu-07 and ninadbstack August 27, 2026 14:52

github-advanced-securityBot found potential problems Aug 27, 2026
View reviewed changes

Comment thread.github/workflows/stress-disk.yml Fixed
Comment thread.github/workflows/stress-disk.yml Fixed
Comment thread.github/workflows/stress-disk.yml Fixed

aryanku-devand others added 2 commits August 27, 2026 20:44

aryanku-dev closed this Aug 28, 2026

aryanku-dev requested a review from a team as a code owner August 27, 2026 14:52

aryanku-dev requested review from Shivanshu-07 and ninadbstack August 27, 2026 14:52

github-advanced-securityBot found potential problems Aug 27, 2026
View reviewed changes

Comment thread.github/workflows/stress-disk.yml Fixed
Comment thread.github/workflows/stress-disk.yml Fixed
Comment thread.github/workflows/stress-disk.yml Fixed

aryanku-devand others added 2 commits August 27, 2026 20:44

aryanku-dev closed this Aug 28, 2026

Uh oh!

Conversation

aryanku-dev commented Aug 27, 2026

Why

Design notes

Merge note

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

aryanku-dev commented Aug 27, 2026

Why

Design notes

Merge note

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

aryanku-dev commented Aug 27, 2026

Why

Design notes

Merge note

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

aryanku-dev commented Aug 27, 2026

Why

Design notes

Merge note

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

aryanku-dev commented Aug 27, 2026

Why

Design notes

Merge note

Uh oh!

Uh oh!