go private deps error on 1.3.0 #136
Comments
|
We changed to build this image using Renovate's open source "buildpack" rather than a custom build, so that could be a cause. But it could also potentially be a regression from Renovate OSS that hasn't been noticed by anyone using it. Please confirm if the following is correct?
|
Correct.
That would be typical, and I can confirm that in this case, the dependency itself also has Renovate install, but I can't guarantee that this is always the case. However, the token that Renovate is using should have access to the dep, and again, this was working before the buildpack changes. |
I would like us to elaborate on this point. If you are running on github.com, it is our assumption that the same app token is used for accessing other private github repos. The only way "the token that Renovate is using should have access to the dep" is if the dep is in a repo which has Renovate installed. But you write "I can't guarantee that this is always the case". Are you configuring some other github.com token somehow? |
We have the token |
|
I agree with you re: the token, but now I'm confused how this ever worked, because I would not expect it to work. Let me step you through my logic, tell me if you spot anything mistaken:
So the only answers I see are:
|
|
Assuming all the private deps do have the renovate app enabled, does all of that hold still? I can do some more research, but fairly confident it worked before.
we are directly using the renovate built Docker image. Renovate itself updated it from 1.2.0 to 1.3.0, and nothing else in the kube deployment should have changed. |
The above all holds, which means I'm not sure how it could have ever worked. The same logic applies to Renovate OSS btw. @viceice am I missing anything on the way go modules with private repos works? Please see above
FYI Go changed from 1.15.6 to 1.16.2 between releases, although I have no reason to believe that would change anything related |
|
I've got it now... we're using a mounted ssh config for private deps. So there's no token, but we've configured ssh to handle the private go packages. So it's possible that the feature adding support for this (or some other unrelated change) is actually the issue. Would it cause any issues with other parts of renovate to configure git to use ssh instead of https? Is there a way to do this that won't affect other aspects of Renovate's operations? |
|
who and where do you mount the ssh config? @rarkins What base image was used before? I assume it was ubuntu 18.04 ? So maybe it's a ssh change in ubuntu? Or maybe a ssh strictness because of the |
|
We’re doing roughly what’s outlined in the examples in the docs (https://docs.renovatebot.com/self-hosting/). Based on the error, it would seem like git is preferring http vs ssh.
@rarkins: So, while we're not running it during build, we are also dropping in a so you're somewhat right on this point (the ssh config and gitconfig explain how it worked before, that is). I can try to troubleshoot it a bit more when I get a chance. ssh permissions should be correct.
|
|
@wyardley Can you build acustom renovate image and test? FROM whitesource/renovate:1.3.0
USER root
RUN install-tool golang 1.15.10
USER 1000This should override / downgrade golang, so we can make sure it's not a golang issue. |
Yes, it went from Ubuntu 18.04 in 1.2.0 to Ubuntu 20.04 in 1.3.0 via the buildpack v4 |
@rarkins: if I update go to 1.15.10 using your Dockerfile example above, it appears to resolve the problem, and verified that if I redeploy vanilla 1.3.0, I get the same artifact error. Another interesting bit - at least for an existing PR, That said, if I exec in and directly run go 1.16, it seems to work as well (slightly sanitized) (maybe because it's already cached, but does still work if I run |
update = downgrade in this case, right? What if you were to build the following? and then: Essentially I want to rule that it's not the act of reinstalling that's triggering 1.15.10 to work for you, rather than 1.15.10 vs 1.16.2. |
Sorry, yes. Building the first option gives something like I can try pushing / deploying if you want, but guessing that won't work since it's already not doing anything in that step? The second: RUN install-tool golang 1.15.10
RUN install-tool golang 1.16.2does seem to work for me I don't think it matters, but if I exec the container locally, neither go is in my |
|
When you say the second works, do you mean the build works or the original problem of private repos is solved? The container uses this entrypoint which sources the ENV: https://github.com/renovatebot/docker-buildpack/blob/master/src/base/bin/docker-entrypoint.sh. I'm not sure if exec follows the entrypoint? If not then it would explain the lack of path |
Both - the build works, and if I run it, the original problem of private repos is solved. |
|
That is incredibly weird. I'm going to rebuild 1.3.0 (same Dockerfile) and push an updated image to Docker Hub just in case it was a bad build affecting Go-only. |
|
Agree that it's incredibly weird; I did try flipping back and forth a couple times, and fully deleting all the kube resources to make sure it wasn't a weird transient issue with a volume mount or something (also verified that the ssh config / git config were there). The good news is that I have my (hopefully temporary) self-built version that's fixing not only this issue, but the one mentioned in renovatebot/docker-buildpack#96, so can run with that for a while. |
|
I've rebuilt and pushed. Also checked the build log for Go in particular: install-tool golang 1.16.2 |
|
So the issue seems to be that the new one has the user set to root rather than ubuntu? Is that final Maybe this is the actual issue? Is this intentional? Do I need to explicitly set the securitycontext for the deployment? |
|
@rarkins did you miss the last |
❯ git diff
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
modified: Dockerfile
────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
@ Dockerfile:125 @ CMD [ "node", "src/server.js" ]
EXPOSE 8080
USER $UBUNTU_ID
USER $USER_ID:( |
|
I've pushed that change again to Docker Hub and hope that fixes it. Thanks for everyone's help |
|
Thanks! |
After updating our on prem install from 1.2.0 to 1.3.0, I'm getting the following error on private go deps (we're using GHE, but it's github.com, i.e., regular cloud hosted GH, using a token). Prior to this update, updating go private deps was functioning.
This is running in Kubernetes, and we do have
GOPRIVATEset in the environment togithub.com/myorg. We also haveGITHUB_APP_KEYandGITHUB_APP_IDset in the environment.Any suggestions on what could be causing this or a possible fix?
The text was updated successfully, but these errors were encountered: