[Bioperl-l] Travis CI build improvements

[Zakariyya Mughal]

On 2017-04-20 at 21:12:20 +0000, Fields, Christopher J wrote:
> 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)

I have opened an issue with proposed changes that will make this
possible <https://github.com/bioperl/bioperl-live/issues/224>.

The cron job detects when it is being run as a cron job on a specific
branch (`network-cron-master`) and then tests the code from the
bioperl-live `master` branch.

Cheers,
- Zaki Mughal

> 
> chris
>