Overview - Ghost

7 days30 days

Latest CI Pipeline Executions

Fuzzy

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...