Skip to content

New capability: R-CMD-check reusable workflow #331

Description

@d-morrison

This repo has no R CMD check capability. README.md's Scope section still lists it as something that "may be added later", and rpt carries a bespoke R-CMD-check.yaml (5-way OS x R-version matrix, rocker/verse container on Linux, error-on: note, Julia + Quarto + pandoc setup) that every R package created from that template inherits as a copy.

Reviewing IndrajeetPatil/workflows/.github/workflows/R-CMD-check.yaml (MIT) turned up two design ideas worth taking rather than just porting rpt's copy verbatim.

1. A hard input for a hard-dependencies-only check

Upstream defines two mutually exclusive jobs selected by a hard boolean:

  • default — the full OS x R-version matrix.
  • hard: true — a single Ubuntu run installing only Depends/Imports/LinkingTo, gated to pull_request only, with just knitr, rcmdcheck, rmarkdown, curl, testthat added back.

This catches the common failure where a package works for the author but breaks for a user who did not install Suggests — a real CRAN-facing concern that the standard matrix cannot detect, since it installs everything.

2. cache: false on the hard job

The subtle part, and the reason to copy the design rather than reinvent it. Upstream sets cache: false specifically on the hard-deps job, with a comment explaining why: a restored dependency cache may already contain a suggested package, which would silently defeat the whole point of the job. Easy to omit and impossible to notice from a green run.

Do not copy

Upstream's concurrency.group is ${{ github.workflow }}-${{ github.head_ref }} with no || github.ref fallback. head_ref is empty on push, so every push across every branch collapses into one group and cancels the others. Their own pre-commit.yaml has the fallback; R-CMD-check.yaml is the one that does not.

Also worth deciding deliberately rather than inheriting: upstream sets error-on: '"note"' (NOTEs fail), matching rpt's existing choice, plus _R_CHECK_CRAN_INCOMING_REMOTE_: false, _R_CHECK_FORCE_SUGGESTS_: false, and _R_CHECK_STOP_ON_INVALID_NUMERIC_VERSION_INPUTS_: true. These should be inputs, not hard-coded, since consumers will disagree.

Migration note

Per CLAUDE.md's migration guidance, this needs a step-by-step diff against rpt's bespoke workflow before it can be called drop-in — rpt's version does Julia, Quarto, and pandoc setup and runs in rocker/verse on Linux, none of which upstream's does. Confirm each step has an equivalent (or an input) before migrating rpt, rather than inferring parity from the inputs table.

Source: IndrajeetPatil/workflows, MIT.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions