Any thoughts on implementing a reporter for Github Actions? Partially related to #4117
It looks like it'll seamlessly tie into the PR to identify problematic lines of code.
https://help.github.com/en/actions/automating-your-workflow-with-github-actions/development-tools-for-github-actions#set-an-error-message-error
I can take a look into implementing this or if someone tells me this has already been implemented, I'd appreciate it very much!
duplicate of #4117
Hi @juergba, respectfully, this doesn't look like a duplicate to me.
It looks like #4117 is related to the release process of mocha, but this issue is looking at the reporter for mocha such that it can output the errors in a compatible format for Github Action so we can get annotations directly in Github about the offending lines of code.
For example, eslint implements this through their stylish formatter - https://github.com/eslint/eslint/blob/master/lib/cli-engine/formatters/stylish.js
Visual example of what I mean by the annotations:

It doesn't look like mocha currently has a reporter that's compliant with the Github Actions output requirements, I just want a confirmation from someone and I can work up a reporter implementation and submit a PR if confirmed. Thanks!
@zxlin thank you.
I currently don't see the necessity for such a report. So from my side you don't get this confirmation. My main reasons are:
Hi @juergba
The primary benefit is the screenshot above - so that users of the lib when they run their CI pipeline on Github Actions, they can get the test case failures annotated on their PR. Otherwise right now they just get a giant text output and they have to manually inspect the test case output to identify where the errors came from.
+1 came here looking for this
@zxlin @ukd1 Mocha can use external reporters with the --reporter option. Have you considered creating one yourself and open sourcing it?
@Munter thanks for the reply, in my initial posting I said:
I can take a look into implementing this
and I again reiterated in my follow up post after this issue got, in my opinion, mistakenly closed that:
I can work up a reporter implementation and submit a PR
I was hoping to find some support for this from the maintainers in it being at least a good idea to implement, but in the follow ups from @juergba, it sounded like he doesn't see the necessity which was low key very demotivational for me to go out and implement one of my own.
I can certainly see the benefits. But there is a difference between creating a PR for a new reporter and making it as its own project. Putting it in core puts the maintenance burden on the core developers, which have little time available as it is. So for a reporter, which already can be plugged in from external packages, I also see little motivation to put it in core.
@Munter great reply; you explain why this shouldn't be in core (tbh, totally makes sense) and a route out (writing an external reporter). Thanks!
Most helpful comment
Hi @juergba
The primary benefit is the screenshot above - so that users of the lib when they run their CI pipeline on Github Actions, they can get the test case failures annotated on their PR. Otherwise right now they just get a giant text output and they have to manually inspect the test case output to identify where the errors came from.