Overview - Ghost

7 days30 days

Latest CI Pipeline Executions

Fuzzy

Succeeded
30173
0babf246 Moved the site id middleware to TypeScript in shared middleware ref https://linear.app/ghost/issue/PLA-366/return-421-x-site-id-mismatch-from-ghosts-site-id-middleware `core/app.js` defined this handler inline, so the only way to assert its behaviour was a full `startGhost()` boot. PLA-366 changes its response contract and that contract deserves cheap direct coverage, so move it in alongside the other shared middleware, convert it and its test to TypeScript, and take the expected site id as an argument instead of reading config internally. Behaviour is unchanged. The maintenance handler stays in `core/app.js` — it is not what PLA-366 touches, and moving it would mean dealing with the untyped url service for no gain right now.
by Austin Bur...
Succeeded
main
5b18df72 🐛 Fixed cleanup behavior of batch email sending (#30169) ref https://linear.app/ghost/issue/ONC-1954 - add preStopTasks array for tasks that should run prior to server drain - wire up email batch shutdown to preStop - fix error handling in cleanup tasks - prevent batch email send retries after shutdown
by Austin Bur...
Succeeded
main
5b18df72 🐛 Fixed cleanup behavior of batch email sending (#30169) ref https://linear.app/ghost/issue/ONC-1954 - add preStopTasks array for tasks that should run prior to server drain - wire up email batch shutdown to preStop - fix error handling in cleanup tasks - prevent batch email send retries after shutdown
by Austin Bur...
Succeeded
main
5b18df72 🐛 Fixed cleanup behavior of batch email sending (#30169) ref https://linear.app/ghost/issue/ONC-1954 - add preStopTasks array for tasks that should run prior to server drain - wire up email batch shutdown to preStop - fix error handling in cleanup tasks - prevent batch email send retries after shutdown
by Austin Bur...
Succeeded
30169
c15804c1 🐛 Fixed cleanup behavior of batch email sending ref https://linear.app/ghost/issue/ONC-1954 - add preStopTasks array for tasks that should run prior to server drain - wire up email batch shutdown to preStop - fix error handling in cleanup tasks - prevent batch email send retries after shutdown
by Austin Bur...
Succeeded
30169
f55f724a 🐛 Fixed cleanup behavior of batch email sending ref https://linear.app/ghost/issue/ONC-1954 - add preStopTasks array for tasks that should run prior to server drain - wire up email batch shutdown to preStop - fix error handling in cleanup tasks - prevent batch email send retries after shutdown
by Austin Bur...
Succeeded
30169
2e9cc98f 🐛 Fixed cleanup behavior of batch email sending ref https://linear.app/ghost/issue/ONC-1954 - add preStopTasks array for tasks that should run prior to server drain - wire up email batch shutdown to preStop - fix error handling in cleanup tasks - prevent batch email send retries after shutdown
by Austin Bur...
Succeeded
30169
bac980e4 🐛 Fixed cleanup behavior of batch email sending ref https://linear.app/ghost/issue/ONC-1954 - add preStopTasks array for tasks that should run prior to server drain - wire up email batch shutdown to preStop - fix error handling in cleanup tasks - prevent batch email send retries after shutdown
by Austin Bur...
Succeeded
main
4896c74b 🐛 Fixed log flushing on exit (#30165) ref https://linear.app/ghost/issue/PLA-254/fatal-boot-errors-are-lost-from-elasticsearch-no-logging-flush-before - bump framework deps to pull in logging flush fix - wire up log flush to exit points
by Austin Bur...
Succeeded
main
4896c74b 🐛 Fixed log flushing on exit (#30165) ref https://linear.app/ghost/issue/PLA-254/fatal-boot-errors-are-lost-from-elasticsearch-no-logging-flush-before - bump framework deps to pull in logging flush fix - wire up log flush to exit points
by Austin Bur...
Succeeded
main
4896c74b 🐛 Fixed log flushing on exit (#30165) ref https://linear.app/ghost/issue/PLA-254/fatal-boot-errors-are-lost-from-elasticsearch-no-logging-flush-before - bump framework deps to pull in logging flush fix - wire up log flush to exit points
by Austin Bur...
Failed
30165
aa92a606 🐛 Fixed log flushing on exit ref https://linear.app/ghost/issue/PLA-254/fatal-boot-errors-are-lost-from-elasticsearch-no-logging-flush-before - bump framework deps to pull in logging flush fix - wire up log flush to exit points
by Austin Bur...
Succeeded
main
617db229 Deduplicated viem in the production image and added image size reporting to CI (#30157) `@x402/*` landed as a second machine-payments rail and, like `mppx` before it, pulls in `viem`. It did not share the copy `mppx` already had — the production image carried two. ## Why there were two `abitype` declares `zod` as an optional peer, used only by its `abitype/zod` subpath, which nothing in the tree imports. pnpm resolved it anyway and the peer suffix propagated up through `ox` and `viem` to their dependents: - `mppx` → `zod@4.4.3` → `viem@2.55.11(zod@4.4.3)` - `@x402/evm`, `@x402/extensions` → `zod@3.25.76` → `viem@2.55.11(zod@3.25.76)` Same version, two byte-identical unpacks. Same for `ox@0.14.33`, `abitype@1.2.3` and `abitype@1.3.0`. Dropping the peer in `.pnpmfile.mjs` (the same hook already used for `consolidate`, `knex` and the `typescript` peer on these very packages) collapses each to one instance. Both zod majors stay installed — that is a genuine version conflict between `mppx` and `@x402/*`, not a peer artefact. Measured across two full `Dockerfile.production` builds: | | before | after | delta | |---|---|---|---| | shipped production tree | 195.9 MiB | 184.9 MiB | **−11.1 MiB** | | files | 32,245 | 28,763 | **−3,482** | `viem` alone is 7.4 MiB and 2,894 of those files. File count matters as much as bytes: the deploy `COPY` layer is extracted single-threaded, once per CI E2E shard. Verified with a real install — the four `@x402/*` and `mppx` entrypoints load, and the 50 machine-payments unit tests pass. ## Why CI did not catch it `Inspect image size and layers` is gated 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. 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, 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 first commit, the diff names it outright: ``` ### Duplicated packages (4, 11.1 MiB recoverable) | Package | Copies | Recoverable | |------------------|--------|-------------| | `viem@2.55.11` | 2 | 7.4 MiB | | `ox@0.14.33` | 2 | 3.0 MiB | | `abitype@1.3.0` | 2 | 0.4 MiB | | `abitype@1.2.3` | 2 | 0.4 MiB | ``` Every layer under the `report` target is already cached from the core build, so the extra build is an export rather than a rebuild. ## Notes - The first PR after this merges will show "no baseline" — the base commit's run predates the artifact. Self-corrects. - `actionlint` reports no new findings; `scripts` lint is clean and its 109 tests pass, including 15 new ones.
by Austin Bur...
Succeeded
main
617db229 Deduplicated viem in the production image and added image size reporting to CI (#30157) `@x402/*` landed as a second machine-payments rail and, like `mppx` before it, pulls in `viem`. It did not share the copy `mppx` already had — the production image carried two. ## Why there were two `abitype` declares `zod` as an optional peer, used only by its `abitype/zod` subpath, which nothing in the tree imports. pnpm resolved it anyway and the peer suffix propagated up through `ox` and `viem` to their dependents: - `mppx` → `zod@4.4.3` → `viem@2.55.11(zod@4.4.3)` - `@x402/evm`, `@x402/extensions` → `zod@3.25.76` → `viem@2.55.11(zod@3.25.76)` Same version, two byte-identical unpacks. Same for `ox@0.14.33`, `abitype@1.2.3` and `abitype@1.3.0`. Dropping the peer in `.pnpmfile.mjs` (the same hook already used for `consolidate`, `knex` and the `typescript` peer on these very packages) collapses each to one instance. Both zod majors stay installed — that is a genuine version conflict between `mppx` and `@x402/*`, not a peer artefact. Measured across two full `Dockerfile.production` builds: | | before | after | delta | |---|---|---|---| | shipped production tree | 195.9 MiB | 184.9 MiB | **−11.1 MiB** | | files | 32,245 | 28,763 | **−3,482** | `viem` alone is 7.4 MiB and 2,894 of those files. File count matters as much as bytes: the deploy `COPY` layer is extracted single-threaded, once per CI E2E shard. Verified with a real install — the four `@x402/*` and `mppx` entrypoints load, and the 50 machine-payments unit tests pass. ## Why CI did not catch it `Inspect image size and layers` is gated 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. 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, 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 first commit, the diff names it outright: ``` ### Duplicated packages (4, 11.1 MiB recoverable) | Package | Copies | Recoverable | |------------------|--------|-------------| | `viem@2.55.11` | 2 | 7.4 MiB | | `ox@0.14.33` | 2 | 3.0 MiB | | `abitype@1.3.0` | 2 | 0.4 MiB | | `abitype@1.2.3` | 2 | 0.4 MiB | ``` Every layer under the `report` target is already cached from the core build, so the extra build is an export rather than a rebuild. ## Notes - The first PR after this merges will show "no baseline" — the base commit's run predates the artifact. Self-corrects. - `actionlint` reports no new findings; `scripts` lint is clean and its 109 tests pass, including 15 new ones.
by Austin Bur...
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
main
2bc34fca Improved release packaging process for docker image (#30153) no ref - attach packed tarball (without package/ suffix) to github release, to be used by the docker official image - include prune.mts script in pack tarball, so docker can use it to prune files and not duplicate the work
by Austin Bur...
Succeeded
main
2bc34fca Improved release packaging process for docker image (#30153) no ref - attach packed tarball (without package/ suffix) to github release, to be used by the docker official image - include prune.mts script in pack tarball, so docker can use it to prune files and not duplicate the work
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...
Succeeded
30153
26804880 Improved release packaging process for docker image no ref - attach packed tarball (without package/ suffix) to github release, to be used by the docker official image - include prune.mts script in pack tarball, so docker can use it to prune files and not duplicate the work
by Austin Bur...