ci: bring the reusable workflow to development; pin exact R versions

[achubaty]

development never received the reusable-workflow migration — PR #23 was based on and merged into main, so the branch every PR actually targets still runs the old self-managed workflow.

Cherry-picks the migration (f6aa3ef) rather than merging main, because main also carries 34 committed docs/ files that development deliberately does not have.

Three changes

1. R-CMD-check now calls the org reusable workflow — the same file that has been on main since #23.

2. The deep matrix legs are pinned to exact R versions instead of oldrel-N. The oldrel ladder is platform-dependent and not monotone. Resolved against the exact platform string setup-r sends:

ubuntu-latest (noble)      ubuntu-22.04            macOS arm64
oldrel-1 -> 4.5.3          oldrel-1 -> 4.5.3       oldrel-1 -> 4.4.3
oldrel-2 -> 4.4.3          oldrel-2 -> 4.3.3       oldrel-2 -> 4.3.3
oldrel-3 -> 4.3.3          oldrel-3 -> 4.2.3       oldrel-3 -> 4.3.3  dup
oldrel-4 -> 4.1.3  !!      oldrel-4 -> 3.6.3  !!   oldrel-4 -> 4.1.3
oldrel-5 -> 4.1.3  dup     oldrel-5 -> 4.1.3       oldrel-5 -> 4.1.3  dup

r: "4.3" resolves to 4.3.3 identically on Linux, macOS and Windows, and Posit ships noble .debs down to 4.0.5. 4.3 is this package's declared floor (DESCRIPTION: R >= 4.3), which the matrix previously never tested — oldrel-2 stops at 4.4.

3. test-coverage.yaml repointed from install-spatial-deps@v0.2 to @main. Every published tag, v0.1 through v0.5, still runs add-apt-repository -y ppa:ubuntugis/ubuntugis-unstable. That installs libgdal37 while Posit's noble binaries link libgdal34, and the mismatch only surfaces at lazy-load. Only @main dropped it.

Note

main still has the @v0.2 pin in test-coverage.yaml; it catches up at the next release merge.

🤖 Generated with Claude Code

[achubaty]

Correction: the oldrel-N table in the description is wrong

I need to correct the evidence I gave. The mapping table above does not reproduce. Re-tested across ~4,500 requests — sequential, concurrent, cold-key — every platform currently returns the clean sequence:

linux-ubuntu-24.04:  oldrel/1..7 -> 4.5.3, 4.4.3, 4.3.3, 4.2.3, 4.1.3, 4.0.5, 3.6.3
linux-ubuntu-22.04:  identical
mac / win:           identical

So oldrel-4 does resolve to 4.2.3 on noble today, and my claim that "R 4.2 is unreachable by any oldrel index" was not the steady state. Sorry — I reported a snapshot as if it were the behaviour.

What is actually wrong, and why this PR still stands

The readings I saw were real, but they were stale cache responses, and the underlying bug is worse than a bad mapping.

The resolver behind setup-r is r-hub/rversions.app. In lib/cache.js, MAX_AGE is 3600s, the key + "/old" entry never expires, and stale() returns that never-expiring value while refreshing in the background — so the corrected value only appears on the next request. In lib/endpoints.js the hourly refresh list covers r-oldrel/1..10 but contains zero resolve entries.

Consequence: any /resolve/oldrel/N/<os> tuple not requested within the last hour serves an arbitrarily old answer on its first request, then self-heals. That is why the plain /r-oldrel/N endpoint is always clean while /resolve/... drifts, why rarely-used platform tuples drift most, and why my readings vanished on retry. It was caught live three times during verification, including a self-inconsistent response labelled oldrel/4 while returning 4.1.3.

The failure is silent. A stale answer carries a valid installer URL, so CI installs a different R than the one requested and the job passes. A version-sensitive failure then cannot be reproduced.

Why exact pins are still the right fix

Not because the ladder is misnumbered — it usually isn't — but because an exact pin on a closed R branch is time-invariant. 4.3 resolves to 4.3.3 whether the cache entry is fresh or six months old, so staleness cannot silently substitute a different R. (Worth knowing: pinning a current branch such as 4.6 is not immune, since that branch still moves. Only closed branches, or full versions like 4.3.3, are fully safe.)

The second motive is unchanged and independent of any of this: the base matrix stops at oldrel-1 — currently R 4.5 — which is above this package's declared floor, so the floor was never tested regardless of how the ladder resolves.

One trade-off this creates

Exact pins do not track upward the way oldrel-N does. When R 4.7 ships, the default legs move to 4.7/4.6 while these stay put, and a gap opens with nothing to announce it. That is a deliberate trade — silence about a gap is preferable to silently testing the wrong R — but it does make these legs an annual review item.

An upstream bug report for the cache staleness has been drafted and not yet filed.

[eliotmcintire]

For the packages I maintain I am keeping the R-version matrix on oldrel-N rather than exact pins — it tracks R releases on its own, so the bottom of the matrix stays current without anyone editing a workflow file, whereas an exact pin becomes a standing review item.

But I am not the maintainer of this package, you are, so I am leaving this entirely to your call. This seems reasonable to decide package by package rather than to settle org-wide, and I have no objection either way here.

One separate note on this PR specifically, unrelated to the pinning question: the reusable-workflow half is a straight improvement, and it migrates test-coverage as well, which my #25 leaves behind. So whatever you decide about the exact pins, the rest is worth landing on its own — and if you do merge this, #25 should be closed as superseded.