Create a vignette for package developers

[maelle]

"Get started"

for developers a deeper explanation of how to use the package failing output, and when it is relevant.

@yonicd do you have examples of cases in your own packages where the report informed development?

cf #27

[maelle]

The vignette should explain what problem covrpage is trying to solve. In my own words: A coverage badge is only a number. When clicking to read the coverage report one gets as much information as one would like, but in an external website and in a nested way, whereas covrpage report has all the information in a single page.

I have to say that if I had to review a package, I might still look at codecov report, especially because of the report for individual R files e.g. https://codecov.io/gh/yonicd/covrpage/src/master/R/badge.R How would you answer that in a vignette @yonicd?

[yonicd]

covrpage doesnt take the place of codecov, it has higher level coverage information that can be conveyed to users before they choose to go to another site from the originating gh repo.

covrpage can give you a more targeted search in codecov. maybe a good solution is to try to build the links, in addition to the files in gh, to the codecov (when it is there) of the build.

the only problem there is in that is like the link you gave for badge.R, the test I run locally is not always the same as in the ci's when using skip_on_travis. many times you skip_on_travis for some technical reasons that couldnt be resolved on the ci ami.

in general i would give motivation for developers the way @llrs or @IndrajeetPatil found ways to leverage the package in their development. I know that @colinfay also has some opinions on how developers can use it in their workflows.

maybe @sellorm @dpastoor have some points to add as an onprem maintainers and how it fits in that workflow.

[llrs]

Just my 2 cents. I used covrpage to start doing test driven development. I first created some tests and then with covrpage I checked my progress. So failing a test is not necessary bad.

[yonicd]

here is a good example of a live repo with test resulting in errors. the status badge on the root readme shows failing, jumping to tests/readme gives a quick human readable specific reason for failure.

[llrs]

@yonicd About that specific report, I'll probably open a new issue. The test are passing in my local machine using devtools::test (and in travis +covr), but when building the report they fail... anyway my point is that the report helps to track development.

[yonicd]

devtools::test runs testthat::test_dir covrpage runs testtthat::test_check which is akin to running tests on covr or cranlike environment.

[yonicd]

merged PRs https://github.com/yonicd/covrpage/commit/c76d9efa256ec6ca7b3154427784267c01689de8, https://github.com/yonicd/covrpage/commit/21299da6f28a4cd9b84716b3467c3c929e3b7b21

[llrs]

There's a comment: <!-- When it exists point to the vignette explaining how to read and interpret the report. -->] that I think should link to the other vignette referenced above.

[yonicd]

Yes. Thanks for pointing that comment out. It was on a todo for later today.