Skip to content
This repository has been archived by the owner on May 12, 2021. It is now read-only.

METRON-705: Parallelize the build in travis to the extent that is obvious #444

Closed
wants to merge 16 commits into from

Conversation

cestella
Copy link
Member

@cestella cestella commented Feb 7, 2017

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.

@ottobackwards
Copy link
Contributor

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?

@mmiklavc
Copy link
Contributor

mmiklavc commented Feb 7, 2017

@ottobackwards Yes, that should do it.

@cestella
Copy link
Member Author

cestella commented Feb 7, 2017

Yep, that's how I did it. You can see a build of it on my account here

@ottobackwards
Copy link
Contributor

I'm doing it now

@ottobackwards
Copy link
Contributor

ottobackwards commented Feb 7, 2017

https://travis-ci.org/ottobackwards/incubator-metron/builds/199370356

#14 passed

Elapsed time 43 min 10 sec
Total time 1 hr 6 min 21 sec

@ottobackwards
Copy link
Contributor

ottobackwards commented Feb 7, 2017

integration tests took 43 minutes

@cestella
Copy link
Member Author

cestella commented Feb 7, 2017

Wow, that's interesting @ottobackwards ; seems like this is very variable. Could you run it again and see if it's consistent?

@cestella
Copy link
Member Author

cestella commented Feb 7, 2017

Looking at those logs, it appears that the first phase, the build (not the actual integration tests) is 4 minutes 39 seconds in my integration-test phase build on travis vs 21 minutes 53 seconds on yours

@ottobackwards
Copy link
Contributor

you bet.... btw -the build on this pr isn't even going at all

@cestella
Copy link
Member Author

cestella commented Feb 7, 2017

@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.
@cestella
Copy link
Member Author

cestella commented Feb 7, 2017

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:

  • parallelize the package phase
  • parallelize the unit test phase
  • run the integration tests in serial

@cestella
Copy link
Member Author

cestella commented Feb 7, 2017

Also, with only 30 parallel builds available across all apache projects, asking for 2 separate containers per build might be greedy. ;)

@ottobackwards
Copy link
Contributor

#14.1 passed

Elapsed time 23 min 28 sec
On my second try around 5pm

@cestella cestella closed this Feb 8, 2017
@cestella cestella reopened this Feb 8, 2017
@cestella
Copy link
Member Author

cestella commented Feb 8, 2017

I reran this 7 times on my travis account for the most recent commit and the times were on average 32 minutes 53 seconds

  • 28m 17s
  • 28m 13s
  • 46m 28s
  • 35m 53s
  • 26m 26s
  • 33m 0s
  • 31m 57s

build_times

@justinleet
Copy link
Contributor

+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

@asfgit asfgit closed this in 80b8aee Feb 21, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
4 participants