What Renovate type are you using?
We're using the SaaS version of Renovate from GitHub marketplace.
Describe the bug
For repositories that they are just library, are imported in other repos, and don't have a main package in root level, Renovate will give the following error:
Command failed: docker run --rm -v /mnt/renovate/gh/moorara/observe:/mnt/renovate/gh/moorara/observe -v /tmp/renovate-cache/others/go:/tmp/renovate-cache/others/go -e GOPATH -e GOPROXY -e CGO_ENABLED=0 -w /mnt/renovate/gh/moorara/observe renovate/go bash -c "git config --global url.\"https://x-access-token:**redacted**@github.com/\".insteadOf \"https://github.com/\" && go get"
go get .: path /mnt/renovate/gh/moorara/observe is not a package in module rooted at /mnt/renovate/gh/moorara/observe
Here is another example:
Command failed: docker run --rm -v /mnt/renovate/gh/***/**:/mnt/renovate/gh/***/** -v /tmp/renovate-cache/others/go:/tmp/renovate-cache/others/go -e GOPATH -e GOPROXY -e CGO_ENABLED=0 -w /mnt/renovate/gh/***/** renovate/go bash -c "git config --global url.\"https://x-access-token:**redacted**@github.com/\".insteadOf \"https://github.com/\" && go get"
go get .: path /mnt/renovate/gh/***/** is not a package in module rooted at /mnt/renovate/gh/***/**
Did you see anything helpful in debug logs?
To Reproduce
Steps to reproduce the behavior:
Expected behavior
No error and Renovate should update Go repositories with no package at root successfully.
Screenshots
Additional context
It seems like the go get behaviour has changed. If you run go get within the root do you observe the same - i.e. it works in Go 1.12 and fails in Go 1.13?
@rarkins Yes, with Go 1.13 if I run go get . from the root I get the same error.
I think go get . only refers to package in current directory and the right command should be go get ./... which means current directory and all sub-directories.
FYI the relevant file in source is here: https://github.com/renovatebot/renovate/blob/master/lib/manager/gomod/artifacts.ts
Today we actually just run go get without any . at all. Do you know if go get ./... is backwards compatible with older go versions too?
@rarkins AFAIK, the three-dot wildcard has been valid from the very beginning, or at least very early on. https://golang.org/cmd/go/#hdr-Package_lists_and_patterns
Example:
$ GO111MODULE=on /usr/local/Cellar/[email protected]/1.11.13/libexec/bin/go get ./...
$ GO111MODULE=on /usr/local/Cellar/[email protected]/1.12.9/libexec/bin/go get ./...
:tada: This issue has been resolved in version 19.43.1 :tada:
The release is available on:
Your semantic-release bot :package::rocket:
This is now live in the app. Can you try rebasing an existing PR and seeing if it is fixed?
@rarkins I can confirm this problem is fixed for us.
Thanks for your quick actions. Very much appreciated it.
Thanks for your help solving it!
馃憤 all good on our end, too. Thanks @rarkins!
Most helpful comment
@rarkins AFAIK, the three-dot wildcard has been valid from the very beginning, or at least very early on. https://golang.org/cmd/go/#hdr-Package_lists_and_patterns
Example: