[ 
https://issues.apache.org/jira/browse/COMPRESS-413?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16063215#comment-16063215
 ] 

ASF GitHub Bot commented on COMPRESS-413:
-----------------------------------------

Github user sesuncedu commented on the issue:

    https://github.com/apache/commons-compress/pull/43
  
    Travis has some nice properties, especially when working with forks. It's 
very easy to enable travis for a fork, so CI can be done before a PR goes in.
    
     Travis can also run really quickly, but only when tuned properly, and when 
the system is not running at capacity. If the stars are aligned, you can get 
every job in a big 'ol  matrix running in parallel (each container build gets 2 
cores and max 4GB of memory), which is  nice if they're free.  The critical 
thing is to be using the container environments and not the VM, as the startup 
time is tiny.  The annoying thing about Travis is that the default environment 
is running Ubuntu 12.04, which is well past its LTS date. The trusty (14.04) 
container is *still* marked as beta, despite being on a production level update 
cycle (set group to edge for that real beta experience). The 12.04 containers 
all have to do a lot of package replacement on startup, which takes away some 
of the benefits of having a container ). I kept the home server on 12.04 until 
the end of LTS because Travis, then went  to xenial (16.04) which is the 
current LTS, and has nice things like proper zfs (hey- an apache connection). 
    
    Hudkins farms in my mental model usually seem to be more congested, but 
there are good reasons not to believe that. 
    



> Travis build redundantly repeats compilation and tests redundantly
> ------------------------------------------------------------------
>
>                 Key: COMPRESS-413
>                 URL: https://issues.apache.org/jira/browse/COMPRESS-413
>             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 with 
> 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
(v6.4.14#64029)

Reply via email to