-
-
Notifications
You must be signed in to change notification settings - Fork 80
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
go: go.mod file not found in current directory or any parent directory #109
Comments
Do you have an example repo that I could try this on? |
I don't but thanks for asking. If I can't sort this maybe I can craft one. I'm wondering if it is related to any of this new 1.16 changes: https://blog.golang.org/go116-module-changes. Interestingly, if I run with |
Found the issue , tiny PR coming. The change is specific to a local build. |
The issue is resetting I don't have permissions to post a PR. This is the diff:
|
1.15 worked because I had GOPATH set. |
Awesome, thanks :) Let me try to put this together as a PR. |
Do have an idea when this might merge? We have obviously a working forked version but it would make our builds easier when this is updated. Thank you ! |
Hi @techknowlogick @rleighton I've hit this issue too -- seems to be a 6 line fix. I'd push a PR but don't have the permissions. Here's a git patch:
|
any news? |
@techknowlogick ping? |
I'm seeing same issue in our WriteFreely project... Running this command produces the same error, despite there being a
Not sure if we need to change the command, or if this is a bug in |
@thebaer It's a bug in xgo. You can use the patch above, or just run xgo with go1.15 instead of 1.16. |
Thanks! Adding |
This forces xgo to use Go 1.15, to work around a bug with Go modules: techknowlogick/xgo#109 (comment) This also uses the correct Darwin and Windows binary names to prevent failures in the `make release` process.
I am not sure if related, but I ran into issues with xgo and go 1.16 that requires ARG GOVERSION=1.16.0
FROM techknowlogick/xgo:go-${GOVERSION}
# https://github.com/techknowlogick/xgo/issues/104
RUN go env -w GO111MODULE=auto And during build process: docker build -f release/xgo.Dockerfile -t dgraph/xgo:go-${GOVERSION} --build-arg GOVERSION=${GOVERSION} .
export XGO_IMAGE_OPT="-image dgraph/xgo:go-${GOVERSION}"
xgo -x -go="go-$GOVERSION" --targets= linux/$GOARCH $XGO_IMAGE_OPT -buildmode=exe . |
I've just created #121 using the patch above, and will merge it hopefully once tests pass. |
Test case fails. See PR for more details. |
Would really appreciate getting this in, causing me a lot of pain at the moment! |
* gomod fixes for go1.16 patch from: #109 (comment) * Update test_pr.yml * Update test_pr.yml * kludge * re-enable eth smoke * Update xgo.bats * apply feedback from Z
Closing as linked PR has now been merged. Will be a sec before CI builds/publishes the new images. |
This still fails for the ethereum/go-ethereum test case. More so it thinks it passes but produces an incorrect binary.
|
Yeah, I updated to the latest image and it still produces the same error for me ( |
oh darn, thanks for letting me know. I've reopened this so I can look into it. |
ok, I've been looking at this a bit. I was missing a bit of the puzzle, https://github.com/techknowlogick/xgo/blob/main/xgo.go#L261 looks to see if the directory that is passed has a go mod, however as mentioned above this fails for the geth case (where the go.mod file is in a parent). From my debugging the reason for that is /tmp/eth/cmd/geth is the path mounted into the container, not /tmp/eth (which is the directory with go.mod). I suspect that using |
So... has this been resolved? I see references to 1.18 and 1.19 in the commits. |
This PR substantially restructures the xgo dockers creating a separate toolchain container, go-version container and then a merged container with the build.sh and xgo. This should in future allow for more caching and allows pr test cases to avoid rebuilding the whole toolchain. In doing this I've noticed and fixed a number of bugs: 1. Yet another bug relating to remote paths that would cause a #181 and #109 2. The default naming for "packages" on module builds is incorrect and unhelpful. (#174) The default name will now be: modulename/pack-... 3. Use mkdir -p /deps instead of /deps to permit reuse of the /deps dir Fix #174 Fix #181 Fix #164 Fix #109 Signed-off-by: Andrew Thornton <[email protected]>
I get:
However:
The command:
Any ideas?
This worked with go 1.13 but now I have to move to 1.16 because of other changes in the code base.
The text was updated successfully, but these errors were encountered: