Renovate: Renovate with Go 1.13 cannot update library repos without main package

Created on 12 Sep 2019  路  9Comments  路  Source: renovatebot/renovate

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:

  1. Create a Go repository with sub-directories and not package at root
  2. Trigger Renovate to update one the go modules

Expected behavior

No error and Renovate should update Go repositories with no package at root successfully.

Screenshots

Additional context

help wanted gomod priority-3-normal bug

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:

$ 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 ./...

All 9 comments

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!

Was this page helpful?
0 / 5 - 0 ratings

Related issues

jgarec picture jgarec  路  3Comments

rarkins picture rarkins  路  3Comments

Arcanemagus picture Arcanemagus  路  4Comments

hutson picture hutson  路  3Comments

amilajack picture amilajack  路  3Comments