This comes out of #214. There was a workaround provided to this usually happening with too many files in a project (#192), but it really is this, a workaround.
My Idea was to check the length of the body before sending it to GitHub (or, react to the error of the http request) and then shorten / abbreviate the body by reducing the number of files. It should also add a warning to the body of the comment that this happened.
Additionally, I'd love to see that the actual workflow-summary contains all the file-reports (as it doesn't have the body-length-restriction as a pull-request comment). However, this requires a bit of more work as one would have to create two different reports.
This comes out of #214. There was a workaround provided to this usually happening with too many files in a project (#192), but it really is this, a workaround.
My Idea was to check the length of the body before sending it to GitHub (or, react to the error of the http request) and then shorten / abbreviate the body by reducing the number of files. It should also add a warning to the body of the comment that this happened.
Additionally, I'd love to see that the actual workflow-summary contains all the file-reports (as it doesn't have the body-length-restriction as a pull-request comment). However, this requires a bit of more work as one would have to create two different reports.