Private Go module lookup fails in versions >41.66-full even with GOPRIVATE set #37624
Replies: 5 comments 5 replies
-
|
The logs show that Renovate correctly detects the Go module import path via GONOPROXY, but when resolving versions it queries the GitLab API with a truncated path (group/project instead of group/project/libs/lib-a). This mismatch results in 404 errors during tag lookup. |
Beta Was this translation helpful? Give feedback.
-
|
the root cause of this issue is due to #37647, renovate does not use the go get tool itself |
Beta Was this translation helpful? Give feedback.
-
|
Pretty sure this is a result of #36963. Version A similar change has previously been reverted (#31055) because it caused this (similar) issue, as discussed in #30886. Related issue: #28540 |
Beta Was this translation helpful? Give feedback.
-
|
Would be keen to understand this a bit better, so I can try to reproduce. In the example above, am I right to assume you've got this structure in gitlab? What does your renovate config look like? I've not been able to dig into this fully yet however my guess is it might be to do with how gitlab handles authenticated / unauthenticated go-get requests. E.g. I setup this structure in gitlab which unauthenticated returns: curl 'https://gitlab.com/tmptest1/group/tmp?go-get=1'
# <html><head><meta name="go-import" content="gitlab.com/tmptest1/group git https://gitlab.com/tmptest1/group.git"></head><body>go get gitlab.com/tmptest1/group</body></html>go get gitlab.com/tmptest1/group but authenticated returns: go get gitlab.com/tmptest1/group/tmp If that's the root cause then adding a hostRule to the config should resolve it |
Beta Was this translation helpful? Give feedback.
-
|
We were using Trying it with DEBUG: Datasource 404 (repository=group/subgroup/projecta)
"datasource": "go",
"packageName": "gitlab.example.com/group/subgroup/projectb",
"url": "https://gitlab.example.com/group/subgroup/projectb?go-get=1"
DEBUG: Failed to look up go package gitlab.example.com/group/subgroup/projectb (repository=group/subgroup/projecta, packageFile=go.mod, dependency=gitlab.example.com/group/subgroup/projectb)Running curls both authenticated and unauthenticated shows same results as you provided, authenticated curl uses same creds as given to Renovate: Unauthenticated curl❯ curl -i 'https://gitlab.example.com/group/subgroup/project?go-get=1'
HTTP/2 200
<html><head><meta name="go-import" content="gitlab.example.com/group/subgroup git https://gitlab.example.com/group/subgroup.git"></head><body>go get gitlab.example.com/group/subgroup</body></html>Authenticated curl❯ curl -iu "gitlab-ci-token:REDACTED" 'https://gitlab.example.com/group/subgroup/project?go-get=1'
HTTP/2 200
<html><head><meta name="go-import" content="gitlab.example.com/group/subgroup/project git https://gitlab.example.com/group/subgroup/project"></head><body>go get gitlab.example.com/group/subgroup/project</body></html>Since DEBUG: GitLab API 404 (repository=group/subgroup/projecta)
"url": {}
DEBUG: Datasource 404 (repository=group/subgroup/projecta)
"datasource": "go",
"packageName": "gitlab.example.com/group/subgroup/projectb",
"url": "https://gitlab.example.com/api/v4/projects/group%2Fsubgroup/repository/tags?per_page=100"
DEBUG: Failed to look up go package gitlab.example.com/group/subgroup/projectb (repository=group/subgroup/projecta, packageFile=go.mod, dependency=gitlab.example.com/group/subgroup/projectb)incorrect URL: Although it's not much I hope this still sheds some light on the issue we have, if I've got some more time I'll dive into it to get some more info, or might debug Renovate locally to see what's going on. |
Beta Was this translation helpful? Give feedback.
-
|
Took a bit of a deeper look today just to try build up a better mental model of how this works. I'm fairly confident my initial hunch is right although the PR definitely would broke clients that didn't have a go hostType setup and had a repo with the group/subgroup/project structure. I do think this is the correct behaviour though (and the only way to make all the different repo structures work). Based on what you've sent I still think the most likely cause is that it's still not making the authenticated request. One thing that did catch me out when investigating was using "token" instead of "username" + "password" for the go hostType. I think it's required because go only supports basic auth for these requests https://docs.gitlab.com/development/go_guide/dependencies/#authenticating). If you specify a token, I think the behaviour is to add a Bearer auth header which isn't supported. Happy to dig further but would need more information about the setup (config, repo structure, etc.) |
Beta Was this translation helpful? Give feedback.
-
|
Ah thanks for your reply, we previously used username + token instead of password. Moving to |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for looking into this in more detail. The structure in my case is exactly like this: where app-x is the actual repository containing the code. Regarding the configuration: I have platform = "gitlab" with token-based authentication enabled. For Go specifically, I haven’t added any special settings in the Renovate config. What I do set are the Go-related environment variables (GOPRIVATE, GONOPROXY, etc.) in the Docker image This configuration works without any issues on Renovate version 41.66, where it successfully resolves both private and public libraries. |
Beta Was this translation helpful? Give feedback.
-
|
The change that broke this for you would have been in Although it broke some clients, I do think it's correct behaviour. To summarise, there's a few scenarios that need supporting. Prior to the change only gitlab go packages which were created at the root of a repository would have been correctly fetched because renovate wasn't using the go-get metadata (which is how go works it out). The change means that the repo path used to generate the project name when looking up tags is coming from the go-get metadata instead of being assumed to be the full package path. If the repo is private, and the go-get request is made unauthenticated, gitlab returns something but it's incorrect (which is why you're likely seeing issues after the update). If it's authenticated, it'll provide the correct path to the repo. I'd probably have flagged as breaking had I spotted the issue before - although I do think this is the correct way. At this point, not too sure what the best course of action would be - might be useful to get a steer from a maintainer. I'm wondering if there's a way to make the go datasource a bit smarter when calling gitlab and use the token that's present (if there is one) ensuring it's using basic auth as required by the go-get api. That would at least prevent trip ups if someone hasn't defined a go hostRule. Alternatively, it might just need better documenting. For your issue, I think it'd be resolved if you add something like this to your config: |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for the detailed explanation — I understand the reasoning and can follow the logic behind the change. It also makes sense now why those error messages appeared after the update. I’ve added the hostRule for GitLab in my config, and after some initial tests everything looks good: no more errors, and Renovate resolves everything correctly. Maybe it would be useful to include this in the documentation as well, so it’s clearer how this works and how Renovate handles these cases. Thanks! |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
How are you running Renovate?
Self-hosted Renovate
If you're self-hosting Renovate, tell us which platform (GitHub, GitLab, etc) and which version of Renovate.
GitLab
Please tell us more about your question or problem
Hello,
since upgrading to Renovate Docker images >41.66-full (tested with 41.76-full), Renovate fails to resolve private Go modules hosted in our internal GitLab/Artifactory repositories.
Even when GOPRIVATE, GONOPROXY, and GONOSUMDB are explicitly set, the resolution fails. This differs from 41.66-full, where private modules were resolved correctly.
The behavior appears misleading with Go 1.25: Go itself honors the env vars, but in Renovate containers >41.66-full, private modules cannot be fetched anymore, suggesting the problem is likely related to the image environment or how Renovate invokes Go commands internally.
Logs (if relevant)
Logs
Beta Was this translation helpful? Give feedback.
All reactions