The linter does not print line number nor filename

[jirihnidek]

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

The linter only print message of the error (e.g.: "Error: ineffectual assignment to err (ineffassign)")

As you can see here: https://github.com/RedHatInsights/yggdrasil/actions/runs/5012437362/jobs/8984386684?pr=124

It is really hard to find reason of such issue, because there is lot of variables names err. This github action also did not create any annotation in the related PR. Maybe this is the reason. When the annotation was not possible to create, then the output of the linter to stdout should still be useful.

I had to install the golangci-lint locally, and then I was able to see and fix the issue.

Version of golangci-lint

3.3.0

Version of the GitHub Action

Current

Workflow file

name: Lint

on: pull_request

jobs:
  lint-commits:
    name: Lint commits
    runs-on: ubuntu-latest
    steps:
      - name: Check out code
        uses: actions/checkout@v3
        with:
          fetch-depth: 0
          ref: ${{ github.event.pull_request.head.sha }}
      - uses: actions/cache@v3
        with:
          path: ~/go/pkg/mod
          key: ${{ runner.os }}-go-${{ hashFiles('**/go.sum') }}
          restore-keys: |
            ${{ runner.os }}-go-
      - run: go mod download
      - name: Run commitsar
        uses: aevea/commitsar@v0.16.0
  lint-code:
    name: Lint code
    runs-on: ubuntu-latest
    steps:
      - name: Set up go
        uses: actions/setup-go@v3
        with:
          go-version: "1.19"
      - name: Check out code
        uses: actions/checkout@v3
      - name: Run golangci-lint
        uses: golangci/golangci-lint-action@v3.3.0
        with:
          version: "latest"
          args: "--verbose"
  lint-language:
    name: Lint language
    runs-on: ubuntu-latest
    steps:
      - name: Check out code
        uses: actions/checkout@v3
      - name: Run woke
        uses: get-woke/woke-action@v0
        with:
          fail-on-error: true

Go version

1.19

Code example or link to a public repository

https://github.com/RedHatInsights/yggdrasil/actions/runs/5012437362/jobs/8984386684?pr=124

[jirihnidek]

Note: I don't have admin rights for https://github.com/RedHatInsights/yggdrasil Maybe there is something wrong in settings of this project, but I cannot see it. I only create PRs for this project.

[gzurowski]

As described in the documentation:

[...] the action creates GitHub annotations for found issues: you don't need to dig into build log to see found by golangci-lint issues

Therefore, you don't need to look into the build log details. Instead you just need to look at the Files Changed tab to review the issues found by golangci-lint.

[jirihnidek]

As described in the documentation:

[...] the action creates GitHub annotations for found issues: you don't need to dig into build log to see found by golangci-lint issues

Therefore, you don't need to look into the build log details. Instead you just need to look at the Files Changed tab to review the issues found by golangci-lint.

I agree, but when annotations were not created (for some reason), then you try to find the reason of lint error in build log, and the build log should still be useful in such case.

[gzurowski]

I initially also got confused by the lack of detailed file/line output in the build logs, but realized that the annotations provide a much richer experience. But I admit that this is not sufficient when something prevents from creating those annotations in Github.

[jirihnidek]

I think that more details in log could be also useful in situation, when you have to deal with big PR with lot of comments. It is easier to view one linter error in log then trying to find one annotation between many comments in long PR.

[rohantmp]

I would like to vote for this issue as well

[simongibbons]

I would be in favour of having both

[ldez]

duplicate of #458