You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Running lintr can take quite some time for large packages, so I think it is a good idea to exclude it from being run during a code coverage check (where it is useless?), e.g. when using covr. When lintr is invoked in testthat using expect_lint_free, the test is skipped if NOT_CRAN is not "true". Therefore, when using package_coverage() to get coverage data locally, lintr is excluded.
Travis seems to set NOT_CRAN to "true", however, so I assume lintr is run twice there and is leading to longer Travis build times.
I suggest also checking for the "R_COVR" environment variable in expect_lint_free, and skipping linting it is set to "true".
The text was updated successfully, but these errors were encountered:
Running
lintr
can take quite some time for large packages, so I think it is a good idea to exclude it from being run during a code coverage check (where it is useless?), e.g. when usingcovr
. When lintr is invoked in testthat usingexpect_lint_free
, the test is skipped ifNOT_CRAN
is not"true"
. Therefore, when usingpackage_coverage()
to get coverage data locally, lintr is excluded.Travis seems to set
NOT_CRAN
to"true"
, however, so I assume lintr is run twice there and is leading to longer Travis build times.I suggest also checking for the
"R_COVR"
environment variable inexpect_lint_free
, and skipping linting it is set to"true"
.The text was updated successfully, but these errors were encountered: