Renovate: Renovate applies golang 1.13 version redaction for updates

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

What Renovate type are you using?
App, installed via Github marketplace

Describe the bug
We haven't upgraded one of our Renovate-enabled repos to go 1.13 (on 1.12), and after the 1.13 release, renovate has started proposing upgrades with the go 1.13 version validation and redaction rules applied. I believe this will propose invalid PRs for anyone that hasn't upgraded to go 1.13 yet.

Did you see anything helpful in debug logs?
The bot comments with a helpful failure comment on the PR, so it was easy to see where things went wrong.

To Reproduce
A simple example is the golang.org/x/crypto package. Renovate just opened a PR with this change to the project go.mod:

require (
       ...
    github.com/urfave/cli v1.21.0
-   golang.org/x/crypto v0.0.0-20190801202406-4def268fd1a4
+   golang.org/x/crypto 227b76d455e7

I pulled down the branch that renovatebot created and ran go mod tidy. The relevant go.mod contents after that were now correct for a go 1.11/1.12 compiler with go modules enabled:

-       golang.org/x/crypto 227b76d455e7
+       golang.org/x/crypto v0.0.0-20190911031432-227b76d455e7

Expected behavior
For go 1.11/1.12 users, I'd expect the renovate bot to create valid PRs for the language version.

Screenshots
image

Additional context
The problem is, I'm not sure how/where to tell Renovate exactly what version of go we're using.

help wanted gomod priority-2-important bug

All 10 comments

Ok, so I don't actually think has to do with version redaction. So far, it looks like it's something weird with many (all?) of the golang.org/x/... packages. I'm fixing them, one by one, and the only theme I'm seeing is that they're all the packages under that path. Here's another one that just failed:

Command failed: docker run --rm -v /mnt/renovate/gh/datadotworld/dev-tools:/mnt/renovate/gh/datadotworld/dev-tools -v /tmp/renovate-cache/others/go:/tmp/renovate-cache/others/go -e GOPATH -e GOPROXY -e CGO_ENABLED=0 -w /mnt/renovate/gh/datadotworld/dev-tools renovate/go bash -c "git config --global url.\"https://x-access-token:**redacted**@github.com/\".insteadOf \"https://github.com/\" && go get"
go: golang.org/x/[email protected]: invalid pseudo-version: does not match version-control timestamp (2019-03-08T20:28:27Z)

go mod tidy doesn't seem to fix the problem, but I have been able to resolve it manually by removing the offending package from go.mod and re-running go mod tidy. I wonder if this is related to the new module proxy and checksum database that launched with 1.13 馃

We get the same error for golang.org/x/net package.

Thanks for the troubleshooting. As a first step I'll apply the changes suggested by @moorara in https://github.com/renovatebot/docker-go/pull/16

After that, I think it's important that Renovate can switch which version of Go it uses dynamically on a per-repo basis. We do this already for Ruby/Bundler so it's not a huge mountain to climb. The question is: how can Renovate tell which version of Go to use, by looking at the repo?

@rarkins For repos using go modules, the version of Go is specified in go.mod file.

@moorara yeah, that should be the right indicator, but AFAIK, you're unlikely to see it in a 1.11/1.12 module-enabled project. Starting with 1.13, go mod tidy adds that to go.mod. From what I can tell, all of these oddities are around the change from running the go dependency commands with 1.13 vs pre-1.13, instead of 1.11 versus 1.12 versus 1.13. AFAIK, 1.11 and 1.12 have no material differences in the domain that Renovate will be interacting with.

So, I suppose, in the absence of a go 1.13 line in go.mod, maybe renovate should run 1.12, otherwise run with the specified version found in go.mod.

Also, the issue title should probably be updated to reflect the real problem, to help guide others to the open issue, but I'm not exactly sure what I should re-title it. Go 1.13 renovate runtime potentially breaks existing pre-1.13 module-enabled projects ?

EDIT - I see @moorara already opened #4476 for the issue described below.


I just had Renovate rebase some PRs, now that https://github.com/renovatebot/docker-go/pull/16 is merged, but I'm still seeing the renovate/artifacts check fail with:

Command failed: docker run --rm -v /mnt/renovate/gh/datadotworld/dev-tools:/mnt/renovate/gh/datadotworld/dev-tools -v /tmp/renovate-cache/others/go:/tmp/renovate-cache/others/go -e GOPATH -e GOPROXY -e CGO_ENABLED=0 -w /mnt/renovate/gh/datadotworld/dev-tools 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/datadotworld/dev-tools is not a package in module rooted at /mnt/renovate/gh/datadotworld/dev-tools

Is there another build/deploy step that needs to happen before the changes in https://github.com/renovatebot/docker-go/pull/16 are rolled out to affect new/existing runs by Renovate?

@acmcelwee I think the ... is not a package in module rooted at ... is due to https://github.com/renovatebot/renovate/issues/4476 and not related to https://github.com/renovatebot/docker-go/pull/16

I opened #4483 for fixing the issue

The go get ./... syntax change should be live within the app within an hour or two maximum. I'll confirm here when done.

I also had the same impression that this is a go 1.13 vs pr-1.13 issue so defaulting to 1.12 may fix the majority of issues. I'm still working on that.

All fixes are confirmed, so closing this out. Thanks all, for the speedy resolution.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

ChristianMurphy picture ChristianMurphy  路  4Comments

Arcanemagus picture Arcanemagus  路  4Comments

kogai picture kogai  路  3Comments

Flydiverny picture Flydiverny  路  4Comments

hutson picture hutson  路  3Comments