ATFutures / geoplumber

Serve geographic data from R and consume with scalable front end.
https://atfutures.github.io/geoplumber/
59 stars 7 forks source link

Exclude lines from codecov #47

Closed mpadge closed 5 years ago

mpadge commented 5 years ago

@layik Following from #37: Lines that we really don't want tested can be excluded from codecov reports, like this example for dodgr. This will improve coverage. I'll have a look through tomorrow and give it a start.

layik commented 5 years ago

Sorry could not get back on this earlier @mpadge. Great! I just realised its an R package 📦. So this should work, but the only way to find out is to push? Could I run it locally? Trying..


package_coverage(line_exclusions = list("R/test.R" = c(1:10, 15)))```
mpadge commented 5 years ago

Updated dodgr example now uses function_exclusions which is even easier

layik commented 5 years ago

Thanks Mark, I saw the function example. Not sure if just adding the name would mean it would ignore all function calls. :) trying again.

layik commented 5 years ago

resetting..

layik commented 5 years ago

I think covr is designed to ignore test file lines or I cannot see how it is done. I am looking at Sys.setenv and getenv to work around this and move the switch into the actual code or some other way.

layik commented 5 years ago

This is what we have done: https://github.com/ATFutures/geoplumber/blob/master/tests/testthat/test-gp_build.R#L7 Looks for an env var and for us we can set this using a Renviron file at ~/ for security reasons (see ftp://cran.r-project.org/pub/R/web/packages/httr/vignettes/secrets.html) (Edit: ftp link not appearing). Travis and covr would not have it an would therefore run full tests (giving up on shortening build times on their servers).

Not exactly the way you were expecting @mpadge.

Build
Status codecov Project Status:
WIP

Robinlovelace commented 5 years ago

Looks good to me!

layik commented 5 years ago

With @mpadge's permission. If need be we can reopen.

mpadge commented 5 years ago

Yeah, that's all fine and dandy, except I'd suggest that RUN_FULL_TEST is a bit ambiguous - full test of what?. System variables to control tests are usually only controlled by a single package maintainer, so are more commonly of the kind i generally use: "MPADGE_LOCAL". If I find that variable, then I determine within the very local scope of a single test file what "full test" might actually mean. Totally nit-picky here, but it is a topic that's been discussed a few times in package reviews, so worth giving some thought to. Also, if it's some generic phrase, there's a chance, however slim, that somebody else might have the same variable, which'd be ... not good. Hence common use of personal github handles.

layik commented 5 years ago

Thanks a lot and super insights Mark. I will be much more nit-picky too from now on. I just could not get covr to ignore a line or two :) I hope I can in future.

layik commented 5 years ago

"GP_LOCAL_INCLUDE_BUILD" or something like that.