Coverage report fails after 65536 characters

[danhunsaker]

The GitHub comment maximum length is, apparently, 65536 characters (though I suspect they might mean bytes):

RequestError [HttpError]: Validation Failed: {"resource":"IssueComment","code":"unprocessable","field":"data","message":"Body is too long (maximum is 65536 characters)"}

Having encountered a coverage report that surpasses this limit, and knowing the repo in question will only continue to have lengthier reports in the future, I'd like to find ways to shorten the report, or possibly split it across multiple comments.

I realize I could resort to an external coverage reporting tool, but I'd prefer to keep everything in one place. (Plus, with private repos, the cost of external tools gets really high really fast.)

[yoonwaiyan]

I'm having the same issue here with the same validation message.

[mszlgr]

Had same problem, and because it looks like this bug is open for long already I forked and modified it to not send link to every line that was not covered. Feel free to use it:

    - name: Report coverage
      uses:  mszlgr/[email protected]

Also this action failed for me when run on below trigger (it assumes that it is pull request), that was also fixed in my fork.

on:
  push:
    branches: [ master ]

[romeovs]

@mszlgr would you consider create a PR for this change?

[ulfgebhardt]

While the original fails with "... 65536 characters" the version of @mszlgr fails with "no PR" which is untrue.

Please publish your code @mszlgr so we can have it properly incorporated

[MuhaddiMu]

Any updates on this?

[ulfgebhardt]

I do not report the coverage on the PR, but have a github action check & enforce it - its my chosen solution:

https://github.com/webcraftmedia/coverage-check-action

See it here in action:

• The Code: https://github.com/gradido/gradido/blob/master/.github/workflows/test.yml#L313
• The Report: https://github.com/gradido/gradido/runs/3484556816?check_suite_focus=true

If you want the report in the PR commented this is not a valid solution

[klausbadelt]

Seems @mszlgr just disables the detail (collapsed) table - not a solution, the per-file table is essential IMHO.
mszlgr/lcov-reporter-action@633ea70

[klausbadelt]

@ulfgebhardt your check action IMHO is better anyway - annotations rule - but unfortunately it's also missing the per-file details table. Would you consider re-adding that?

[ulfgebhardt]

@klausbadelt I did not write the coverage-check-action tool. Its a fork from https://github.com/devmasx/coverage-check-action with a feature report_name to allow multiple coverage reports in one workflow. The original tool made all coverage reports overwrite others due to duplication of names.
I do not have a particular interest in the per file report, but I could image it to be usefull and if possible without effort I would include it in my projects. Tho I can encourage you to implement it and invite you to do so on https://github.com/webcraftmedia/coverage-check-action . If you decide to do that, I will help you if needed and can provide some infrstructure work like releases for the tool.
Deal?

[andybelltree]

I've just opened a PR which will
a) Allow you to supply filter-changed-files which will create a report for just changed files in that PR. This solves the issue for me
b) Shortens the output to be under the limit with a substring()

Example usage

   - name: Comment code coverage
        uses: andybelltree/[email protected]
        with:
          filter-changed-files: true

#31

[halleyrv]

I put filter-changed-files: true but now this is the comment in my pull request

NaN%--