-
Notifications
You must be signed in to change notification settings - Fork 3.7k
[ci] Break out test steps for Hexagon / microTVM #10946
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
Conversation
| label: 'Run Hexagon tests', | ||
| ) | ||
| sh ( | ||
| script: "${docker_run} ${ci_hexagon} ./tests/scripts/task_python_hexagon_simulator.sh", |
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.
I'm not sure if it's doable, but this step can run in parallel with the step at line 766.
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.
We could especially now that we're installing GNU parallel onto the Docker images, but only the longest step really matters so we don't have to mess with this unless we get the CPU/GPU tests under 30 minutes or so
ccbc5a9 to
73a65e1
Compare
|
@kparzysz-quic any objection to this one going in? |
fcd37f1 to
e24795a
Compare
Since we gate all tests on all builds currently in Jenkins, the longest running build is a bottleneck for overall runtime. This moves them to their own test steps so that the longer-running GPU/CPU tests can start earlier. This should shave off another 30 minutes or so of CI time. As a follow up we can investigate per-platform parallelism, e.g. the CPU tests only wait on the CPU build, but Jenkins doesn't have good support for this so we might have to work on the UX a bit first.
Since we gate all tests on all builds currently in Jenkins, the longest running build is a bottleneck for overall runtime. This moves them to their own test steps so that the longer-running GPU/CPU tests can start earlier. This should shave off another 30 minutes or so of CI time. As a follow up we can investigate per-platform parallelism, e.g. the CPU tests only wait on the CPU build, but Jenkins doesn't have good support for this so we might have to work on the UX a bit first. Co-authored-by: driazati <[email protected]>
Since we gate all tests on all builds currently in Jenkins, the longest running build is a bottleneck for overall runtime. This moves them to their own test steps so that the longer-running GPU/CPU tests can start earlier. This should shave off another 30 minutes or so of CI time. As a follow up we can investigate per-platform parallelism, e.g. the CPU tests only wait on the CPU build, but Jenkins doesn't have good support for this so we might have to work on the UX a bit first. Co-authored-by: driazati <[email protected]>
Since we gate all tests on all builds currently in Jenkins, the longest running build is a bottleneck for overall runtime. This moves them to their own test steps so that the longer-running GPU/CPU tests can start earlier. This should shave off another 30 minutes or so of CI time.
As a follow up we can investigate per-platform parallelism, e.g. the CPU tests only wait on the CPU build, but Jenkins doesn't have good support for this so we might have to work on the UX a bit first.
cc @areusch