You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The GitHub annotations system enforces a hard limit of 10 errors/warnings per check run, which can create challenges when running comprehensive checks with a higher number of warnings. This limitation can hinder effective debugging and reviewing for larger projects.
When running the plugin-check-action, only the first 10 errors/ warnings are displayed as annotations. This might lead to missing other important errors/warnings unless users manually check the logs or artifacts for detailed output.
Possible workarounds:
Combine multiple errors/warnings into a single annotation message to stay within the 10 error /warning limit while still providing meaningful feedback.
Produce an artifact (e.g., HTML or JSON file) containing a full report of all errors / warnings. Users can download this file for in-depth analysis.
Would it make sense to implement one of these workarounds in this action?
When introducing Plugin Check in larger projects it's probably best to start with the plugin and not the GitHub Action, because of the much faster feedback loop. Later on you’ll automatically have fewer annotations. So I'd consider this a bit of an edge case.
As for potential solutions, I think leaving a PR comment is probably best, see #1
Grouping unrelated messages in an unrelated file sounds weird from a UX perspective. An artifact might be a nice addition, but is also easy to miss. If you need a table with all errors, the plugin is the quicker choice.
The GitHub annotations system enforces a hard limit of 10 errors/warnings per check run, which can create challenges when running comprehensive checks with a higher number of warnings. This limitation can hinder effective debugging and reviewing for larger projects.
When running the plugin-check-action, only the first 10 errors/ warnings are displayed as annotations. This might lead to missing other important errors/warnings unless users manually check the logs or artifacts for detailed output.
Possible workarounds:
Would it make sense to implement one of these workarounds in this action?
Reference: Extremely low annotation limit Thank you for considering this improvement!
The text was updated successfully, but these errors were encountered: