Overview - Ghost

GhostWorkspace

CI Pipeline Executions
- Filtered
Runs
Demo

Insights

Compare tasks
Analytics

Overview

Ghost

Loading workspace stats

Loading workspace insights...

Statistics interval

7 days30 days

Latest CI Pipeline Executions

Filter

Fuzzy

Sort by

© 2026 - Nx Cloud

Terms of Service Privacy Policy Changelog Status Docs Contact Nx Cloud Pricing Company @NxDevTools

GhostWorkspace

Agents
Replay
VCS
Self-Healing

Average execution time

9m 3s

1907 CI pipeline executions

Computation time saved

31d 22h

Cache hit rate

88%

Protect cache integrity with sandboxing

Time to Green

52m 58s

Was 1h 3m, improved by 16%

Succeeded
30936
46a0beff Added descriptions to the config schema, and a step to keep adding them no ref z.toJSONSchema() carries .meta() descriptions and examples straight through, so the schema can generate a config reference for self-hosters later. That only works if the metadata is there, and writing it with the key costs a line while retrofitting it across every key is a sweep nobody will volunteer for. So it is now a step in the SCHEMA.md instructions, and the two keys that have schemas today carry their own descriptions rather than telling the next person to do something the existing examples do not. .meta() registers in zod's registry and does not affect parsing, so the round-trip test over the shipped env configs is unchanged.
by Austin Bur...
A
Succeeded
30936
6f99e724 Added descriptions to the config schema, and a step to keep adding them no ref z.toJSONSchema() carries .meta() descriptions and examples straight through, so the schema can generate a config reference for self-hosters later. That only works if the metadata is there, and writing it with the key costs a line while retrofitting it across every key is a sweep nobody will volunteer for. So it is now a step in the SCHEMA.md instructions, and the two keys that have schemas today carry their own descriptions rather than telling the next person to do something the existing examples do not. .meta() registers in zod's registry and does not affect parsing, so the round-trip test over the shipped env configs is unchanged.
by Austin Bur...
A
Succeeded
30936
5070b609 Added descriptions to the config schema, and a step to keep adding them no ref z.toJSONSchema() carries .meta() descriptions and examples straight through, so the schema can generate a config reference for self-hosters later. That only works if the metadata is there, and writing it with the key costs a line while retrofitting it across every key is a sweep nobody will volunteer for. So it is now a step in the SCHEMA.md instructions, and the two keys that have schemas today carry their own descriptions rather than telling the next person to do something the existing examples do not. .meta() registers in zod's registry and does not affect parsing, so the round-trip test over the shipped env configs is unchanged.
by Austin Bur...
A
Succeeded
30936
092b44a3 Added descriptions to the config schema, and a step to keep adding them no ref z.toJSONSchema() carries .meta() descriptions and examples straight through, so the schema can generate a config reference for self-hosters later. That only works if the metadata is there, and writing it with the key costs a line while retrofitting it across every key is a sweep nobody will volunteer for. So it is now a step in the SCHEMA.md instructions, and the two keys that have schemas today carry their own descriptions rather than telling the next person to do something the existing examples do not. .meta() registers in zod's registry and does not affect parsing, so the round-trip test over the shipped env configs is unchanged.
by Austin Bur...
A
Succeeded
30936
8c03846a Added descriptions to the config schema, and a step to keep adding them no ref z.toJSONSchema() carries .meta() descriptions and examples straight through, so the schema can generate a config reference for self-hosters later. That only works if the metadata is there, and writing it with the key costs a line while retrofitting it across every key is a sweep nobody will volunteer for. So it is now a step in the SCHEMA.md instructions, and the two keys that have schemas today carry their own descriptions rather than telling the next person to do something the existing examples do not. .meta() registers in zod's registry and does not affect parsing, so the round-trip test over the shipped env configs is unchanged.
by Austin Bur...
A
Succeeded
30936
b0813f94 Add docstrings for config loading, validation, and override behavior
by coderabbit...
Succeeded
30936
176cbfa7 Added descriptions to the config schema, and a step to keep adding them no ref z.toJSONSchema() carries .meta() descriptions and examples straight through, so the schema can generate a config reference for self-hosters later. That only works if the metadata is there, and writing it with the key costs a line while retrofitting it across every key is a sweep nobody will volunteer for. So it is now a step in the SCHEMA.md instructions, and the two keys that have schemas today carry their own descriptions rather than telling the next person to do something the existing examples do not. .meta() registers in zod's registry and does not affect parsing, so the round-trip test over the shipped env configs is unchanged.
by Austin Bur...
A
Succeeded
30936
52316552 Added descriptions to the config schema, and a step to keep adding them no ref z.toJSONSchema() carries .meta() descriptions and examples straight through, so the schema can generate a config reference for self-hosters later. That only works if the metadata is there, and writing it with the key costs a line while retrofitting it across every key is a sweep nobody will volunteer for. So it is now a step in the SCHEMA.md instructions, and the two keys that have schemas today carry their own descriptions rather than telling the next person to do something the existing examples do not. .meta() registers in zod's registry and does not affect parsing, so the round-trip test over the shipped env configs is unchanged.
by Austin Bur...
A
Succeeded
30936
7ace8ab5 Added descriptions to the config schema, and a step to keep adding them no ref z.toJSONSchema() carries .meta() descriptions and examples straight through, so the schema can generate a config reference for self-hosters later. That only works if the metadata is there, and writing it with the key costs a line while retrofitting it across every key is a sweep nobody will volunteer for. So it is now a step in the SCHEMA.md instructions, and the two keys that have schemas today carry their own descriptions rather than telling the next person to do something the existing examples do not. .meta() registers in zod's registry and does not affect parsing, so the round-trip test over the shipped env configs is unchanged.
by Austin Bur...
A
Succeeded
30936
5896017b Added guidance on where a config schema belongs no ref The obvious reading of schema.ts is that every key should end up in it. Following that would make shared/config - the bottom of the dependency graph, which knows nothing about any feature today - describe bulkEmail, tinybird, machinePayments and the rest. The lowest-level module in the tree would gain inbound knowledge of the highest-level features. The split that avoids it: keys boot cannot start without stay central and fail at load; everything else is the feature's concern, parsed by the feature when it initialises. That needs nothing new - the tree is loose and frozen, and parsing a frozen subtree returns a fresh unfrozen object, so a feature can validate its own slice next to the code that reads it today. It is also the better place for it, since a feature-scoped schema can use strict objects, defaults and coercion that would be reckless centrally, and a broken Mailgun config should not stop Ghost serving pages. Also records the two alternatives that were considered and rejected, so they are not re-proposed: self-registration at import time cannot work when config is the first thing loaded, and generating schema.ts from per-feature schemas buys load-time failure for config that should not fail boot. Corrects two things while here. The `node --use-strict` note was wrong - the flag makes only the entry point strict, and a required CommonJS module keeps its own strictness, so it cannot enforce the freeze at all. And the list of places that wrote through into config was missing knex-migrator, which is the instructive one: when a dependency assembles its own options from what you hand it, it needs a copy.
by Austin Bur...
A
Succeeded
30936
52b2b5d0 Fixed knex-migrator losing its connection options to frozen config no ref MigratorConfig.js hands `config.get('database')` straight to knex-migrator, and its connect() assembles knex's options by mutating what it is given: it sets connection.timezone, charset and decimalNumbers, and deletes connection.filename. On main that write succeeds, and leaks into config like the two cases fixed in the preceding commits. Once config is read-only it stops succeeding - and knex-migrator is sloppy-mode CommonJS, so it does not throw either. The write is simply dropped, and the migrator's connection silently loses its timezone, charset and decimalNumbers. It now gets a clone. cloneDeep rather than structuredClone: this hands a tree to a third party we do not control, so it must not throw on a value it cannot clone - and structuredClone does throw on a Proxy, which rules it out for the read-only guard described below. Found by temporarily replacing the deep freeze with a Proxy whose set trap throws, then running the unit, integration and e2e suites against both MySQL and SQLite plus a development boot. Deep-freezing could not have found it: Ghost's production .js files and its dependencies are sloppy-mode CommonJS, where a write to a frozen object is dropped without an error. That guard is worth having under test as its own change; this was the only violation it found.
by Austin Bur...
A
Succeeded
30936
7c7028dc Changed config to a single frozen, validated tree no ref The schema already validated config, but only the key paths it named were served from the validated result - everything else still read nconf's live stores. Two representations, kept in sync by invalidating one whenever the other was written. That split is what blocked the two things this is for. Freezing only covered the schemafied part, so the config a caller could still mutate was most of it. And a transform could never be safe: a transformed parent and a raw read of an unlisted path beneath it would disagree, because they came from different places. nconf's job now ends at layering the sources. loadNconf() hands its merged tree to createConfig(), which validates it once, deep-freezes it, and returns the object everything reads from then on. The whole config is immutable, not only the typed part, because the schema is loose: a key it does not name is still validated and frozen, just typed `any`. Call sites are unchanged - `get()` walks the frozen tree instead of merging nine stores. set() and reset() stay for tests, and both now rebuild the whole tree from the loaded sources plus the overrides recorded so far. That had to change: nconf's reset() empties every store and configUtils.restore() reapplies 117 keys one at a time, so for the length of a restore the config did not validate - 61 top-level keys, all of them environment variables, no `url` and no `env`. Validation is atomic, so the rebuild has to be too. configUtils needs no changes at all now. writePath copies a level on the way down if it is frozen, because an override's value is often something a test read back out of config. One test was doing read-modify-write on a config object and now sets the path directly. Nothing else in the tree needed changing: the two places that wrote through into config are fixed in the preceding commits. Verified: unit 9320, integration 483, e2e 2661 (one known cross-test flake in the actions audit log, clean in isolation). A development boot is clean - no read-only errors - and all four shipped environments validate under GHOST_CONFIG_SCHEMA_STRICT=true and come back frozen.
by Austin Bur...
A
Succeeded
30936
b2725896 Changed config to a single frozen, validated tree no ref The schema already validated config, but only the key paths it named were served from the validated result - everything else still read nconf's live stores. Two representations, kept in sync by invalidating one whenever the other was written. That split is what blocked the two things this is for. Freezing only covered the schemafied part, so the config a caller could still mutate was most of it. And a transform could never be safe: a transformed parent and a raw read of an unlisted path beneath it would disagree, because they came from different places. nconf's job now ends at layering the sources. loadNconf() hands its merged tree to createConfig(), which validates it once, deep-freezes it, and returns the object everything reads from then on. The whole config is immutable, not only the typed part, because the schema is loose: a key it does not name is still validated and frozen, just typed `any`. Call sites are unchanged - `get()` walks the frozen tree instead of merging nine stores. set() and reset() stay for tests, and both now rebuild the whole tree from the loaded sources plus the overrides recorded so far. That had to change: nconf's reset() empties every store and configUtils.restore() reapplies 117 keys one at a time, so for the length of a restore the config did not validate - 61 top-level keys, all of them environment variables, no `url` and no `env`. Validation is atomic, so the rebuild has to be too. configUtils needs no changes at all now. writePath copies a level on the way down if it is frozen, because an override's value is often something a test read back out of config. One test was doing read-modify-write on a config object and now sets the path directly. Nothing else in the tree needed changing: the two places that wrote through into config are fixed in the preceding commits. Verified: unit 9320, integration 483, e2e 2661 (one known cross-test flake in the actions audit log, clean in isolation). A development boot is clean - no read-only errors - and all four shipped environments validate under GHOST_CONFIG_SCHEMA_STRICT=true and come back frozen.
by Austin Bur...
A
Succeeded
30936
e64709ec Changed config to a single frozen, validated tree no ref The schema already validated config, but only the key paths it named were served from the validated result - everything else still read nconf's live stores. Two representations, kept in sync by invalidating one whenever the other was written. That split is what blocked the two things this is for. Freezing only covered the schemafied part, so the config a caller could still mutate was most of it. And a transform could never be safe: a transformed parent and a raw read of an unlisted path beneath it would disagree, because they came from different places. nconf's job now ends at layering the sources. loadNconf() hands its merged tree to createConfig(), which validates it once, deep-freezes it, and returns the object everything reads from then on. The whole config is immutable, not only the typed part, because the schema is loose: a key it does not name is still validated and frozen, just typed `any`. Call sites are unchanged - `get()` walks the frozen tree instead of merging nine stores. set() and reset() stay for tests, and both now rebuild the whole tree from the loaded sources plus the overrides recorded so far. That had to change: nconf's reset() empties every store and configUtils.restore() reapplies 117 keys one at a time, so for the length of a restore the config did not validate - 61 top-level keys, all of them environment variables, no `url` and no `env`. Validation is atomic, so the rebuild has to be too. configUtils needs no changes at all now. writePath copies a level on the way down if it is frozen, because an override's value is often something a test read back out of config. One test was doing read-modify-write on a config object and now sets the path directly. Nothing else in the tree needed changing: the two places that wrote through into config are fixed in the preceding commits. Verified: unit 9320, integration 483, e2e 2661 (one known cross-test flake in the actions audit log, clean in isolation). A development boot is clean - no read-only errors - and all four shipped environments validate under GHOST_CONFIG_SCHEMA_STRICT=true and come back frozen.
by Austin Bur...
A
Succeeded
30936
c8dc5061 Changed config to a single frozen, validated tree no ref The schema already validated config, but only the key paths it named were served from the validated result - everything else still read nconf's live stores. Two representations, kept in sync by invalidating one whenever the other was written. That split is what blocked the two things this is for. Freezing only covered the schemafied part, so the config a caller could still mutate was most of it. And a transform could never be safe: a transformed parent and a raw read of an unlisted path beneath it would disagree, because they came from different places. nconf's job now ends at layering the sources. loadNconf() hands its merged tree to createConfig(), which validates it once, deep-freezes it, and returns the object everything reads from then on. The whole config is immutable, not only the typed part, because the schema is loose: a key it does not name is still validated and frozen, just typed `any`. Call sites are unchanged - `get()` walks the frozen tree instead of merging nine stores. set() and reset() stay for tests, and both now rebuild the whole tree from the loaded sources plus the overrides recorded so far. That had to change: nconf's reset() empties every store and configUtils.restore() reapplies 117 keys one at a time, so for the length of a restore the config did not validate - 61 top-level keys, all of them environment variables, no `url` and no `env`. Validation is atomic, so the rebuild has to be too. configUtils needs no changes at all now. writePath copies a level on the way down if it is frozen, because an override's value is often something a test read back out of config. One test was doing read-modify-write on a config object and now sets the path directly. Nothing else in the tree needed changing: the two places that wrote through into config are fixed in the preceding commits. Verified: unit 9320, integration 483, e2e 2661 (one known cross-test flake in the actions audit log, clean in isolation). A development boot is clean - no read-only errors - and all four shipped environments validate under GHOST_CONFIG_SCHEMA_STRICT=true and come back frozen.
by Austin Bur...
A
Succeeded
30936
46f51365 Added a zod schema that types and freezes config.get() no ref Config is loaded by nconf and read through `config.get('a:b')`, which returns `any` and hands out a live reference into nconf's stores. There are ~350 such reads in `ghost/core/core` across 78 top-level keys, so validating all of it at once is not a change anyone could review or safely ship. The schema is therefore allowed to grow one key at a time, and `config.get()` is typed from it: a key path the schema covers resolves to that key's validated, deep-frozen value with a real type, and everything else reads straight from nconf with the `any` it has always had. Call sites do not move. A key gains validation, freezing and a type at every existing `config.get('that:key')` in the same change that adds its schema, so there is no half-migrated state to reason about and no codemod to land. Only `url` and `env` are schemafied here. Both are deliberately no stricter than what the loader already asserted, so this validates nothing new. Two details worth knowing about the typing. `z.looseObject` adds an index signature, which collapses the key-path union to `string` and silently types everything as `any` unless it is stripped at each level - hence `Known<T>` in schema.ts. And the path union stays cheap: a synthetic 90-key schema three levels deep produces 2969 paths and adds 0.23s to a cold `tsc --noEmit` over ghost/core. Writing through nconf drops the validated view rather than rebuilding it, because `configUtils.restore()` writes one key at a time and re-validating part-way through would reject a config that is only briefly incomplete. Production never calls `set`, so this costs nothing there. Production only warns on a schema violation. Ghost(Pro) injects config through environment variables this repo cannot see, so a schema this repo got subtly wrong should be a log line rather than a fleet-wide boot crash-loop. Development and test boot strictly, and GHOST_CONFIG_SCHEMA_STRICT overrides either way.
by Austin Bur...
A
Succeeded
30936
67d4670a Added a zod schema that types and freezes config.get() no ref Config is loaded by nconf and read through `config.get('a:b')`, which returns `any` and hands out a live reference into nconf's stores. There are ~350 such reads in `ghost/core/core` across 78 top-level keys, so validating all of it at once is not a change anyone could review or safely ship. The schema is therefore allowed to grow one key at a time, and `config.get()` is typed from it: a key path the schema covers resolves to that key's validated, deep-frozen value with a real type, and everything else reads straight from nconf with the `any` it has always had. Call sites do not move. A key gains validation, freezing and a type at every existing `config.get('that:key')` in the same change that adds its schema, so there is no half-migrated state to reason about and no codemod to land. Only `url` and `env` are schemafied here. Both are deliberately no stricter than what the loader already asserted, so this validates nothing new. Two details worth knowing about the typing. `z.looseObject` adds an index signature, which collapses the key-path union to `string` and silently types everything as `any` unless it is stripped at each level - hence `Known<T>` in schema.ts. And the path union stays cheap: a synthetic 90-key schema three levels deep produces 2969 paths and adds 0.23s to a cold `tsc --noEmit` over ghost/core. Writing through nconf drops the validated view rather than rebuilding it, because `configUtils.restore()` writes one key at a time and re-validating part-way through would reject a config that is only briefly incomplete. Production never calls `set`, so this costs nothing there. Production only warns on a schema violation. Ghost(Pro) injects config through environment variables this repo cannot see, so a schema this repo got subtly wrong should be a log line rather than a fleet-wide boot crash-loop. Development and test boot strictly, and GHOST_CONFIG_SCHEMA_STRICT overrides either way.
by Austin Bur...
A
Succeeded
30936
53a40409 Added a zod schema that types and freezes config.get() no ref Config is loaded by nconf and read through `config.get('a:b')`, which returns `any` and hands out a live reference into nconf's stores. There are ~350 such reads in `ghost/core/core` across 78 top-level keys, so validating all of it at once is not a change anyone could review or safely ship. The schema is therefore allowed to grow one key at a time, and `config.get()` is typed from it: a key path the schema covers resolves to that key's validated, deep-frozen value with a real type, and everything else reads straight from nconf with the `any` it has always had. Call sites do not move. A key gains validation, freezing and a type at every existing `config.get('that:key')` in the same change that adds its schema, so there is no half-migrated state to reason about and no codemod to land. Only `url` and `env` are schemafied here. Both are deliberately no stricter than what the loader already asserted, so this validates nothing new. Two details worth knowing about the typing. `z.looseObject` adds an index signature, which collapses the key-path union to `string` and silently types everything as `any` unless it is stripped at each level - hence `Known<T>` in schema.ts. And the path union stays cheap: a synthetic 90-key schema three levels deep produces 2969 paths and adds 0.23s to a cold `tsc --noEmit` over ghost/core. Writing through nconf drops the validated view rather than rebuilding it, because `configUtils.restore()` writes one key at a time and re-validating part-way through would reject a config that is only briefly incomplete. Production never calls `set`, so this costs nothing there. Production only warns on a schema violation. Ghost(Pro) injects config through environment variables this repo cannot see, so a schema this repo got subtly wrong should be a log line rather than a fleet-wide boot crash-loop. Development and test boot strictly, and GHOST_CONFIG_SCHEMA_STRICT overrides either way.
by Austin Bur...
A
Succeeded
30936
45c8fa61 Added a ratcheting zod schema for Ghost's config no ref Config is loaded by nconf and read through `config.get('a:b')`, which is untyped, unvalidated, and hands out live references into nconf's stores. There are over a thousand such call sites, so neither the schema nor the migration off `get()` can land in one go. This is the scaffold for doing it incrementally. Every top-level key Ghost ships or reads is enumerated in the schema as `todo()` - accepts anything, infers as `any` - so nothing changes for callers today. Ratcheting a section means swapping in a real schema and deleting its line from the allowlist, which the unit suite asserts matches the schema exactly in both directions: a section can't be added without review, and can't quietly regress once ratcheted. The same applies to the second axis, loose objects that still accept unknown keys. The parse output is deep frozen and attached to the config instance as properties, so `config.paths.contentPath` and `config.get('paths:contentPath')` agree for as long as nconf is still underneath and call sites can move one file at a time. The snapshot is cloned before freezing so nconf's own stores stay writable, and tests refresh it through config-utils after they write config. Production only warns on a schema violation. Ghost(Pro) supplies config through environment variables this repo cannot see, so a schema mistake should be a log line there rather than a fleet-wide boot loop; development and test boot strictly, and GHOST_CONFIG_SCHEMA_STRICT overrides either way. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
by Austin Bur...
A