Overview - Ghost

7 days30 days

Latest CI Pipeline Executions

Fuzzy

Succeeded
30297
4ca5d8b5 Removed the separate update-check-boot job type ref https://linear.app/ghost/issue/HKG-1972/migrate-update-checks-to-the-durable-jobs-interface The boot dispatch now reuses the single update-check job class, so the update-check-boot type, its class, and its handler registration are gone. The separate type only ever bought per-run log and Sentry identities, and we decided we don't need to distinguish the two paths at execution time - the dispatch-site "boot run queued" log line, emitted right at startup, gives enough context to read which run followed. This reverses the two-identity intent stated in the earlier commits on this branch. If per-run provenance is ever needed, it belongs in the transport as a generic scheduled-vs-dispatched marker on every job, not in per-job types or payload flags. The update-check-boot job_type disappears from job.completed events and Sentry tags; verified against pro-infra that no alert rule keys on it.
by Princi Ver...
Succeeded
30297
3ac83033 Cleaned up the duplicated update-check job handlers ref https://linear.app/ghost/issue/HKG-1972/migrate-update-checks-to-the-durable-jobs-interface The two registrations ran byte-identical bodies, so they now share one handler function. Both registrations remain because delivery is keyed per job type, and the boot and recurring runs keep their distinct log and Sentry identities via the envelope type rather than the handler. Also folded in review fixes: the jobs doc now covers the in-process class-based scheduled-job path alongside the legacy Bree one, and the wrapper unit test evicts the module from the CommonJS require cache instead of calling vi.resetModules(), which never cleared it and left the per-test isolation ineffective.
by Princi Ver...
Succeeded
30297
f4d5972e Cleaned up the duplicated update-check job handlers ref https://linear.app/ghost/issue/HKG-1972/migrate-update-checks-to-the-durable-jobs-interface The two registrations ran byte-identical bodies, so they now share one handler function. Both registrations remain because delivery is keyed per job type, and the boot and recurring runs keep their distinct log and Sentry identities via the envelope type rather than the handler. Also folded in review fixes: the jobs doc now covers the in-process class-based scheduled-job path alongside the legacy Bree one, and the wrapper unit test evicts the module from the CommonJS require cache instead of calling vi.resetModules(), which never cleared it and left the per-test isolation ineffective.
by Princi Ver...
Failed
30297
b8323fc2 Cleaned up the duplicated update-check job handlers ref https://linear.app/ghost/issue/HKG-1972/migrate-update-checks-to-the-durable-jobs-interface The two registrations ran byte-identical bodies, so they now share one handler function. Both registrations remain because delivery is keyed per job type, and the boot and recurring runs keep their distinct log and Sentry identities via the envelope type rather than the handler.
by Princi Ver...
Failed
30297
f0e33954 Migrated update-check to the class-based jobs service ref https://linear.app/ghost/issue/HKG-1972/migrate-update-checks-to-the-durable-jobs-interface Both identities now run in-process through the jobs service instead of a Bree worker, so the worker shim that re-initialised settings, permissions and email-address is deleted rather than ported - the main process already has all of those before the jobs service starts. The schedule functions keep their log strings and full-day random cron verbatim and now take the jobs service as a parameter, with boot resolving the instance as the composition root. The per-run lifecycle lines do change shape: the deleted worker posted '[Background Job] update-check: execution started' / ': completed in Xms' through the legacy bridge, while the jobs service logs the colon-less '[Background Job] update-check started' / 'completed in Xms' plus a structured system.event=job.completed payload with job_type and duration_ms. Verified against pro-infra main (eb383ec): no Elastic rule references update-check or any '[Background Job]' message regex, so no alert keys on the legacy shape. Any future heartbeat rule should target the structured job.completed fields, as the email-analytics rule already does. Boot's schedule call gains a try/catch because the swap turns a synchronous addJob into a rejectable async call inside un-awaited initBackgroundServices, matching the sibling gifts and members blocks. The legacy integration test drove the deleted worker file directly, so it is replaced with one that dispatches each job class through the jobs service and asserts the same end-to-end alert behaviour via runtime config. The jobs-service wrapper test now reloads the module per test: the unit project shares modules across files, so adding a test file re-sharded the run and let another file's init() reach its uninitialised-state assertions.
by Princi Ver...
Succeeded
30297
b892f39d Migrated update-check to the class-based jobs service ref https://linear.app/ghost/issue/HKG-1972/migrate-update-checks-to-the-durable-jobs-interface Both identities now run in-process through the jobs service instead of a Bree worker, so the worker shim that re-initialised settings, permissions and email-address is deleted rather than ported - the main process already has all of those before the jobs service starts. The schedule functions keep their log strings and full-day random cron verbatim and now take the jobs service as a parameter, with boot resolving the instance as the composition root. The per-run lifecycle lines do change shape: the deleted worker posted '[Background Job] update-check: execution started' / ': completed in Xms' through the legacy bridge, while the jobs service logs the colon-less '[Background Job] update-check started' / 'completed in Xms' plus a structured system.event=job.completed payload with job_type and duration_ms. Verified against pro-infra main (eb383ec): no Elastic rule references update-check or any '[Background Job]' message regex, so no alert keys on the legacy shape. Any future heartbeat rule should target the structured job.completed fields, as the email-analytics rule already does. Boot's schedule call gains a try/catch because the swap turns a synchronous addJob into a rejectable async call inside un-awaited initBackgroundServices, matching the sibling gifts and members blocks. The legacy integration test drove the deleted worker file directly, so it is replaced with one that dispatches each job class through the jobs service and asserts the same end-to-end alert behaviour via runtime config. The jobs-service wrapper test now reloads the module per test: the unit project shares modules across files, so adding a test file re-sharded the run and let another file's init() reach its uninitialised-state assertions.
by Princi Ver...
Succeeded
30297
c6b05b4f Migrated update-check to the class-based jobs service ref https://linear.app/ghost/issue/HKG-1972/migrate-update-checks-to-the-durable-jobs-interface Both identities now run in-process through the jobs service instead of a Bree worker, so the worker shim that re-initialised settings, permissions and email-address is deleted rather than ported - the main process already has all of those before the jobs service starts. The schedule functions keep their log strings and full-day random cron verbatim and now take the jobs service as a parameter, with boot resolving the instance as the composition root. The per-run lifecycle lines do change shape: the deleted worker posted '[Background Job] update-check: execution started' / ': completed in Xms' through the legacy bridge, while the jobs service logs the colon-less '[Background Job] update-check started' / 'completed in Xms' plus a structured system.event=job.completed payload with job_type and duration_ms. Verified against pro-infra main (eb383ec): no Elastic rule references update-check or any '[Background Job]' message regex, so no alert keys on the legacy shape. Any future heartbeat rule should target the structured job.completed fields, as the email-analytics rule already does. Boot's schedule call gains a try/catch because the swap turns a synchronous addJob into a rejectable async call inside un-awaited initBackgroundServices, matching the sibling gifts and members blocks. The legacy integration test drove the deleted worker file directly, so it is replaced with one that dispatches each job class through the jobs service and asserts the same end-to-end alert behaviour via runtime config. The jobs-service wrapper test now reloads the module per test: the unit project shares modules across files, so adding a test file re-sharded the run and let another file's init() reach its uninitialised-state assertions.
by Princi Ver...
Succeeded
30164
e563adc0 Migrated update-check to the class-based jobs service ref https://linear.app/ghost/issue/HKG-1972 Follows clean-tokens across to the class-based jobs service. update-check was the odd one out among the recurring jobs: it did its work inside a Bree worker thread, so run-update-check.js had to re-initialise permissions, settings and email-address from scratch just to reach the state the main process was already in, and had to hand-roll cancellation and 'done' messaging on top. None of that was the job - it was the cost of running somewhere else. The task itself was already a plain function with its dependencies resolved by require, so moving it onto the main event loop deletes the worker file outright rather than porting it. The one thing the worker did that genuinely needed replacing is cancellation. It exited on a 'cancel' message specifically so a shutdown would not stall on it, and the new service has no per-job cancellation to inherit. That matters here more than it did for clean-tokens, whose work is a bounded DB delete: the alert branch emails every active admin sequentially, and the mailer defaults to the direct transport with no send timeout, so on a misconfigured instance it is unbounded. Left alone it could hold the shutdown drain open past a deployment's grace period and be killed mid-write. So the handler bounds the whole run with withDeadline, added here as a jobs-service concern because it is the same trade every in-process job will face. Abandoning is not failing, though - the work usually finishes moments later - so a breached deadline gets its own warning event rather than a Sentry capture. Paging someone because their mail host is slow would teach everyone to ignore the alert. Two other things follow from running in process. The mock-server dance the old integration test needed - a real HTTP server because nock cannot reach across a worker boundary, workerData to smuggle config in, process.env to route the worker's mailer - collapses into plain config overrides and mockManager.mockMail. And the worker-relay log lines disappear, so the handler now emits a structured update_check.completed event carrying the summary the previous commit exposed. Scheduling collapses to a single scheduleJobs() entry point. Boot used to decide whether the forced one-off run happened, by reading updateCheck:forceUpdate at the call site; that decision now sits next to the config it reads, which is both where it belongs and the only place it can be tested - boot's background services never run under the test environment. What is left in boot is one delegating call in a try/catch, matching the token cleanup block above it, and initBackgroundServices is exported so a test can finally observe that boot starts the check at all. Without that seam, deleting the call site entirely was a green test run. The legacy registration goes in this same commit, and the worker file with it: with nothing left for Bree to spawn, running in both systems is not something you can do by accident. The unit test pins that by stubbing the legacy manager's addJob and asserting nothing reaches it. The per-boot randomised daily cron keeps its full 24-hour spread, which is what keeps sites off a shared spike against updates.ghost.org - deliberately wider than the 6-hour window the member jobs use. Two pinned draws hold it, because a single sample cannot tell a range from an offset. Test-environment behaviour changes on purpose: scheduling is skipped when NODE_ENV starts with test, as the other migrated jobs do. The in-task environment gate stays as defence in depth. Two deliberate losses worth recording. A hard crash now takes down Ghost rather than one worker thread - the same trade clean-tokens already made. And the boot run and the daily run both serialise to the type 'update-check', where Bree gave them distinct names, so telemetry can no longer tell "fails only when forced at boot" from "fails daily".
by Fabien O'C...