search

gitgitgadget / git

GitGitGadget's Git fork. Open Pull Requests here to submit them to the Git mailing list
https://gitgitgadget.github.io/
Other
212 stars 133 forks source link

Split the `linux-gcc` in our CI builds into two separate jobs #242

Open dscho opened 5 years ago

dscho commented 5 years ago

The linux-gcc job is a bit overloaded: it actually runs the test suite twice. Once with regular options, and once after setting all kinds of GIT_TEST_* options.

Since the running time is dominated by the test suite, not by the build, it would make more sense for those two runs to be run in parallel.

Therefore, let's split linux-gcc into two: a regular one, and on with all the extra options.

webstech commented 5 years ago

Is this a split in azure or a split in make? If the desire is to use make to run the test suites in parallel I can look at that. There are test output location issues and success finalization issues to be resolved. There may be similar issues with azure but am not familiar with them.

dscho commented 5 years ago

Whoops, I should have mentioned that I started work on this here: https://github.com/gitgitgadget/git/pull/266 (see especially the discussion in https://public-inbox.org/git/pull.266.git.gitgitgadget@gmail.com/ for enlightenment about the reluctance to accept this).

webstech commented 5 years ago

Sorry, I had missed your PR. I played with a make implementation about the same time (just got around to asking about the issue and did not review the PRs).

The upside of make is a single build of git but that does not sound like the bottleneck. Using parallel make also makes it easier for devs to just run make (all the special vars are target specific vars). The downside of parallel make is figuring out the error when it fails but make has really improved on that by removing the interleaving of the output of the parallel jobs. Too bad about the push back - faster builds are in everyone's interest.