Open ThiefMaster opened 4 years ago
only show errors but not warnings
Yes, in the context of .NET, I worked around this "Unchanged files with check annotations" beta feature by building my solution without warnings.
dotnet build MySolution.sln --no-restore /property:WarningLevel=0
Very lame.
I only recently got to using GitHub full time and this s..t makes my blood boil :cursing_face:
It is makred beta
, you'd betta have a way to remove it :anger:
Please allow us to turn this off! For us, warnings are useful in the context of eslint
and certain workflows, but not useful in the context of an unrelated PR. There should always be an easy way to turn off beta features like this one.
This is preventing me from merging perfectly good PRs, and is incorrect.
How to turn this thing off? Do i need to resort to ublock filters or what?
How to turn this thing off? Do i need to resort to ublock filters or what?
I'm using this ublock filter:
github.com##div.js-diff-progressive-container:has-text(/Unchanged files with check annotations/)
Thank you very much @m2-farzan This thing is ridicolous and frustrating. Im surprised its still an issue we have to work around.
What do we need to do in order to get GitHub to assign an engineer to this issue? The issue is annoying enough that if GitHub's code was open source one of us would bite the bullet and get this done. Can't be that hard!
The "Unchanged files with check annotations" feature when using problem matchers needs to be configurable (for each action/matcher): It's pretty discouraging for a new contributor to see loads of unrelated warnings from a style checker in their first PR that are completely unrelated, not to mention that it also adds noise for checkers where you know that it's not something that could be caused in changes from another file in the PR.
For example, I'm running stylelint with
no-descending-specificity
warnings enabled. For CSS added in a PR those warnings may be useful, but I REALLY don't care about the almost 1000 warnings in our existing codebase (some even in legacy files) when running CI for a new PR!Right now the only workaround for this is to either disable the rule altogether, only show errors but not warnings, or somehow only run the linter on new/changed files when running the action for a PR.