Closed ericphanson closed 3 years ago
I think providing some API for the user to customize what report
does would definitely be in the scope. The specific code for the GitHub annotations I would prefer having in a separate package, to avoid feature creep in Documenter.
Sorry, I forgot to update this- I’ve since realised we can handle the GitHub annotation case with only https://github.com/JuliaDocs/Documenter.jl/pull/1687, since we can use a special logger to handle the message and create the annotation!
I think likely many other report targets could be handled similarly by loggers, since with that PR they get the line and file info of the failing test. So I’ll close this at least for now.
Currently,
doctest
callsreport
to emit an@error
with the details of the failing doctest. Would it be in Documenter’s scope to support other targets? I’m in particular thinking that when run in GitHub Actions CI on a PR, instead of just printing to the logs, Documenter could make “annotations” on the PR itself, like codecov does for example (another example: https://github.com/reviewdog/reviewdog#reporter-github-checks--reportergithub-pr-check). That would allow one to see the failing test in-line in the PR (next to the code of the test) rather than in the logs where it’s separated from the code.