commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Amey Jadiye <ameyjad...@gmail.com>
Subject Re: [all/travis-ci] Regarding potential Travis-CI solutions
Date Fri, 04 Aug 2017 18:56:20 GMT
Hi,

Yes we are giving up the simplicity of travis but I see some advantages
over it, all of them are listed in my previous mail, let me try to put them
again.

1. Travis provides very limited JDK at this point [1] and travis builds can
become more flexible and we will have more control over the different
flavours, versions and vendors of jdk we wants to use with travis build
process.

2. Travis is very slow providing the different versions of jdk ATM. they
don't have  ibmjava8 not sure when ibmjava9 will be there ?

3. Complexity of file is limited to just one parent file, and its very
generalised so we still have options to choose which jdk we want.

4. Script can contain specific version of stable  JDK we want this gives
more control to us for quickly updating next minor version rather waiting
for Travis.

5. Other thing I'm proposing is to have this script as .travis.parent.sh and
we can keep it somewhere centralised http location and wget it and execute
from .travis.sh so core logic will have to maintain at single place, change
will be only in respective .travis.yml.

This script is modified kepping in mind that this will be usefull to all
Commons components for their own specific needs and not onyl for text, Text
is just test project. Even I don't want EA to be the part of script, I was
just trying different options if anyone wants.

Ex. for text I will have only below environment.

env:
  - JDK=7
    vendor=oracle
  - JDK=7
    vendor=open
  - JDK=8
    vendor=oracle
  - JDK=8
    vendor=open
    ECJ=true
  - JDK=8
    vendor=ibm
  - JDK=9
    vendor=oracle
  - JDK=9
    vendor=ibm

[1]. https://docs.travis-ci.com/user/languages/java/

Regards,
Amey

On Fri, Aug 4, 2017 at 11:44 PM, Benedikt Ritter <britter@apache.org> wrote:

> I agree with Pascal. It's better to use Travis build in stuff. When IBM Jdk
> really become available, that would be quite nice, because that tends to
> cause failures. Regarding EA builds, I think it's good enough to test
> releases against them. Since EA builds may have regressions, this could
> lead to unstable builds. That's why I wouldn't make them part of my CI.
>
> Regards,
> Benedikt
>
> Pascal Schumacher <pascalschumacher@gmx.net> schrieb am Fr. 4. Aug. 2017
> um
> 18:20:
>
> > Hello everybody,
> >
> > let me add some detail to what I mean by hard to maintain.
> >
> > The scripts contains links to specific jdk versions:
> >
> >
> > http://download.java.net/java/jdk9/archive/178/binaries/jdk-
> 9+178_linux-x64_bin.tar.gz
> >
> > http://download.java.net/java/jdk9/archive/178/binaries/jdk-
> 9+178_linux-x64_bin.tar.gz
> >
> > http://download.java.net/java/jdk8u152/archive/b05/binaries/
> jdk-8u152-ea-bin-b05-linux-x64-20_jun_2017.tar.gz
> >
> > http://public.dhe.ibm.com/ibmdl/export/pub/systems/
> cloud/runtimes/java/8.0.4.7/linux/x86_64/ibm-java-sdk-8.0-
> 4.7-x86_64-archive.bin
> >
> > These have to be updated regularly, because what good is it to test
> > against yesterdays EA versions? (They actually are already out of date
> :().
> >
> > Commons-text just uses a very stable and small parts of the jdk so I do
> > not think it is very likely that something will break on a different
> > variant.
> >
> > There is also a pull request to add the ibm jdk to travis:
> > https://github.com/travis-ci/travis-cookbooks/pull/874 and a travis
> > employee promised to take a look soon. So maybe travis will support the
> > ibm jdk out of the box soon.
> >
> > Cheers,
> > Pascal
> >
> > Am 03.08.2017 um 23:32 schrieb Rob Tompkins:
> > > Hello all,
> > >
> > > We have an open pull request from Amey (
> > https://github.com/apache/commons-text/pull/61 <
> > https://github.com/apache/commons-text/pull/61>) proposing a fairly
> > complicated but quite nice travis-ci build solution (taken from the
> jacoco
> > project) that accommodates building on JDK7, JDK8, JDK8-ea, EclipseJava,
> > JDK9-ea, as well as IBMJava-8. To accommodate building on all of these
> > different versions of Java, we do however need to make the travis-ci
> build
> > a good deal more complex.
> > >
> > > As the two reviewers on the pull request, Pascal and myself, have
> mildly
> > differing opinions on the complexity-value trade off here, with Pascal’s
> > opinion being: "…[T]his is overkill. I don't think commons-text needs to
> be
> > tested against the eclipse java compiler and early access versions of
> java
> > 8 and 9. The script looks difficult to debug and maintain.” And my
> > perspective is that this could be a test piece for using this elsewhere
> in
> > commons.
> > >
> > > To me, the argument for simplicity is always quite compelling, to the
> > point that I’m mostly willing to let go of using the jacoco travis-ci
> > pattern. But I figured I would, before making any decisions, see what the
> > community thinks generally about this possible travis-ci build script.
> > >
> > > Cheers,
> > > -Rob
> >
> >
> >
>



-- 

---------------------------------------------------------------------

To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org

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

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message