Open mblayman opened 2 months ago
kamal build push
when run by itself doesn't try to login to the docker registry so whether it succeeds or not depends on whether you are logged in already. The docker version of the command won't be.
kamal deploy
it will log you in to docker hub so that does work from within Docker.
Thank you, @djmb! This makes sense to me. Is this by design?
I'm new to kamal so I'm trying to determine some of the philosophy around working with the tool. I like to ease into a new tool by working incrementally. Because of that preference, I attempted to do what I consider the first half of the flow (i.e., create an app/kamal setup that uploads an image artifact to a registry).
My next goal was to move into using that artifact on a cloud host.
It sounds like the only way to have that approach currently is to use the non-Dockerized version of kamal (which is fine by me). Is the intent to have the Dockerized version work at parity with the non-Dockerized version? Or will there always be some limitations around the Dockerized version that should be documented?
tl;dr -
kamal build push
failed to auth with Docker Hub when using the macOS alias, but it succeeded when I rankamal
via a local gem install on the host OS.Notably, the local gem install run includes a couple of
[auth]
steps that were not visible in the previous run that used the macOS alias.Context:
"credsStore": "desktop"
I am using
kamal
from the macOS alias ofthat is listed in the install docs. After preparing an app, my demo repo at https://github.com/mblayman/kamal-demo was failing when I tried to send the image to Docker Hub using
kamal build push
. I was authenticated already and proved that I was authenticated by pushing an alpine image to https://hub.docker.com/repository/docker/mblayman/kamal-demo/general to convince myself that my auth was valid.When running
kamal build push
, I had a log like (trimming some of the less relevant bits):All the details are viewable via the stream where I did this live at https://www.youtube.com/live/mJPSSUVL4qw
This evening (24 hours later), I restarted the machine (since I had just installed Docker in the same session as kamal), re-ran
kamal build push
, and confirmed that I still had the same behavior.Then I proceeded to install
kamal
via the brew installed version of Ruby. I repeatedkamal build push
and it succeeded with no modifications to any configuration files or files in the demo repo!Here is the relevant log:
Notably, this run includes a couple of
[auth]
steps that were not visible in the previous run that used the macOS alias.My best working theory is that the Dockerized version of kamal did not have access to the auth information that was set on the host OS, but I don't know the inner workings of kamal. I hope this report helpful.