When a patch cannot be downloaded and `only-new-issues` is set, error instead of running

[connorszczepaniak-wk]

Welcome

• Yes, I understand that the GitHub action repository is not the repository of golangci-lint itself.
• Yes, I've searched similar issues on GitHub and didn't find any.
• Yes, I've included all information below (version, config, etc).

Description of the problem

I recently had a run of golangci-lint where the GitHub API responded with 422 downloading the patch for the PR. The PR was very small (6 lines, 1 file changed), but the API responded with the following:

failed to fetch pull request patch: RequestError [HttpError]: The diff could not be processed because too many files changed

This lint run has only-new-issues set, but without the patch it flagged a large number of issues in the entire repo because it ran without the patch.

It would be nice to have an option to error sooner and more obviously if the patch couldn't be downloaded instead of running the linter on the whole codebase. I understand that it may not be desirable for all use cases, so I propose making this a configuration option.

Version of golangci-lint

1.56.2

Version of the GitHub Action

4.0.0

Workflow file

Details

     - name: Lint Main
        uses: golangci/golangci-lint-action@3cfe3a4abbb849e10058ce4af15d205b6da42804 # v4.0.0
        with:
          version: v1.56.2
          only-new-issues: true
          args: -v --timeout=10m

Go version

1.22.0

Code example or link to a public repository

N/A

[nielskrijger]

Same issue; Go 1.21, golangci-lint 1.55.1, Github action v4.

Was this introduced by V4?

At the moment this will happen for any PR with --only-new-issues that changes >300 files.

[connorszczepaniak-wk]

I just hit this even more explicitly:
failed to fetch pull request patch: RequestError [HttpError]: Sorry, the diff exceeded the maximum number of lines (20000): {"resource":"PullRequest","field":"diff","code":"too_large"}

I'm not sure what I'd want in this case. Failing would be bad, because then there'd be no way around it -- but I also don't want to run my linter on all code, because we have existing lints in our codebase that we haven't fixed yet (so it fails anyway).

[ldez]

Hello,

I'm not sure how to fix that 🤔

Solutions:

1. reports an error
2. creates a fake diff using the API to get files (with pagination)
3. uses git to create the diff
4. ?

Solution 1 is a problem because you will have an error but you will never be able to "fix" this error, so your PR will be blocked forever.

Solution 2 is very complex: manually creating a diff is not trivial and it's brittle.

Solution 3 can work, but by default the action actions/checkout doesn't check out the full git tree (it only checks out 1 commit), so it will require adding fetch-depth: 0 to check out the full tree to be able to use git to create the diff. And, this is not an option that the golangci-lint action can control because it's an option from another action.

For now, I see no other solutions inside the golangci-lint action.

[lcarva]

Is it possible to create the diff from the locally cloned repo instead? A git diff between the PR and the target branch should do the job, no?

[ldez]

#996 (comment)

[lcarva]

@ldez my bad... missed your comment.

Solution 3 can work, but by default the action actions/checkout doesn't check out the full git tree (it only checks out 1 commit), so it will require adding fetch-depth: 0 to check out the full tree to be able to use git to create the diff. And, this is not an option that the golangci-lint action can control because it's an option from another action.

What if there was another parameter to the golangci-lint action, e.g. use-local-clone boolean? By default it is set to false which implies the current behavior. If it's set to true, then it just uses the local clone. It's up to users to make sure their local clone has the right depth. We could, however, have some sanity checks to help users along the way, e.g. if no diff is found, emit an error message that they should check the depth.

[ldez]

Please read once again my comment.

[lcarva]

Please read once again my comment.

Hmm I'm likely missing something. My suggestion was to just use the git clone as is. Leaving it up to users to make sure it was cloned in the expected manner. I am not, by any means, suggesting that golangci-lint controls an option from another action.