Mocha: Github Actions Reporter

Created on 17 Dec 2019  路  9Comments  路  Source: mochajs/mocha

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

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.

All 9 comments

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:

Annotations example

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:

  • you implement a report, then Mocha has a report. Hm ... what for, what are the benefits?
  • priorities: we have many open issues, lots of waiting PR's, little resources. Many of those issues have higher priority than this report, whatever benefit it would return.

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!

Was this page helpful?
0 / 5 - 0 ratings