refs https://github.com/TryGhost/Toolbox/issues/357
- Adds support for persisted one off offloaded (worker thread) jobs
- To try them out run Ghost instance in "testmode" and shoo a request like so: `curl http://localhost:2368/ghost/api/oneoff/graceful-job` - this starts a one time job from graceful-job script (can only ever be executed once on the Ghost instance)
- Job's progress and runtime details are persisted in `jobs` table
- To play more with one off jobs use `addOneOffJob` method available on jobsService
refs https://github.com/TryGhost/Toolbox/issues/357
- Job persisted in the database need to track job's execution status such as completion, failure, execution start and end times. This changeset allows to hook into job/bree lifecycle to track job's progress.
- NOTE: only supports "offloaded" jobs at the moment. Support for "inline" jobs will be added once there's a clear usecase for it.
- The "started" status and "started_at" timestamp are assigned to a job at the moment when the worker thread is created inside of bree
- The "finished" status and "finished_at" timestamp are assigned to a job when a "done" event is passed from the job script (NOTE: using process.exit(0) will not trigger the "finished" state")
- The "failed" status is assigned when the job execution is interrupted with an error
refs https://github.com/TryGhost/Toolbox/issues/357
- One time jobs need a storage mechanism to be run only ever once.
- Field notes:
- `id`, `created_at`, `updated_at` - standard Ghost fields
- `name` - unique name of the job, could also be used with prefixing to identify certain type of job (e.g.: backup-bob-2022-10-16, backup-sam-2023-01-13 identifying backup jobs run by users)
- `status` - 'started' | 'finished' | 'failed' | 'queued' (need to identify when the job is in progress, done, added to the execution queue, or errored)
- `started_at` - when the job started execution
- `finished_at` - when the job successfully finished execution
closes https://github.com/TryGhost/Team/issues/1684
**Migrations:**
- Added report permissions (fixtures + migrations)
- Dropped reason field in reports (no textarea in reports in V1)
- Dropped nullable from comment_likes.member_id (can't be null)
- Added SET NULL/CASCADE foreign keys for comments related tables(*)
(*):
fixes https://github.com/TryGhost/Team/issues/1687
refs https://ghost.slack.com/archives/C02G9E68C/p1658217288591369
This commit adds support for `SET NULL` foreign keys in schema and migration helpers + also fixes the foreign keys for the comment_reports, comment_likes and comments tables.
- When a member is deleted, we **do** want to keep their reports (SET NULL)
- When a member is deleted, we **do not** want to keep their likes (CASCADE)
- When a member is deleted, we **do** want to keep the comments (SET NULL)
**Changes:**
- Added report API: `POST /members/api/comments/{id}}/report/`
- Sends an email to the owner when a comment is reported
- Saves a report to the database (not used for now, but might be useful later)
refs https://github.com/TryGhost/Toolbox/issues/357
- This is a scaffolding for what will become a one off job scheduling mechanism. The aim is allowing to run jobs which can be only ever be run once in the lifetime of the instance - persisting through restarts.
refs https://github.com/TryGhost/Toolbox/issues/357
- In upcoming iteration job manager will need "models" fully initialized to be able to persiste one time jobs. This bit of code of in a bad place as it initialized (through require) the job manager without having models module initialized first.
- The change moves that code from a bad to less bad place (wasn't able to think of any better location for now). Checking for `server:testmode' config in job initialization has a little bit of a smell, but don't think it's super critical. Could be improved if a better structure appears in the future!
- we're going to be pinning all dependencies within the monorepo
- this shouldn't change anything anyway because we're using the same
version across all packages
- we keep seeing a lot of random failures from CI due to the Posts
Content API
- I think it's because of the Ghost boot + number of fixtures we load,
which sends us over our 10s threshold
- let's see if 15s resolves that
- these packages are split apart for local development, but will be
bundled into Ghost when publishing
- therefore, these packages won't be published so we are resetting the
versions to make them cleaner
https://github.com/TryGhost/Toolbox/issues/357
- This is a groundwork before adding one-off (solo) jobs with persistance to the job manager
- Making the addJob method async also makes the whole interface consistent - removeJob and shutdown are also async
