ci: repoint install-spatial-deps to @main

[achubaty]

Repoints install-spatial-deps from v0.2 to @main — 1 reference(s) in .github/workflows/R-CMD-check.yaml .

Why

Every published tag of that action — v0.1 through v0.5, including the newest — still runs:

add-apt-repository -y ppa:ubuntugis/ubuntugis-unstable

That PPA installs libgdal37 (GDAL 3.11.x). Posit's noble binary cache builds sf/terra against the Ubuntu-default libgdal34 — confirmed by objdump on the PPM noble tarballs, which need libgdal.so.34, libproj.so.25, libgeos_c.so.1. The mismatch surfaces only at lazy-load, as libgdal.so.34: cannot open shared object file, and takes the whole job with it.

Only @main dropped the PPA (PredictiveEcology/actions#25). Tags do not move, so pinning to one keeps the hazard — which is why "pin to the newest tag" is currently the wrong advice for this action.

This repo's own history records the failure in both directions: a cached terra built against one libgdal while the runner supplied the other. The underlying cause was a stale setup-r-dependencies package cache outliving a change in the runner's system GDAL — the PPA is what made the two disagree.

Note

On the pak path this step is largely redundant anyway: setup-r-dependencies → pak::lockfile_install() → install_sysreqs() already installs libgdal-dev, gdal-bin, libgeos-dev, libproj-dev, libsqlite3-dev and libudunits2-dev from stock noble apt, and pak's own rules add the ubuntugis PPA only for Ubuntu 14.04/16.04. Removing the step entirely is a separate change, gated on a self-test run — this PR only makes the pin correct.

🤖 Generated with Claude Code

[eliotmcintire]

@achubaty I am not finished the full migration. Please do not work on this yet.

[eliotmcintire]

Redundant with #31, which migrates this repo's R-CMD-check.yaml to the org reusable workflow.

The migration removes the install-spatial-deps step entirely — the reusable workflow installs the geospatial system dependencies itself via setup-r-deps (PredictiveEcology/actions#25) — so the line this PR repoints no longer exists afterwards. Whichever of the two merged second would hit a conflict for no gain.

Closing this one rather than #31 only because the migration is the superset; the repointing intent is identical and correct. Same treatment was applied to an equivalent set of repin PRs I had opened earlier.

Not a comment on the ~40 module repos (Biomass_*, fireSense_*, BiomeBGC_*, …) — those are not covered by the migration and should go ahead as-is.

🤖 Generated with Claude Code

https://claude.ai/code/session_012DVjmY3im9Xak7tXLSMGCa