[Rd] Experimental CI tool for R

[Jeroen Ooms]

On Thu, Jul 23, 2020 at 11:57 PM Simon Urbanek
<simon.urbanek using 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.