davelosert/vitest-coverage-report-action

Validation Failed: body is too long 65536 characters)

Closed this issue · 2 comments

We're getting the following error in our workflow:

{
  "resource": "IssueComment",
  "code": "custom",
  "field": "body",
 "message": "body is too long 65536 characters)"
}

This does not occur if we do not generate coverage-final.json.

For context, this is the yaml and error from the log

Workflow

steps:
  - name: Check out code
    uses: actions/checkout@v4

  - name: Use Node.js 16
    uses: actions/setup-node@v4
    with:
      node-version: 16

  - name: Restore dependencies
    run: npm ci

  - name: Build application
    run: npm run build 

  - name: Run unit tests
    run: npx vitest --coverage.enabled true --coverage.all --coverage.reporter=json --coverage.reporter=json-summary --coverage.reporter=clover --run --silent

  - name: "Report Coverage"
    uses: davelosert/vitest-coverage-report-action@v2
    with:
      name: "Frontend"
      file-coverage-mode: "all"

Log

Run davelosert/vitest-coverage-report-action@v2
  with:
    name: Frontend
    file-coverage-mode: all
    github-token: ***
    json-summary-path: coverage/coverage-summary.json
    json-final-path: coverage/coverage-final.json
    working-directory: ./
Fetching list of changed files for PR#3217 from Github API
  Received 2 items
Error: HttpError: Validation Failed: {"resource":"IssueComment","code":"custom","field":"body","message":"body is too long (maximum is 65536 characters)"}

Hi @mlafleur ,

I guess this is a possible duplicate of #232

This happens most likely because there are too many files in your projects and you've set the file-coverage-mode: all option. As such, this action hits the limits for the length of a GitHub Issue Body Comment when writing the changed-files section.

A workaround is to set the file-coverage-mode to changes to only get specific coverage reports for files changed in the PR.

I can't workaround the limitation unfortunatly, but I am planning to introduce a better error message for these cases (this is what #232 is all about)

As this is a duplicate of #232, I will close this issue for now. 🙂