Extremely low annotation limit

[lisanna-dettwyler]

Select Topic Area

Product Feedback

Body

According to https://github.com/orgs/community/discussions/26680, you can only have 10 warnings or errors per step, and 50 per job which feels extremely low and arbitrary. I can understand this being used to make sure other annotations from other steps don't get lost in the noise. Unfortunately, this breaks workflows which are intending to post warning annotations to specific lines in files, such as to indicate the results of static analysis checkers.

There is no user interface feedback indicating that warnings are being hidden, nor documentation about this at https://docs.github.com/en/actions/using-workflows/workflow-commands-for-github-actions#setting-a-warning-message, so it just makes it look like the feature is broken.

[FollowTheProcess]

Just adding my +1 to this, love the annotations feature and am using it in a GitHub action I've written for my organisation, but you can easily come up with >10 warnings or errors. Is there any way this can be increased? I understand page performance concerns of loading lots of these but surely something can be done here e.g. similar to "large diffs are not shown by default" We could have a similar feature for annotations

Hoping this gets prioritised as with such a low limit I'm struggling to use the full benefit of the annotations 🤞🏻

[Elementoso]

Aghotalam ya nke oma

[mwstanleyft]

Even a message saying that further annotations were generated but aren't shown would be a step up from silently hiding them.

[andyhinds]

I have just got in a right muddle as annotation errors I was expecting to see weren't there. Now I know the limit I might be able to work around it but it would be much better if we could see more, or at least have an indication that more errors actually exist!

[austinpray-mixpanel]

I'm okay with the 10 warning / 10 error limit as long as the UI prioritizes showing warnings / errors relevant to the pull request diff. Right now I think it's in the order they are printed in the action. Which makes putting relevant warnings (caused by incrementally rolling out a stricter lint rule) in front of pull request authors more difficult.

[Kyle-sandeman-mrdfood]

Yeah, I ended up forking a public GH Action to add a "filter by changed lines" step. (original-command > output.txt; python filter.py output.txt sort of thing.)
I would really like the limit raised even if only for paid plans in private/org repos

[mad-briller]

10 is super low, only takes a single line change to make a static analyser potentially output more than 10 errors

[woodruffw]

I'm an author of a static analysis tool, and I've run into this limitation while adding a GitHub annotations output mode: woodruffw/zizmor#634

From my perspective this is a significant functional limitation on GitHub, one that's made worse by the lack of user feedback or indicators telling consumers that their annotations have been silently swallowed/suppressed. Is there any plan to (at least) provide an indicator when annotations are being suppressed due to volume? That alone would make the feature's limitations significantly easier to communicate to users.