This repository has been archived by the owner on Jun 25, 2022. It is now read-only.
Check for go.mod when searching for files.
#236
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
It appears that `GoFiles` from [`Package`](https://godoc.org/go/build#Package) is _NOT_ module aware. Therefore the check in `v2/jam/parser/finder.go:87` would always return and not find files. The only way in which I think we can reliably check if a project is using modules is to check for the presence of `go.mod` in the package root. Thus, I have added the guard to check for `go.mod` before we rely on `pkg.GoFiles`.
|
Whats the status of this? |
v1r7u
added a commit
to deepnetworkgmbh/joseki
that referenced
this pull request
Feb 4, 2020
DISCLAIMER: I haven't found a way to run the service in bare-bone alpine container. polaris keeps a part of runtime needed configuration in yaml files. These files are embedded into polaris binaries with gobuffalo/packr The problem is, packr is not able to embed files from referenced modules gobuffalo/packr#236 To overcome the issue, polaris-scanner is built and is running from the same golang container golang:1.13.7-alpine3.11 using CGO_ENABLED=1 If produced binary is copied to bare-bone alpine container - it's not visible, due the problem described in SO question https://stackoverflow.com/q/34729748/1952990 I tried both options from SO question: nor symlink, neither CGO_ENABLED=0 helps, because of the initial packr issue
v1r7u
added a commit
to deepnetworkgmbh/joseki
that referenced
this pull request
Jul 24, 2020
DISCLAIMER: I haven't found a way to run the service in bare-bone alpine container. polaris keeps a part of runtime needed configuration in yaml files. These files are embedded into polaris binaries with gobuffalo/packr The problem is, packr is not able to embed files from referenced modules gobuffalo/packr#236 To overcome the issue, polaris-scanner is built and is running from the same golang container golang:1.13.7-alpine3.11 using CGO_ENABLED=1 If produced binary is copied to bare-bone alpine container - it's not visible, due the problem described in SO question https://stackoverflow.com/q/34729748/1952990 I tried both options from SO question: nor symlink, neither CGO_ENABLED=0 helps, because of the initial packr issue
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
It appears that
GoFilesfromPackageis NOT module aware. Therefore the check inv2/jam/parser/finder.go:87would always returnand not find files. The only way in which I think we can reliably check
if a project is using modules is to check for the presence of
go.modin the package root. Thus, I have added the guard to check for
go.modbefore we rely on
pkg.GoFiles.This should address #195 and #228