Re: Travis CI build improvements

On Tue, Apr 18, 2017 at 2:39 PM, Fields, Christopher J
<[email protected]> wrote:
>     On Mon, Apr 17, 2017 at 6:50 PM, Zakariyya Mughal <[email protected]> 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

_______________________________________________
Bioperl-l mailing list
[email protected]
http://mailman.open-bio.org/mailman/listinfo/bioperl-l