commons-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (COMPRESS-413) Travis build redundantly repeats compilation and tests redundantly
Date Sat, 24 Jun 2017 15:31:02 GMT


ASF GitHub Bot commented on COMPRESS-413:

Github user bodewig commented on the issue:
    Thanks Simon.
    TBH I'm not too sure why we've got Travis builds at all, probably so we can run Coveralls.
I'll leave this request open for those more interested in the Travis CI setup. I'll rather
invest some time in adding a Jenkins matrix build for the JDKs we want to support instead.
    Commons Compress aims to be compatible with Java7, no matter how old or deprecated, but
we already cover that with Jenkins - the pull request builder over there uses Oracle JDK 7,
so we've got that covered independent of Travis CI. We do run SonarQube for Compress already.
    Personally I dislike `mvnw` scripts, but this is probably a matter of taste. I won't veto
its introduction.
    Please strip the changes to `AsiExtraField` from this PR, they are completely unrelated.

> Travis build redundantly repeats compilation and tests redundantly
> ------------------------------------------------------------------
>                 Key: COMPRESS-413
>                 URL:
>             Project: Commons Compress
>          Issue Type: Improvement
>          Components: Build
>    Affects Versions: 1.14
>         Environment: Travis
>            Reporter: Simon Spero
>            Priority: Minor
>              Labels: CI
>             Fix For: 1.15
>   Original Estimate: 0h
>  Remaining Estimate: 0h
> The Travis build setup is suboptimal.
> At the moment, code is compiled and installed by the default install phase.  
> Then the default build phase is executed, which compiles and runs the tests.
> If the tests succeed, then the build is cleaned, recompiled, and retested; this time
> coverage enabled. 
> The .travis.yml file could be changed to skip the install phase, and to run tests with
coverage during the build phase. 
> The coveralls plugin can be configured in the pom  to not fail the build if the service
is unreachable, so forks that don't have jacoco enabled won't always have their builds fail.

> Also, the jdk switching in the trusty container seems to be not working properly at the
moment, so installing a jdk7 doesn't work properly.
> These changes evolved as I was poking jenkins last night.

This message was sent by Atlassian JIRA

View raw message