-
Notifications
You must be signed in to change notification settings - Fork 107
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Split up test jobs so that they can be run concurrently #1056
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice!
Not sure why this can’t be merged; something about needing all required statuses? |
@paulrobertlloyd yeah, will need an admin to update the branch protection rules, removing the requirement for the current general “Pull request” job to pass and instead adding the 4 new ones. @roshaanbajwa is this something you could do? Also be good to check if the names for all 4 jobs make sense? I wasn’t sure if “JavaScript unit test” and “Visually regression tests” were the right terms or not? |
Possibly the overall workflow should be renamed from “Pull request” too? The names only affect the interface I think, but given these tests will also all run if any internal or outside new contributors open a pull request, the less confusing they are the better? (Although we can also help anyone who gets stuck) |
Seems very sensible to me 👍 @roshaanbajwa is on leave now but I'm sure we can get this checked and merged on his return. |
@anandamaryon1 @roshaanbajwa the settings should be on this page: https://github.com/nhsuk/nhsuk-frontend/settings/branches under 'branch protection rules'. |
Currently all the tests run one after each other, taking just under 5 minutes in total.
Aim here is to run them concurrently, which should roughly half the time it takes to run them all (slowest one is visual regression tests which take about 2.5 mins).
In addition they’ll all get reported on the PR separately, which should make it easier to quickly see which one failed, rather than having to dig into the actions log to work it out.
Before
After