[R-pkg-devel] checking windows timing?
FWIW, we dealt with the tests-taking-too-long problem for CVXR (which has a lot of tests) by mercilessly cutting out all tests on CRAN (testthat::skip_on_cran()) except for some fundamental ones on atoms, curvature, etc.? We then rely on Github actions (with NOT_CRAN = true) to run the full test suite on several platforms. Not perfect, but that's what worked for us. -Naras
On 10/13/20 9:46 AM, Ben Bolker wrote:
? Following up on my questions from yesterday:
? I've been advised to (drastically) reduce the checking time of my
package on CRAN's Windows platform (currently at 23 min). I've gone
through and added a lot of conditionals to skip tests on CRAN.? I
could reduce it farther but I'm starting to encounter seriously
diminishing returns, e.g.
?* do I condition out some particular test that takes 6 seconds?
(e.g., a little slow, but not egregious)
?* do I put \dontrun{} around an example that takes 6 seconds [I'm a
bit confused about this, but as I understand it CRAN checks with
--run-donttest ? \dontrun{} also sometimes provokes complaints from
CRAN, because "you should only use \dontrun{} for code that cannot be
run by users" ...]
? I don't want to spend forever tweaking things, and I don't want to
comment/condition out all of my tests, but I would really prefer to
avoid bouncing from CRAN again. I don't know a *reliable* way to test
whether CRAN-checking on Windows will take <10 mins or not ...
? I don't have a local Windows test platform.
? win-builder gives timings for long-running components, but not for
the whole run.
? r-hub gives a time for the entire build (19 min in my case) - but
this includes the time to set up the virtual machine, install all
packages, etc..
? I can approximately predict that most examples and tests will take
twice as long on CRAN's windows machines (and four times as long since
tests, at least, are checked on both i386 and x86_64 architectures).
? Testing is currently taking 6 minutes on my local machine (newish
Ubuntu 18.04 laptop), so I guess have more work to do, but I wonder if
anyone has suggestions ...
? cheers
??? Ben Bolker
______________________________________________ R-package-devel at r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-package-devel