METRON-705: Parallelize the build in travis to the extent that is obvious #444
Conversation
So to test this - if you have travis set up for your git account, I think you just push it to a branch in your repo and let travis build it? |
@ottobackwards Yes, that should do it. |
Yep, that's how I did it. You can see a build of it on my account here |
I'm doing it now |
https://travis-ci.org/ottobackwards/incubator-metron/builds/199370356 #14 passed Elapsed time 43 min 10 sec |
integration tests took 43 minutes |
Wow, that's interesting @ottobackwards ; seems like this is very variable. Could you run it again and see if it's consistent? |
you bet.... btw -the build on this pr isn't even going at all |
@ottobackwards Yeah, we have to use the apache job queue (which has 30 parallel builds) on travis rather than the big one for all open source projects. I suspect it gets slammed during the day. |
…he modest gains of just parallelizing the build and unit test run and serializing the integration test run.
Ok, this was just too volatile. I also got 43 minutes for the integration test run. It's probably worth investigating in the future, but for now I'm going to revert to just one container:
|
Also, with only 30 parallel builds available across all apache projects, asking for 2 separate containers per build might be greedy. ;) |
#14.1 passed Elapsed time 23 min 28 sec |
+1, I was able to run this up in Travis setup on my repo without issue and it ran right in the middle of the time range listed |
Travis suggests here that for situations where the integration get chunky, one can parallelize them using their build matrix functionality. Also, if we can separate those out, we can also process-parallelize the unit and build.
Currently the build time is cut roughly in half to 24 minutes wall-clock.
NOTE: This is just a stopgap that requires no code changes to lower build wall-clock times. This is not intended to replace work parallelizing the integration tests or making the build take less time.