Update CI macos fall back value

[cgiachalis]

Running on initial failures in #844, I discovered that macos ci uses an outdated R version: v4.4.1 vs current v4.5.1.

That's because the macos CI uses an environment variable RVER to select the R version with fallback value "4.4.1". This pull request updates the fallback value to "4.5.1" and ensures that the specific job is not failing fast. Also, I tweaked the include field so you can transparently pass the R version for macos to environment variable RVER.

At a later point, you could automate the current release of macos installer via R-Hub endpoint:

• https://api.r-hub.io/rversions/r-release-macos or API docs here

cc @ihnorton , @mojaveazure

[jdblischak]

This is slightly confusing since RVER has no effect on the Ubuntu builds. For example, someone might try changing it to '4.5.0' or 'devel', and would be surprised that this had no effect. I assume you did this in order to inject the R version in to the name below. I'm not strongly opposed to this strategy, but I wonder if there is an alternative mechanism.

[cgiachalis]

I assume you did this in order to inject the R version in to the name below.

Exactly.

[cgiachalis]

The alternative would be to modify r-ci.sh , i.e., query the API https://api.r-hub.io/rversions/r-release-macos and if we get other than 200 code let it default to fallback value.

[mojaveazure]

Thanks for catching @cgiachalis!

but I wonder if there is an alternative mechanism.

I would say the best alternative mechanism would be to replace r-ci.sh with r-lib/actions as we did in single-cell-data/TileDB-SOMA#4156 and for pkgdown deployments here in #802; these actions are tested and widely-used across the R community, and would allow us to use the more standard names of "release" or "devel" when specifying R versions to test on. This is not a priority for us at the moment, but will likely be where the CI for TileDB-R evolves to

[cgiachalis]

Thanks @mojaveazure!