Hi Junio, On Wed, 23 Jan 2019, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget" <gitgitgad...@gmail.com> > writes: > > > From: Johannes Schindelin <johannes.schinde...@gmx.de> > > > > Let's not decide in the generic ci/ script how many jobs to run in > > parallel; it is easy enough to hand that information down via the > > `MAKEFLAGS`. > > > > Signed-off-by: Johannes Schindelin <johannes.schinde...@gmx.de> > > --- > > ci/run-build-and-tests.sh | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/ci/run-build-and-tests.sh b/ci/run-build-and-tests.sh > > index db342bb6a8..80d72d120f 100755 > > --- a/ci/run-build-and-tests.sh > > +++ b/ci/run-build-and-tests.sh > > @@ -7,7 +7,7 @@ > > > > ln -s "$cache_dir/.prove" t/.prove > > > > -make --jobs=2 > > +make > > make --quiet test > > if test "$jobname" = "linux-gcc" > > then > > As there is no assignment to MAKEFLAGS in this patch, is it intended > for this step to change behaviour (possibly with the intention to > add "default 2 jobs at least under travis" back later in the > series)? Not that it matters too much, but it is unnerving to see > that the proposed log message promising "it is easy enough" while > not actually doing so, without expressing an intention. I was under the incorrect impression that Travis already configured a MAKEFLAGS=--jobs=<n> by default (I got fooled by the GIT_PROVE_OPTS setting that configures that --jobs option). But the spirit of the change is still correct, I would think, so I made the change more complete by actually setting MAKEFLAGS in the CI-specific sections, and by removing the explicit --jobs=2 parameters in the scripts. Ciao, Dscho
