dnephin/pre-commit-golang

go-vet does not work if Go code is not in the root folder

talha131 opened this issue · 8 comments

talha131 commented

go-vet script, first runs go list in the root directory. It fails if it does not find go files.

In my case, I have multiple related projects in the same repo. Something like this

.
├── LICENSE
├── README.md
├── backend
└── frontend

I need go-vet to only run the backend folder. But the way script works, it is not possible.

One way is to infer the directory from the staged files. Or add option to pass dir in the argument to the hook.

davidpfarrell commented

I'm experiencing a similar issue with both the go-vet and go-build scripts.

At least the vet script tries to get a list. The build script currently does not.

What would you think to :

  1. Modifying the go-vet script to do go list ./... instead of just go list
  2. Add the same functionality to the go-build script

?

I could create a separate issue for the go-build mod to keep changes clean.

BTW: I currently get around this issue by having a doc.go file in my root folder. This allows vet and build to succeed and continue into sub-folders. Not sure if there are any negative side effects to having it and in fact it gives me a chance to give a quick description of the repo, so I kinda like it (although I would prefer the scripts work without it)

  • 👍3
treuherz commented

Is there a reason running go vet ./... wouldn't work? If that command doesn't fail fast on finding an error then I'd agree with @davidpfarrell's solution of looping over the output of go list ./...

  • 👍1
davidpfarrell commented

Hi @treuherz ,

I discovered the issue overall to be more nuanced, what with gopath vs modules and single-package-repos vs multi-package repos.

Inspired by @dnephin 's work, I ended up developing a new set of hooks that tries to offer more support for various project setups:

If you had some time to try it, I'd love to hear if it worked any better for your project's setup?

  • 👍4
  • ❤️1
treuherz commented

That's excellent, @davidpfarrell, it solves the problem perfectly. The hooks that only run against the modules of staged files are great to see as well, a very helpful improvement.

rupamkhaitan commented

@davidpfarrell what is your suggestion for doc.go? How to make go build work? What do you write inside doc.go? Is it a blank file?

i raised another issue for go build not working #50

davidpfarrell commented

@davidpfarrell what is your suggestion for doc.go? How to make go build work? What do you write inside doc.go? Is it a blank file?

i raised another issue for go build not working #50

Hi @rupamkhaitan ,

Here's the doc.go referenced in my comment:

I think at the time it just contained the package declaration and that's all it needed in order to work with these hooks.

your new repo is very useful, i am also moving to this one
Thanks for the note. Looking at your code sample in #50 you'll likely want to use the *-mod hooks, which will apply the hooks to the module root folder of changed files.

Good luck!

rupamkhaitan commented

@davidpfarrell yes i am using your repo and running my build by passing custom tags.. and everything works.. I dont really understand the diff between go-build-mod & go-build-repo-mod (and -pkg ones is for old strcuture??)

 - id: go-build-mod
        always_run: true # Run even if no matching files staged
        args: ["-tags", "e2e"]