no issue
- we've seen some instances of SQLite saying "database disk image is malformed"
- I think this happens because we copy the file whilst we are still connected to
the old DB
- this commit destroys the connection before copying the clean file to the live
DB file
refs: https://github.com/TryGhost/Toolbox/issues/146
Switched to @tryghost/logging instead of passing around the library. The main sticking points of this change are jobs. When jobs are launched we don't want them to use a separate @tryghost/logging instance because they would start parallel rotation jobs. @tryghost/logging v2.x passes all logs to the parent process if run in a child process, so that we can use the same patterns in jobs and the rest of the codebase.
refs https://github.com/TryGhost/Toolbox/issues/136
- we nuke and reinitialize the DB many times between tests
- this forms a good portion of the time taken and we shouldn't be spending
so much time on just resetting the DB back to a known state
- this commit switches out the knex-migrator reset + init calls for SQLite to
a function which keeps a clean copy of the DB and copies the file back
when we "reset"
- for MySQL, existing functionality is kept
- this massively speeds up tests because it saves ~700ms+ for every reset
- whilst this change seems to work, it's just the start so there's a
lot more refactoring needed. this change is currently gated to CI until
it's deemed safe/sane enough to run on local machines without blowing
up
refs https://github.com/TryGhost/Team/issues/1206
- The callout card displays an emoji and a paragraph of text inside a highlighted box.
Co-authored-by:
- Sanne de Vries (@sanne-san)
refs https://github.com/TryGhost/Team/issues/1239
- bumped the mobiledoc-to-html renderer so it doesn't add the `kg-width-wide` class when rendering `aside` sections to `<blockquote>`
refs https://github.com/TryGhost/Toolbox/issues/152
- Have skimmed through the test suites in hopes to find some quick performance wins to bring the runtime speed closer to the one in "main". Haven't been successful to identify major wins, cleaned up a couple of small bits.
- We'll have to live with a tradeoff between maintainability/unified boot VS cost of mainitaining a fake boot process. Imo extra couple seconds of runtime is worth it.
refs https://github.com/TryGhost/Toolbox/issues/152
- Because the root app module was initialized only once per runtime it caused all the express apps to stack on each other causing all sorts of strange behavior when trying to test redirects/vhost mounts etc. Lesson here: be very cautious of how the module is initialized, an explicit function is almost always a better way!
refs 3c7a8dead4
- The tests needed adjustments with the native boot mechanism.
- The number of returned posts changed in the test resutls because duing native boot we also insert fixtures which add to the number of initial posts
- The vhost regression suite is still failing and I had no strength to figure out why. The redirect it fails with makes no sense, the clue here is that the test doesn't fail when running in isolation, so probably has to do with some leftover overrides from the previous test cases.
refs 3c7a8dead4
- The boot process has been using an asyc method to load the routes file, which is the case now for these tests since the switch to raw boot method instead of mimicking it manually
refs 3c7a8dead4
- Simplifies the state initialization code significantly and reuses native boot mechanism instead of mimicking it (it was a headache to maintain with all the internal services moving around)
refs 3c7a8dead4
- The idea is a rip-off from the referenced commit. It allows to isolate initialization logic to "frontend" mounted on top of a "parent"
- Gives path to simplify the express-mock tests
Co-authored-by: Hannah Wolfe <erisds@gmail.com>
refs https://github.com/TryGhost/Toolbox/issues/152
- This stops the mounting of the admin and frontend from being buried deep in express initialisation
- Instead it's explicit, which makes two things almost possible:
1. we can potentially boot the frontend or backend independently
2. we can pass services and settings loaded during boot into the frontend
- This needs more work, but we can start to group all the frontend code together
- Meanwhile we also need to rip apart the routing and url services to decouple the frontend from the backend fully
- BABY STEPS!
Co-authored-by: Hannah Wolfe <erisds@gmail.com>
