[Bioperl-l] Travis CI build improvements

[Fields, Christopher J]

On 4/20/17, 3:00 PM, "Zakariyya Mughal" <zaki.mughal at gmail.com> wrote:

    On 2017-04-18 at 15:24:25 +0100, Peter Cock wrote:
    > On Tue, Apr 18, 2017 at 2:39 PM, Fields, Christopher J
    > <cjfields at illinois.edu> wrote:
    > >     On Mon, Apr 17, 2017 at 6:50 PM, Zakariyya Mughal <zaki.mughal at gmail.com> wrote:
    > > …
    > >     > As for the tests that require the network or optional dependencies, it
    > >     > is possible to enable different builds conditionally. I believe the best
    > >     > approach for the ones that require networking would be to create a
    > >     > special branch that enables those tests. This branch can just be rebased
    > >     > off the current master branch whenever a new release is uploaded.
    > >     >
    > >     > Regards,
    > >     > - Zakariyya Mughal
    > >
    > >     That's an interesting idea about running the online tests only on
    > >     specific branches. Biopython tries to run our online tests weekly
    > >     via buildbot, and this is part of our (time consuming) release
    > >     process (final run of full test suite on the release manager's own
    > >     machines).
    > >
    > >     Peter
    > >
    > > We did this with the 1.6.x branch for a while, as it was diverging more
    > > and more from the master branch (this was also at a point where we
    > > started cleaving out none-core-like modules) but we wanted to keep
    > > testing it.   IIRC we can also set up travis to run with specific env.
    > > variables on or off for a particular environment, which can then be
    > > used to trigger additional optional tests (similar in respects to Dist::Zilla’s
    > > release-only or author tests).   The downside is this would be triggered
    > > every commit, which we don’t really want.  So, using a branch is a
    > > much simpler, elegant solution (test only upon merge).
    > >
    > > chris
    > 
    > There is also the new cron option in TravisCI, which might be useful
    > here - e.g. set a weekly TravisCI job and use the environment
    > variable $TRAVIS_EVENT_TYPE == 'cron' as a flag to trigger
    > the full test mode rather than off-line only tests.
    > 
    > https://docs.travis-ci.com/user/cron-jobs/
    > https://github.com/travis-ci/beta-features/issues/1
    > 
    > As a downside this could make coverage plots harder to interpret
    > as some commits should get higher coverage than others...
    > 
    > Peter
    
    I could give this a try. If the cron builds are only run on a single
    branch, then only looking at that single branch should remain consistent
    modulo any network outages.
    
    Cheers,
    - Zaki Mughal

That works for me, and if anything it could help raise a flag with modules relying on remote services that go away (this has been a pretty common issue)

chris