Some ideas for improving Travis build performance improvements:

[Simon Spero <se...@gmail.com>]

COMPRESS-413 has some examples  which include:

   - Switching to the trusty container, which doesn't require installing as
   many updates.
   - Use only two JDKs: openjdk7 and openjdk8.
      - JDK 7 is obsolete -
      - Oracle EOL'ed JDK7  over two years ago; openjdk7 occasionally gets
      patched (though it's not available from the default source in recent
      versions of ubuntu, including xenial (16.0.4), which is the current LTS.
      - Java 7 is mostly relevant only for older versions of Android. Some
      JLS 8 features are not supported for versions of Android prior
to 7.0 (e.g.
      Repeatable annotations, and interface default/ static methods).  However,
      this environment is not tested for under oracle or openjdk 7.  It's also
      painful to build for under maven.
   - Run the entire CI process in the build phase. This avoids compiling
   and testing two or three times over. However, any errors will fail the
   build.
   - Cache build dependencies (this is another reason to move plugin work
   to the build phase, since the cache is saved before after_success is run).
   - Add a mvnw setup. 3.5.0 may be  needed if jdk9ea is added to the build
   matrix.
   - The pull request also has random test coverage increases to pacify a
   confused coveralls.

See: https://github.com/apache/commons-compress/pull/39

which combined with previous changes from~

 Ran for 5 min 4 sec
 Total time 13 min 26 sec

to:

 Ran for 1 min 56 sec
 Total time 1 min 50 sec


[Note that some variation comes from primed/unprimed caches]

Re: Some ideas for improving Travis build performance improvements:

[Stefan Bodewig <bo...@apache.org>]

Hi Simon et al

I'm not sure what we are using Travis CI for in the first place. Maybe
we can minimize build time by reducing the build to the utter minimum
required to achieve that - whatever that is?

Honestly I don't see anything we couldn't do with our Jenkins
installation as well. Maybe having Coveralls for pull requests, but
that's it (and Coveralls itself seems to produce random ups and downs
occasionally).

Stefan

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org