Use the agent's ~/.dockercfg credentials doesn't stick

[Javier Perez]

Bamboo version: 6.5

Issue: When doing a docker push task configuration I select radio button Use the agent's ~/.dockercfg credentials and successfully save the task. However, when clicking back on the task configuration, bamboo has "reset" the option to Provide username and password. Not unexpectedly, the task execution fails with no basic auth credentials

Question: Why is this happening? How can I make bamboo accept the Use the agent's ~/.dockercfg credentials option?

Alternatively: Is it possible that the push task doesn't make a logout, so credentials are kept in .docker/config.json

[Gabriel Ribeiro · Accepted solution]

Hi @Javier Perez

I was able to reproduce the behavior and reported it as a bug: 

• Docker task - "Use the agent's ~/.dockercfg credentials" registry authentication type is not persisted

Please be sure to watch it, so that you are notified when this is fixed in a future release.

Thank you for reporting this.

[Javier Perez]

Thank Gabriel. Well, this is the third bug we find in this release :-(

Would you have an answer to my other question? Is it possible that the push task doesn't make a logout, so credentials are kept in .docker/config.json?

[Gabriel Ribeiro]

Hi Javier,

The problem is that If you specify the credentials as part of the docker push task, Bamboo will always logout once it's done executing the task. Thus it will remove credentials associated to that registry from the config.json file

On previous Bamboo versions, there was a possibility to leave the credentials section empty so that Bamboo would not send a docker logout when the task finishes its execution but, since Bamboo 6.4 this is not possible anymore.

thanks

[Javier Perez]

So, this is my problem. It happens that my Dockerfile has a FROM that is pulling from my docker registry. I also need to pass arguments in the docker build command

docker build --build-arg arg=bla

Since the docker build task type in bamboo doesn't support build parameters I need to use the docker build in a bamboo script type task. After the build, the image is pushed to the docker registry using the docker push task type. Since the docker push task removes credentials from config.json, the next build, when docker build is called, won't find the credentials in config.json (having been removed by the the bamboo docker push in the previous bamboo run) so my build fails.

What's the solution for this? Pushing to the docker registry using a script type task?

[Scott Moore]

We use Bamboo 6.9.2, and just ran into the same problem that Gabriel Ribero mentions above: "The problem is that If you specify the credentials as part of the docker push task, Bamboo will always logout once it's done executing the task. Thus it will remove credentials associated to that registry from the config.json file"

It took a long time for us to figure out the reason why seemingly random failures were happening.

Some of our build plans had "Use the agent's native credentials" selected (which I'm assuming is what used to be labeled "Use the agent's ~/.dockercfg credentials" in older versions) on their "Push a Docker Image" task. Other build plans had a specific user's credentials in it.

We also had a daily job that would run "docker login" to ensure that the the quay.io auth in .docker/config.json.

So the failure pattern was complicated:

• A job using a specific user's credentials would run, and work. But (unknown to us at the time) it would remove the native agent creds
• Any job that used a specific user's credentials to push would continue to work fine on that agent
• If a job using native agent credentials happened to run on that agent in between the jobs mentioned above, and before the daily login build, then it would fail

We lost a lot of time troubleshooting this.

Why would using a specific user's credentials cause the native agent's auth to be cleared?!! It makes no sense to me. Is this something that the Bamboo Docker task does, or does it happen down inside of a docker command that the Docker task triggeres?

Either way, it doesn't seem to make sense... for comparison: Say I'm a janitor that has access to all rooms in a building with a master key. Then some other employee uses their specific key that only works on Room 123 to unlock Room 123. The next time I use my master key on Room 123, I would still expect it to work!