-
Notifications
You must be signed in to change notification settings - Fork 235
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Travis: Build against multiple R versions #2281
Conversation
- RSQlite and data.table, needed by db - gap, needed by assim.batch - sirt and sf, needed by data.land
@mdietze I may not have made the "opinions, please" section prominent enough. Should I take your approval to also be an endorsement of allowing failures in oldrel and devel? |
Yep, I endorse your approach, but didn’t pull yet so as to give others time to comment. Given how some packages change, it may be impossible to support multiple versions without code that detects which version is installed and switches among different code blocks, and that could become a nightmare |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good, like the ability to compile against 3 versions of R. I agree with the OK to fail if old or next version are broken.
Description
make check
now skips rebuilding documentation if env var$REBUILD_DOCS
is falseMotivation and Context
R versions
The major change here is a transition from testing against one R version (hopefully the one most users have) to defining a build matrix so that we can test in multiple environments at once. The build matrix concept could be extended in the future to include different OSes, Postgres versions, environment variables, etc, but for this PR the matrix is one-dimensional and contains three R versions:
release
,devel
, andoldrel
. These are aliases defined by Travis and currently point respectively to R 3.5, nightly, and 3.4, but versions are updated each release.Opinions, please: I currently have the devel and oldrel builds marked as
allow_failures
, which means the build is always run on all three versions, but will report success as long as it finishes successfully on R-release. My rationale is that this will let us keep an eye on how it's doing in other versions but won't commit us to maintaining them. Is this what we want?Skip documentation
I've updated
scripts/check_with_errors.R
to recognize an environment variable$REBUILD_DOCS
and pass its logical value to thedocument
argument ofdevtools::check
. This is primarily to save a few seconds per package on Travis, where documentation is always freshly-built at check time, but feel free to use it any other timemake check
fails to document/not document things the way you want.Review Time Estimate
Types of changes
Checklist: