Possible breaking changes to macos-latest runner for older versions of R

[mdneuzerling]

Hi folks,

I've noticed some builds starting to fail that were previously fine, and I think it may be due to a breaking change being rolled out to the macos-latest image. The image is being upgraded to Big Sur starting from September 15th, with the migration intending to be completed by November 3rd. See the relevant issue, which notes that "R was not available for Big Sur when we prepared the image for the first time."

We can force a particular OS with macos-10.15 or macos-11. Here's a summary of success/failure with build links:

• Successful build for R 4.0.5 on macos-10.15
• Failing build for R 3.6.3 on macos-11
• Failing build for R 4.0.5 on macos-11
• Successful build for R 4.1.1 on macos-11

The job I've got is very simple, and doesn't depend on repository contents. It simply sets up R and runs Rscript -e '1+1'.

jobs:
  failing-big-sur-reprex:
    runs-on: macos-11

    steps:
      - uses: actions/checkout@v2

      - name: Set up R 4.0.5
        uses: r-lib/actions/setup-r@v1
        with:
          r-version: '4.0.5'

      - name: Verify Rscript exists
        run: |
          Rscript -e '1+1'

[jimhester]

I don't really see how that particular change could be causing this, we are not relying on the installed R version at all, and the setup-r action worked fine on macOS before they were even including R in the pre-built images.

Perhaps something else with the newer environment is causing the issue.

[riccardoporreca]

@jimhester, I looked at this more in detail, working on a fork of @mdneuzerling's repo for a minimal example running a matrix of (macOS, R) combinations for convenience.

See https://github.com/riccardoporreca/parity/actions/workflows/metaflow-reprex.yaml?query=branch%3Ametaflow-reprex, and in particular:

• https://github.com/riccardoporreca/parity/actions/runs/1381632277 for a summary of the failing cases

• https://github.com/riccardoporreca/parity/actions/runs/1382095739 for a minimal set of relevant R versions (4.0 and 4.1), including relevant investigations as follows

  • There is a step called "Where R you?" executed before and after setup-r, showing whether the "R" command is found and listing /usr/local/bin/R* and /Library/Frameworks/R.framework/Resources/bin (if present).

By comparing "Where R you?" in the 4 runs, before and after setup-r, we can see that

• On macOS 10.15, R is installed even before setup-r (as expected, given macOS-latest workflows will use macOS-11 actions/runner-images#4060), with R (similarly Rscript) being /usr/local/bin/R, as a symbolic link to /Library/Frameworks/R.framework/Resources/bin/R. The same setup is preserved after setup-r no matter the R version, which is however installed replacing the installation from before.

• On macOS 11, R is not installed before setup-r (as expected, given macOS-latest workflows will use macOS-11 actions/runner-images#4060). After setup-r, the situation is different depending on the R version

  • For R 4.1, a symlink /usr/local/bin/R exists (created by the installer?) pointing to the newly-installed /Library/Frameworks/R.framework/Resources/bin/R which as such is available as R (through PATH).
  • For R 4.0, R is installed as /Library/Frameworks/R.framework/Resources/bin/R, but no symlink is established under /usr/local/bin/, thus making R not available.

It looks like the installation of R 4.0 (and similarly for 3.6 I guess) does not explicitly establish a symlink under /usr/local/bin/, and works on macOS 10.15 only thanks to symlink from the pre-established R install. On the other hand, the installation of R 4.1 (and devel) does establish the symlink and as such works regardless of a pre-established R installation.

[riccardoporreca]

@mdneuzerling, @jimhester, creating the symbolic links for R and Rscript in a dedicated step after setup-r works around the issue, see riccardoporreca/parity@0fd9ab6 and corresponding successful run https://github.com/riccardoporreca/parity/actions/runs/1402707005

I guess this can be used as the suggested workaround for now in workflows running on macOS-11 (most likely as the new macOS-latest) with R 4.0 or older.

Should this be added to the setup-r implementation, similar to what already in place on Ubuntu?

actions/setup-r/src/installer.ts

Lines 229 to 242 in a39aa4f

	// Add symlinks to the installed R to the path
	//
	//
	try {
	await exec.exec("sudo ln", [
	"-sf",
	path.join("/opt", "R", version, "bin", "R"),
	"/usr/local/bin/R"
	]);
	await exec.exec("sudo ln", [
	"-sf",
	path.join("/opt", "R", version, "bin", "Rscript"),
	"/usr/local/bin/Rscript"
	]);

[t-kalinowski]

I'm running into this as well in the Tensorflow repo. r-lib/actions/setup-r@v1 seems to be failing for me on macOS-latest with R-oldrel. link

[gaborcsardi]

Yes, the reason for this is that the older macOS R installers used to create the symlinks differently, and since Big Sur the old way is not allowed because of Big Sur's tightened security. The newer R installers create the symlinks from a post-install script which works on Big Sur as well.

So we'll need to create the symlinks manually, at least on older R versions, exactly as you say above.

[gaborcsardi]

This is now fixed in the v2 tag.

[github-actions]

This issue has been automatically locked. If you believe you have found a related problem, please file a new issue and include a link to this issue