GitHub Community
Extremely low annotation limit #68471
Replies: 10 comments 2 replies
|
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 🤞🏻 |
|
Aghotalam ya nke oma |
|
Even a message saying that further annotations were generated but aren't shown would be a step up from silently hiding them. |
|
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! |
|
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. |
|
Yeah, I ended up forking a public GH Action to add a "filter by changed lines" step. ( |
|
10 is super low, only takes a single line change to make a static analyser potentially output more than 10 errors |
|
I'm an author of a static analysis tool, and I've run into this limitation while adding a GitHub annotations output mode: zizmorcore/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. |
|
Hi!!! Nice to meet ya haha this is so annoying haha |
|
A "maximum number of annotations reached" would be very helpful. Spent two hours yesterday trying to figure out what I'm doing to break the GitHub annotation engine so no more annotations are being created. Totally clueless I gave up and sent a few of the generated annotations to an AI model to see if he could spot the error, and he told med about this limitation, and he emphasized it's undocumented. 🤷 |
|
The best documentation about those limits I found in docs of actions toolkit 🙄 : |
|
No doubt like every one here. just wasted more hours than I'm prepared to admit just to find out that there is a limit that is so small it is just "stupid" As others have pointed out, it's not uncommon to go above 10, let alone 50 for a whole workflow. Why even call it a feature? It's incomplete as there is nothing to show that you have "more" annotations that will be ignored. AND 3 years later and it's still a problem!!!!!!!!!! |
Uh oh!
There was an error while loading. Please reload this page.
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.
All reactions