Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

"Unchanged files with check annotations" is disruptive and should be configurable #457

Open
ThiefMaster opened this issue May 14, 2020 · 16 comments
Labels
enhancement New feature or request external

Comments

@ThiefMaster
Copy link

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.

@majew7
Copy link

majew7 commented Jun 9, 2023

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.

@dpwiz
Copy link

dpwiz commented Sep 18, 2023

I only recently got to using GitHub full time and this s..t makes my blood boil 🤬
It is makred beta, you'd betta have a way to remove it 💢

@mistercrunch
Copy link

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.

@kberg
Copy link

kberg commented Apr 1, 2024

This is preventing me from merging perfectly good PRs, and is incorrect.

@pavelloz
Copy link

pavelloz commented Jul 3, 2024

How to turn this thing off? Do i need to resort to ublock filters or what?

@m2-farzan
Copy link

m2-farzan commented Sep 12, 2024

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/)

@pavelloz
Copy link

Thank you very much @m2-farzan
This thing is ridicolous and frustrating. Im surprised its still an issue we have to work around.

@mistercrunch
Copy link

mistercrunch commented Sep 13, 2024

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!

@UserNotFound
Copy link

The linter I'm use allows me to ignore errors, but they are still logged as warnings, and every PR for that repo is full of these annotations. If this is in Beta, why can't I opt out? If people have been complaining for 4 years, why hasn't it been addressed? Feels like an abandoned feature I'm forced to live with.

I've been pressing the a key to hide them, but still....it's no fun to have to tell others they have to do that when reviewing my PRs....

image
https://x.com/natfriedman/status/1366417484698578953

@pavelloz
Copy link

pavelloz commented Nov 4, 2024

Almost 4 years... Unbelievable.

@mistercrunch
Copy link

mistercrunch commented Nov 5, 2024

Do we know if github employees look at top issues, maybe prioritized by number of comments/reactions? If so maybe we get our communities to +1 👍 this issue? We've got about ~200 reactions now, how many does it take to get something prioritized!?

Wasn't there some story about some software engineer who raged-joined a company, got hired, fixed the annoying bug they couldn't live with, made sure it 🚢 , and proceeded to give its 2 weeks notice (?) Which one of us is going to have to do this :) ?

@dpwiz
Copy link

dpwiz commented Nov 7, 2024

The support says this is an "enhancement" waiting to be addressed.

It appears that other priorities are currently being addressed, and an ADR for this enhancement has not yet been initiated.

Perhaps it should be re-qualified as a bug? @thboop

With that in mind, please rest assured that the engineers take this feedback seriously and it will be considered for future ADRs.

After all those years I've started to doubt that...

@mistercrunch
Copy link

The indirect solution might be to introduce a linter/lint rule that makes this issue appear in one of the repos where GitHub employees are active :)

@SomeoneIsWorking
Copy link

@github I wanna pay you to allow me to hide this. Please.

@ahbarnett
Copy link

I agree. Please allow this "feature" to be disabled in the web interface.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request external
Projects
None yet
Development

No branches or pull requests