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
Travis Build Stages + Docker Repository #573
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #573 +/- ##
==========================================
Coverage ? 85.17%
==========================================
Files ? 81
Lines ? 2206
Branches ? 266
==========================================
Hits ? 1879
Misses ? 261
Partials ? 66 Continue to review full report at Codecov.
|
… to be disabled if necessary.
Currently using travis stages for parallalisation of tasks, but it should be noted that having to start the system each time adds roughly ~12 minutes to the total time taken. |
Possibly chopped off 4~8 minutes looking at previous build (although the trend upwards before failed builds was quite rapid). |
@JackMorganNZ I think what I wanted to do here is done. Not sure this fixes the problem might be worth turning off resource generation tests off unless it is a pull request (example line is in csu waiting to be uncommented). I found that resource generation tests take about ~8 minutes on my machine and considering they are essentially run again at deployment to make all the variants that is a significant portion of time. I haven't attempted anything here to speed up deployment scripts. |
Would you be able to explain this more, don't quite get it sorry:
|
@JackMorganNZ if you look at the travis build history a while ago the builds were about 10 minutes, then recently they quickly sped up to about 20+ minutes just before develop broke. I think the new resources are causing a (mild) kind of state explosion increasing the build times drastically. |
Locks the python version #203
Uses base images to reduce build time #231
Fixes csu script to ensure correct status code for backward testing #425
Attempts to address maximum timeouts #572