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