Draft: Split backend code tests into separate jobs per suite
Closes #____ (e.g. #230 (closed))
What does this MR do?
Currently, the backend-code test job takes roughly 25 minutes in total.
While the total pipeline's runtime won't be affected much (backend-acceptance takes longer than -code), time until any test fails will be much shorter.
For example, if a unit test is going to fail, that will happen after roughly 20 minutes, because these run after all the API tests. Running these two suites in parallel means failing unit tests will be visible much faster.
Worse for flaky tests (like testTriggerFetchWarningNotificationWithMixedPickups, which i highly suspect is flaky: !3199 (merged)), you need to wait 25 minutes every time to roll the dice and see whether it failed again this time.
Also, because the -code job runs on Gitlab runners, they won't affect each other's performance. One concern is that this will slightly increase the CI minutes we use (due to duplicated setup work), but I don't think this is a serious problem with the amount of minutes we are allocated as an OSS project.
How confident are you it won't break things if deployed?
Links to related issues
How to test
Screenshots (if applicable)
Checklist
-
added a test, or explain why one is not needed/possible... -
no unrelated changes -
asked someone for a code review -
set a "for:" label to indicate who will be affected by this change -
added to the next milestone (see https://gitlab.com/foodsharing-dev/foodsharing/-/milestones, unless it has a "for:Dev" label) -
added an entry to CHANGELOG.md -
added a short text in the release notes to /release-notes/YYYY-MM.md -
Once your MR has been merged, you are responsible to create a testing issue in the Beta Testing forum: https://foodsharing.de/region?bid=734&sub=forum. Please change the MRs label to "state:Beta testing". - Consider writing a detailed description in German.
- Describe in a few sentences, what should be tested from a user perspective.
- Also mention different settings (e.g. different browsers, roles, ...) how this change can be tested.
- Be aware, that also non technical people should understand.