Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Setting workdir breaks GitHub action annotations #31

Closed
nkansal96 opened this issue Jul 4, 2020 · 7 comments
Closed

Setting workdir breaks GitHub action annotations #31

nkansal96 opened this issue Jul 4, 2020 · 7 comments
Labels
area: annotations bug Something isn't working

Comments

@nkansal96
Copy link

I have a project that supports multiple languages, and all of the go code is in a well-behaved subdirectory:

- frontend
- proto
- secrets
- gocode
  - go.mod
  - go.sum
  - cmd
    - server
      - main.go

I configured the golangci-lint-action as such:

jobs:
  lint:
    name: "Lint"
    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    
    # Runs a set of commands using the runners shell
    - name: Lint
      uses: golangci/golangci-lint-action@v1
      with:
        version: v1.26
        working-directory: gocode

I am using the default .golangci.yml configuration file. I tested a change that should fail the linter and I get the error correctly in the GitHub actions format:

##[error]func `unused` is unused (unused)

However, the error doesn't show up as an annotation on the pull request. Upon further investigation, it seems like the real out (from running locally) is this:

~/Projects/shepherd/gocode
.venv ❯ ~/go/bin/golangci-lint run --out-format github-actions
::error file=cmd/server/main.go,line=5,col=6::`unused` is unused (deadcode)

The problem appears to be that the file is outputted relative to the working directory and not the root of the GitHub repository (i.e. the path should be gocode/cmd/server/main.go) which seems to be preventing GitHub from correctly handling this.

This appear to be a bug. Can this be fixed with an option of some kind? Or is there an existing option that handles this case?

@sayboras sayboras added bug Something isn't working help wanted Extra attention is needed labels Jul 4, 2020
@sayboras
Copy link
Member

sayboras commented Jul 4, 2020

@nkansal96 It seems like a bug to me. working-dir is passed as shell cwd while running golangci-lint. We can try to somehow append it into golangci-lint output. Another alternative option is to support path to config file (--config like golangci-lint) and always run scanning from root directory.

Need your input on second option as well, is there any reason/issue if you try to run from root directory ? or you just want to keep .golangci.yaml inside gocode directory ?

@nkansal96
Copy link
Author

Thanks for the quick response @sayboras

The .golangci.yml is already in the gocode folder, so it is not an issue with the config file path. In any case, this can be set through args I believe.

I also tried running golangci-lint in the root directory, but ran into issues due to the fact that go.mod is not present in the root of the repository. If I move the go.mod file outside of the gocode subdirectory, then things work as expected. I would prefer not to pollute the top-level of the project though (though I will accept this as a solution if nothing else is possible).

One option here is to add a flag to golangci-lint run such as --path-prefix, or to the config yaml, pathPrefix, which prepends the prefix to all paths?

@jwilner
Copy link
Contributor

jwilner commented Jul 10, 2020

@nkansal96 you should find my above PR helpful (I know I do)

@nkansal96
Copy link
Author

@jwilner Awesome! Thank you for making the contribution :)

@SVilgelm
Copy link
Member

It would be great it the action will automatically set path-prefix parameter if the workin-directory set
after the pull request golangci/golangci-lint#1226 is merged

@jwilner
Copy link
Contributor

jwilner commented Jul 10, 2020

@SVilgelm that would make sense to me if we can be sure that there are no existing usages of working-directory that we'd be breaking -- and maybe this was added so recently and doesn't really work without it, so we're safe on that front?

@SVilgelm
Copy link
Member

Fixed in #34

@ldez ldez added area: annotations and removed help wanted Extra attention is needed labels May 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area: annotations bug Something isn't working
Projects
None yet
Development

No branches or pull requests

5 participants