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.
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 <jeroen at berkeley.edu> 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. > > ______________________________________________ > R-devel at r-project.org mailing list > https://stat.ethz.ch/mailman/listinfo/r-devel >
On Thu, Jul 23, 2020 at 11:57 PM Simon Urbanek <simon.urbanek at r-project.org> 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.