[Bioc-devel] Wishlist: on demand R CMD check

[Jim Hester]

Kasper,

You can set this up yourself using a combination of Travis-CI
<http://docs.travis-ci.com/user/languages/r/> (for linux and OSX) and
Appveyor <http://www.appveyor.com/> (for Windows). The R integration for
Travis is now build in, however for Appveyor you will need to use the
r-appveyor <https://github.com/krlmlr/r-appveyor> project by Kirill Müller.

An example .travis.yml file to setup Travis-CI would be

language: r
sudo: required
bioc_required: true
bioc_use_devel: true

Travis’ default builds are Ubuntu 12.04, however there is also experimental
support for OSX <http://docs.travis-ci.com/user/multi-os/> as well. However
I have not personally tried doing an OSX build on Travis, so I cannot vouch
that it is fully functional.

Travis sometimes take a while to move through the queue, but it is still
much faster than waiting for the build report, Appveyor seems to be under
less load, so usually builds there start nearly instantly.

A example appveyor.yml file for Bioconductor packages can be found at
https://gist.github.com/jimhester/b071d33464db22c999dc.

Let me know if any of the above is unclear or you have any issues,

Jim

P.S. I sent a previous email of the above using the wrong email account, so
it was not posted to the list, if as a consequence you receive the response
twice I apologize.

On Tue, Jun 2, 2015 at 8:39 AM, Laurent Gatto <lg390 at cam.ac.uk> wrote:

>
> To what extend could the single package builder be used for such a
> feature? This would not address Michael's point, but it is a way to get
> access to all archs using existing software infrastructure.
>
> Laurent
>
> On  2 June 2015 13:18, Michael Lawrence wrote:
>
> > Maybe the motion towards github and the work Gabor C has been doing on
> > Travis integration might help with this?
> >
> > Note that a proper check should test all reverse dependencies of your
> > package, and that would get expensive for some of the more core
> > packages... so that might need to be deferred to the regular
> > repository-level build process.
> >
> >
> > On Tue, Jun 2, 2015 at 2:48 AM, Sean Davis <seandavi at gmail.com> wrote:
> >> On Tue, Jun 2, 2015 at 5:32 AM, Vincent Carey <
> stvjc at channing.harvard.edu>
> >> wrote:
> >>
> >>> I agree that this would be nice; not sure how feasible.  Could a
> specific
> >>> approach with containers provide a solution?
> >>>
> >>
> >> Unfortunately, containers are linux microkernels, so Windows and MacOS
> are
> >> basically out.
> >>
> >>
> >>> On Mon, Jun 1, 2015 at 11:09 PM, Kasper Daniel Hansen <
> >>> kasperdanielhansen at gmail.com> wrote:
> >>>
> >>> > For a substantial number of issues with R CMD check, it is easy to
> >>> > reproduce the errors/warnings/notes on my own system; simply update
> all
> >>> > packages and run the test.
> >>> >
> >>> > For a small number of errors I have sometimes (over the years) had
> >>> problems
> >>> > reproducing them, perhaps because they are platform specific or
> because
> >>> of
> >>> > other issues.
> >>> >
> >>> > In those cases, especially for packages which I work on
> infrequently, the
> >>> > current submission / check introduces a long delay and - more
> >>> importantly -
> >>> > substantial mental overhead for me.  This is because I submit a fix
> and
> >>> > then I usually have to wait 36-48h to see the result of R CMD check.
> >>> >
> >>> > It would be great if we could get access to running R CMD check on
> all
> >>> > three platforms by demand, with a results page which is semi-private
> (to
> >>> > not confuse the package with a fix with the official devel
> version).  I
> >>> > realize this could be misused or introduce a large computational
> overhead
> >>> > on the project.  Perhaps only make this available for packages
> accepted
> >>> > into the project.  But it would be nice.  For example, I have been
> >>> hunting
> >>> > a bug in minfi for like 10 days now, and the fact that I need to
> wait 48h
> >>> > to get the result of a fix, really makes this painful.
> >>> >
> >>> > Best,
> >>> > Kasper
> >>> >
> >>> >         [[alternative HTML version deleted]]
> >>> >
> >>> > _______________________________________________
> >>> > Bioc-devel at r-project.org mailing list
> >>> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >>> >
> >>>
> >>>         [[alternative HTML version deleted]]
> >>>
> >>> _______________________________________________
> >>> Bioc-devel at r-project.org mailing list
> >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >>>
> >>
> >>         [[alternative HTML version deleted]]
> >>
> >> _______________________________________________
> >> Bioc-devel at r-project.org mailing list
> >> https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >
> > _______________________________________________
> > Bioc-devel at r-project.org mailing list
> > https://stat.ethz.ch/mailman/listinfo/bioc-devel
>
> --
> Laurent Gatto | @lgatt0
> http://cpu.sysbiol.cam.ac.uk/
>
> _______________________________________________
> Bioc-devel at r-project.org mailing list
> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>

	[[alternative HTML version deleted]]