no issue
- Small "boyscout" improvements that were noticed while developing a new feature. This boosts the execution time of the test suit a little bit.
refs https://github.com/TryGhost/Toolbox/issues/359
refs 1606a10ff8
- One-off jobs have been released and needed a little bit of documentation for engineers to find their feet quick with a new concept.
- One-off jobs have a quality of executing only ever once within the lifetime of Ghost instance. For example this feature enabled moving members-migrations from the main path of boot process - boosts the boot time significantly (refed commit)
refs https://github.com/TryGhost/Toolbox/issues/358
- When a one-off job fails it could be restarted during the next call, given it has been cleared from the job queue.
- This readding WILL NOT work for jobs that are restarted within same process (while being kept in the bree's queue). It's specifically targetting one-off jobs like migrations that **might** fail and are only added once per process lifetime.
refs https://github.com/TryGhost/Toolbox/issues/358
- Without going into the model layer (schema) for a job it's hard to figure out which job statuses are available. Using an object with hard typed properties makes the code less prone to typos.
refs https://github.com/TryGhost/Toolbox/issues/358
- The method is a bit of a dangerous to use in cases when the job takes a long time to execute.
- Returning a boolean value did not make sense and provided no helpful information. Having a job model (or not having one) gives the context in which the "completion" happened.
refs ttps://github.com/TryGhost/Toolbox/issues/358
- One off jobs need a way to check for prior execution and await for their completion (in cases when it is reasonably short).
- Added `hasExecuted` and `awaitCompletion` methods to the job manager allowing to monitor one off job state
refs https://github.com/TryGhost/Toolbox/issues/359
- Sending newsletters got broken because underlying "inline job" execution had a bug.
- The real problem was in the job manager trying to verify inline unnamed job status in the database without having a name.
refs https://github.com/TryGhost/Toolbox/issues/359
- Inline one off jobs are needed in situations when we want to run a certain operation only once in the lifecycle of the Ghost instance. These operations should not be extremely long to execute though (not suited for backups or import types of tasks)
refs https://github.com/TryGhost/Toolbox/issues/359
- It's up to a user to decide initializing the job manager without a "jobModel". In these cases the regular recurring job scheduling should work as it did before
- we shouldn't need individual LICENSE files because these packages
won't be published, so the top-level one applies
- also cleaned up README files to remove mentions of Lerna monorepos and
install instructions
refs https://github.com/TryGhost/Toolbox/issues/354
- set packages to `private: true`
- removed repository link - these packages won't be published so this
link won't be seen anywhere
- removed `publishConfig`
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
- 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.
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
refs https://github.com/TryGhost/Toolbox/issues/203
- without `--all`, c8 will ignore files that aren't covered in tests, so
they won't pull the test coverage down
- this means we have artificially high coverage scores
- this commit adds `--all` where previously missing
