Overview - Ghost

7 days30 days

Latest CI Pipeline Executions

Fuzzy

Succeeded
30157
fab70635 Added Docker image size reporting to CI no ref `Inspect image size and layers` only runs on the artifact path — forks and cross-repo PRs, where the image is loaded into the local daemon. Canonical PRs push straight to GHCR and never load, so the PRs that actually change the image reported nothing at all. Two additions, both at the end of job_docker so they delay neither the e2e image nor anything downstream, and both continue-on-error on tags so an informational step can never strand a half-published release: - `Report image size` sums compressed layer sizes from the registry manifest for the core and full images, and compares them against the `sha-<short>` tag CI already publishes for the PR base commit. - A `report` build stage carries per-package byte and file counts of the pruned production node_modules (`prune.mts --report`), diffed against the base commit's uploaded report by `scripts/compare-image-report.js`. The per-package view is there because image bytes hide the regression worth catching: a peer-forked duplicate of viem is ~2.9k files but gzips to roughly 2 MB of a 152 MB pull, which reads as noise. Run against the tree from before the preceding commit, the diff names it outright — "viem@2.55.11, 2 copies, 7.4 MiB recoverable". Every layer under the `report` target is already cached from the core build, so the extra build is an export rather than a rebuild.
by Austin Bur...
Failed
30157
e8be8dbc Added Docker image size reporting to CI no ref `Inspect image size and layers` only runs on the artifact path — forks and cross-repo PRs, where the image is loaded into the local daemon. Canonical PRs push straight to GHCR and never load, so the PRs that actually change the image reported nothing at all. Two additions, both at the end of job_docker so they delay neither the e2e image nor anything downstream, and both continue-on-error on tags so an informational step can never strand a half-published release: - `Report image size` sums compressed layer sizes from the registry manifest for the core and full images, and compares them against the `sha-<short>` tag CI already publishes for the PR base commit. - A `report` build stage carries per-package byte and file counts of the pruned production node_modules (`prune.mts --report`), diffed against the base commit's uploaded report by `scripts/compare-image-report.js`. The per-package view is there because image bytes hide the regression worth catching: a peer-forked duplicate of viem is ~2.9k files but gzips to roughly 2 MB of a 152 MB pull, which reads as noise. Run against the tree from before the preceding commit, the diff names it outright — "viem@2.55.11, 2 copies, 7.4 MiB recoverable". Every layer under the `report` target is already cached from the core build, so the extra build is an export rather than a rebuild.
by Austin Bur...
Succeeded
30157
e4cccaed Added Docker image size reporting to CI no ref `Inspect image size and layers` only runs on the artifact path — forks and cross-repo PRs, where the image is loaded into the local daemon. Canonical PRs push straight to GHCR and never load, so the PRs that actually change the image reported nothing at all. Two additions, both at the end of job_docker so they delay neither the e2e image nor anything downstream, and both continue-on-error on tags so an informational step can never strand a half-published release: - `Report image size` sums compressed layer sizes from the registry manifest for the core and full images, and compares them against the `sha-<short>` tag CI already publishes for the PR base commit. - A `report` build stage carries per-package byte and file counts of the pruned production node_modules (`prune.mts --report`), diffed against the base commit's uploaded report by `scripts/compare-image-report.js`. The per-package view is there because image bytes hide the regression worth catching: a peer-forked duplicate of viem is ~2.9k files but gzips to roughly 2 MB of a 152 MB pull, which reads as noise. Run against the tree from before the preceding commit, the diff names it outright — "viem@2.55.11, 2 copies, 7.4 MiB recoverable". Every layer under the `report` target is already cached from the core build, so the extra build is an export rather than a rebuild. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
by Austin Bur...