Experimental CI tool for R

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Experimental CI tool for R

Jeroen Ooms-2
Based on ideas from the R-core discussion panel at useR2020, I created
a little CI tool to make it easier to follow changes in R-devel, and
to write/test patches for R.

The tool is based on a Github mirror of the SVN, where each new commit
triggers a full make-check on 8 different system configurations. The
results are published on: https://r-devel.github.io which gives an
overview of the most recent revisions, including links to the build
logs, and a link to the (unsigned) Windows installer. As of yesterday,
it should be possible to inspect the build logs without signing in to
GitHub.

The system can also be used to develop and test patches for base-R.
Anyone can send pull-requests, which will trigger the same set of
builds. The check results and link to Windows installer will appear
under your pull request. Finally, GitHub makes it very easy to export
a pull request as a patch file, which is the format that R-core
members still like to use. More instructions are available on:
https://github.com/r-devel/r-svn#readme

I hope this tool can make cross-platform testing and contributing of
base-R slightly less painful, while we are still on SVN.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Experimental CI tool for R

Simon Urbanek
Jeroen,

This is great! It is definitely a good basis to build on.

However, I wonder why your macOS setup is so extremely stripped down (not even Cairo, tcltk nor X11 - and not TeX, either) and as far from what we actually use as possible (using gcc instead of clang, openblas etc.).

How do you plan to go about managing the build flavors? I think it would be great if there was a process whereby the builds could be updated so they are more realistic and thus more helpful, but since the repo is completely anonymous, it's unclear how one would go about that nor how it would be governed (and where to put documentation). For obvious reasons the Windows one is the only complete one, but given the requests for Homebrew-based package testing (independent of CRAN) it would be useful to publish the artefacts as well so that they could be used by GH action workflows for packages. Cleary we could just fork it, but I guess it would make more sense if this was a coordinated effort.

Cheers,
Simon


> On Jul 21, 2020, at 23:55, Jeroen Ooms <[hidden email]> wrote:
>
> Based on ideas from the R-core discussion panel at useR2020, I created
> a little CI tool to make it easier to follow changes in R-devel, and
> to write/test patches for R.
>
> The tool is based on a Github mirror of the SVN, where each new commit
> triggers a full make-check on 8 different system configurations. The
> results are published on: https://r-devel.github.io which gives an
> overview of the most recent revisions, including links to the build
> logs, and a link to the (unsigned) Windows installer. As of yesterday,
> it should be possible to inspect the build logs without signing in to
> GitHub.
>
> The system can also be used to develop and test patches for base-R.
> Anyone can send pull-requests, which will trigger the same set of
> builds. The check results and link to Windows installer will appear
> under your pull request. Finally, GitHub makes it very easy to export
> a pull request as a patch file, which is the format that R-core
> members still like to use. More instructions are available on:
> https://github.com/r-devel/r-svn#readme
>
> I hope this tool can make cross-platform testing and contributing of
> base-R slightly less painful, while we are still on SVN.
>
> ______________________________________________
> [hidden email] mailing list
> https://stat.ethz.ch/mailman/listinfo/r-devel
>

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
Reply | Threaded
Open this post in threaded view
|

Re: Experimental CI tool for R

Jeroen Ooms-2
On Thu, Jul 23, 2020 at 11:57 PM Simon Urbanek
<[hidden email]> wrote:
>
> This is great! It is definitely a good basis to build on.
> I wonder why your macOS setup is so extremely stripped down (not even Cairo, tcltk nor X11 - and not TeX, either) and as far from what we actually use as possible (using gcc instead of clang, openblas etc.).
> How do you plan to go about managing the build flavors? I think it would be great if there was a process whereby the builds could be updated so they are more realistic and thus more helpful, but since the repo is completely anonymous, it's unclear how one would go about that nor how it would be governed (and where to put documentation).

Thanks for having a look at this.

Build scripts for GitHub actions are always stored in the workflows
directory in the same repository. The build-svn.yaml file contains the
commands used to prepare the server and build R on each of the
platforms. Here you can easily enable/disable features, or add another
flavor. In the same way you can test patches, you can use pull
requests to suggest changes to the build matrix. I have also added a
note about this in the readme.

On MacOS currently indeed we test a minimal configuration which
matches homebrew:
https://github.com/homebrew/homebrew-core/blob/master/Formula/r.rb#L35-L47
. The main reason is to minimize random build failures that we were
getting when downloading xquartz and mactex during the build process
(these are not preinstalled on the GHA builders, anc MacTex).

It would be great if you can help with adding a flavor to build a
cran-like MacOS installer.


> For obvious reasons the Windows one is the only complete one, but given the requests for Homebrew-based package testing (independent of CRAN) it would be useful to publish the artefacts as well so that they could be used by GH action workflows for packages. Cleary we could just fork it, but I guess it would make more sense if this was a coordinated effort.

Of course, 100% agree this should be a coordinated effort.  Ideally we
hope some modern tooling can be adopted upstream, as for most other
open source projects, where CI is a standard part of the development
process, such that cross-platform building and testing is automated
and transparent.

______________________________________________
[hidden email] mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel