https://pantsbuild.org/ logo
Join Slack
Powered by
Hello again, I'm trying to understand an issue I e...
# general
h
Hello again, I'm trying to understand an issue I encountered today in pushing a docker image on Jenkins Pipeline, where 
pants publish
returned an error "_denied: requested access to the resource is denied_" from docker-cli. Meanwhile a plain 
docker push
worked just fine. My Jenkinsfile wraps the 
pants publish
step inside withDockerRegistry. The urls specified in withDockerRegistry and in 
[docker.registry.private_name].address
are identical (though Pipeline plugin requires a protocol prefix whereas pants doesn't). In our Pipeline, we use a separate credentials to login and push the image and that account is different from the pipeline runner, i.e. 
$USER
. The last thing worth mentioning is that the docker images were built prior to entering withDockerRegistry, meaning that they were built under the name of 
$USER
. Am I doing something wrong perhaps?
đź‘€ 1
c
Hi, and thanks for the report. I’ll take a look see what I can find.
I think the issue is with not locating the 
~/.docker/config.json
properly. This may very well be a bug in our docker backend. I’ll investigate further, but it’ll be some time..
OK, I’ve double checked on a Linux (Ubuntu) system, that with a properly setup 
docker
client, 
./pants publish <docker-image>
works when running from the command line. (with properly setup here, I refer to there being a successfully issued 
docker login
for the registry you want to push to.) I’ve not had the opportunity to test running a Jenkins pipeline with the docker plugin you mention, but it feels like it could be in proximity there abouts. It should not matter which user built the image, however.
Meanwhile a plain 
docker push
 worked just fine.
Was this also executed from within the 
withDockerRegistry
step?
h
sorry for the late reply (slack is restricted in the firm…). Yes, the plain docker run is executed from within the “withDockerRegistry” step. Thanks for the hint about docker confit location, I'll add some diagnostics to check that on the Jenkins run.
đź‘Ť 1
@curved-television-6568 it turns out that the particular step exports DOCKER_CONFIG, which points to a different location than ~/.docker. I made a failed attempt to inject the environment variable via specifying [subprocess-environment].env_vars.add = […, “DOCKER_CONFIG”]. I guess I should specify that variable somewhere else but can't find any from the documentation. In the meantime, I can confirm that “pants publish” works by adding a symlink to $DOCKER_CONFIG
đź‘Ť 1
c
Could you try with https://www.pantsbuild.org/docs/reference-docker#section-env-vars If you provide just the name, it will pick the value from the environment invoking pants.
h
Thanks for the info! However, with -ldebug, I can't find the env being populated in docker push command, in fact I can't find docker push being wrapped unter any Process either . On the other hand, that env var does get populated in the docker build step. I'm using 2.8.0rc4.
c
Arrgh. You’re absolutely right. Sorry, my bad. That env is not passed to 
docker publish
but it should be (that was my intention, overlooked). Will fix, sorry for the trouble.
Regarding not seeing the process, I think that is due to it being an interactive process running in the foreground, so it isn’t logged the same as for other processes.
Pushed bugfix, waiting for it to land… will let you know when there is a rc out to try. (or try bleeding edge if you’re adventurous using 
PANTS_SHA
for a commit from 
main
, after it’s been merged)
đź‘Ť 1
h
Thanks for the quick turnaround! No trouble at all, it's also a great experience for me to trace the tool's diagnostics in more depth and learnt quite a bit. I'm happy to try the edge build when I get back to work tomorrow.
❤️ 1
c
@happy-pizza-30507 There's now a 2.9.0.dev2 out with this fix in.
đź‘Ť 1
h
Thanks @curved-television-6568 I have tried it and it looks good!
đź’Ż 1
c
Thanks, great 👍🏽
4 Views
Open in Slack
PreviousNext
Powered by