It should be possible to have matchers deduplicate identical annotations

[JasonGross]

If I have workflow with multiple jobs (e.g., testing C code with multiple versions of gcc), if the same warning/annotation comes up multiple times in different jobs, I want it to be appropriately deduplicated. That is, I don't want to see something like this:

(Feel free to tell me that this is the wrong venue to report this issue, and that there's a different place to be reporting issues in annotations, or that I should email support@github.com or whatever.)

[xt0rted]

This was reported in https://github.com/actions/runner/issues/264 and closed saying it was another team's issue.

[G-Rath]

It would be great if there could be some traction on this, as it's very easy to get spammed by annotations.

For example, setup-node provides problem matchers for eslint, which have started kicking in on our repos; for applications this is usually fine but for libraries like eslint-plugin-jest, where we have a matrix of actions to run our tests on Node 8, 10, 12, and 14, each using ESLint 5, 6, and 7, we end up getting spammed with the same linting annotation 30 times:

(Taken from this PR - it might go away later if I force push, but can easily reproduce).

I love the annotations feature, but this will get old pretty quickly since there isn't any mechanism (that I know of at least) for having problemMatchers/annotations only apply to specific jobs or steps (short of fancy footwork with custom actions).

It would be good if there was an official ticket we could watch to see the progress and priority of this issue, as so far we've just got a ticket opened 6 months ago by @xt0rted that was closed 6 days later by @thboop saying they've passed it on another team - a reasonable response except it leaves us (the community) without anyway to tell if the issue is actually being worked on or seen by anyone, as well as make it harder to tell how much this might matter to the community since there's nothing to upvote.

[xt0rted]

@G-Rath you can turn problem matchers off, there's just no real documentation talking about it.

The setup-node action registers 3 problems matchers which are:

• eslint-compact
• eslint-stylish
• tsc

Using those names you can turn off any of them with the remove-matcher command.

If you only want them to run for node 14 and eslint 7 you could try something like this:

- name: Use Node.js ${{ matrix.node-version }}
  uses: actions/setup-node@v1
  with:
    node-version: ${{ matrix.node-version }}
- if: matrix.node-version != '14.x' || matrix.eslint-version != '7'
  run: |
    echo "::remove-matcher owner=eslint-compact::"
    echo "::remove-matcher owner=eslint-stylish::"
    echo "::remove-matcher owner=tsc::"

[JasonGross]

This is not a very good solution, IMO; the whole reason to test multiple versions is to ensure that the code doesn't break on any of them. It's not particularly nice if the annotations are only visible when the failure is on a particular version, but not if the failure only occurs on other versions.

[JustinGrote]

In my case the annotations aren't identical and they get duplicated anyways, here's a simple repro: https://github.com/actions/runner/issues/504#issuecomment-647903579

[alcuadrado]

This is such a common problem (almost guaranteed if you use a matrix strategy) that it's surprising it hasn't been solved. Even a solution requiring some user manual intervention (e.g., defining a merge-id for each annotation) would be much times better than the current spammy situation.