Feature Request: Disable GitHub Problem Matcher annotations

[Avasam]

Hi! I would like pyright-action to provide a way through configuration to disable Problem Matcher annotations. This can cause irritation in some projects that still have lots of warnings. See mhammond/pywin32#2102 (comment) for example. Especially for unchanged files (since GitHub doesn't allow configuring that Beta feature): actions/toolkit#457 & https://github.com/orgs/community/discussions/81472

From https://github.com/actions/toolkit/blob/master/docs/commands.md#problem-matchers and https://stackoverflow.com/a/65964721 I read it should be possible to disable them, by adding a step - run: echo "::remove-matcher owner=pyright::", but that didn't seem to work. Even if it did, it's not well-publicised or known.

[jakebailey]

I think you're looking for no-comment: true? https://github.com/jakebailey/pyright-action#:~:text=required%3A%20false-,no%2Dcomments%3A,-description%3A%20%27

[jakebailey]

(problem matchers are a different thing entirely)

[jakebailey]

I suppose that it would be beneficial to have this option configurable such that you can control the level of messages that get shown as annotations, if that's what you're looking for. Disabling them entirely may not be good because showing errors is pretty helpful.

[Avasam]

I think you're looking for no-comment: true? jakebailey/pyright-action#:~:text=required%3A%20false-,no%2Dcomments%3A,-description%3A%20%27

I'll try that, I thought that was for something else.

(problem matchers are a different thing entirely)

That would explain why the above attempt to disable didn't work.

I suppose that it would be beneficial to have this option configurable such that you can control the level of messages that get shown as annotations, if that's what you're looking for. Disabling them entirely may not be good because showing errors is pretty helpful.

I personally agree and would even leave warnings in untouched files on for my own projects (because I'd want to get to them eventually, and it's more visible than in a CI log for an action that passed).

But for projects where I'm using the "waterleak principle" (ie: prevent new errors, set everything existant as warning to help slow new violations, then gradually fix them and turn them back on), it can lead to a ton of warnings (currently ~470 in pywin32, a handful in setuptools, etc.) that some maintainers may not be a fan of seeing "pollute" the files tab.

[jakebailey]

I'll add some configuration, and try and rename the flag to be more clear. In hindsight, it should really be called "no-annotations", but the underlying API GitHub provides calls them comments, so I used that name 😄

[jakebailey]

I just released v2.2.0. You can now write:

with:
   annotate: errors

Which will only annotate errors.

[Avasam]

I'll add some configuration, and try and rename the flag to be more clear. In hindsight, it should really be called "no-annotations", but the underlying API GitHub provides calls them comments, so I used that name 😄

Thanks for the consideration. I think at least making the description a bit more clear that it's related to the GitHub comments in the files tab (and not code / pyright comments) would be enough for me.

I just released v2.2.0. You can now write:

with:
   annotate: errors

Which will only annotate errors.

wow that was fast ^^

[jakebailey]

Thanks for the consideration. I think at least making the description a bit more clear that it's related to the GitHub comments in the files tab (and not code / pyright comments) would be enough for me.

The new name is "annotate" and it mentions "annotations"; is that enough clarity? GitHub has them in a subheading that says "annotations", so I think it's enough?

[Avasam]

The new name is "annotate" and it mentions "annotations"; is that enough clarity? GitHub has them in a subheading that says "annotations", so I think it's enough?

"Annotation" is indeed what I initially searched for in the readme. So I'd say yes that is enough for me.

[stephanebiermann]

@jakebailey Do you know who at GitHub is responsible for the toolkit and could assist with making the below mentioned issue configurable/possible to turn off ?

actions/toolkit#457

[jakebailey]

No, I have no idea.

(Asking me about a GitHub issue is a bit like asking the DMV about your taxes; both are technically the government, but have nothing to do with each other.)