You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Sorry if this is not the right place to ask for this, but I'm desperate.
I have a Kubernetes cluster, and I created a pod with docker buildx create to build docker containers in the cluster.
I have a bunch of Python projects, each of which is associated with its own container. These containers contains only the dependencies: the source files are downloaded from S3 after the container is built.
I have a Python script inside every one of these projects that automates the building process by calling docker buildx build --bootstrap ....
Here is the problem: if this script explicitly imports the dependency that comes from out private repository, the build fails with this weird message:
#1 ERROR: error for bootstrap "kube30": Unauthorized
------
> [internal] booting buildkit:
------
ERROR: error for bootstrap "kube30": Unauthorized
where "kube3" is the name of the k8s pod.
However, if I comment out the import of this dependency (without removing it from the environment: everything stays the same except the code line with the import being commented out), the script works.
What's even weirder is that if I launch the docker buildx build --bootstrap ... command from the CLI, and not from the script, it works even when importing the dependency.
I've also tried using the library python_on_whales, and I get the same issue. Debugging the code, I've found out that the problem presents when trying to inspect the pod calling docker buildx inspect "kube3" --bootstrap.
I have no idea why this happens. Again, in my CLI everything works, but from the script, it breaks only when explicitly importing the dependency. I searched everywhere online but I haven't found answers. And the problem is not in the building process itself (which doesn't even start) but in inspecting the pod.
The text was updated successfully, but these errors were encountered:
Bootraping a builder instance and running a build are separate steps so this isn't influenced by whatever you are building. You can bootstrap builder with inspect or create command, and none of them take any build arguments.
If the problem is calling buildx binary from a different context (while for example buildx works for you when running from shell) then the issues might be related to different HOME or not having access to your credentials (depending on your credentials store).
Sorry if this is not the right place to ask for this, but I'm desperate.
I have a Kubernetes cluster, and I created a pod with
docker buildx create
to build docker containers in the cluster.I have a bunch of Python projects, each of which is associated with its own container. These containers contains only the dependencies: the source files are downloaded from S3 after the container is built.
I have a Python script inside every one of these projects that automates the building process by calling
docker buildx build --bootstrap ...
.Here is the problem: if this script explicitly imports the dependency that comes from out private repository, the build fails with this weird message:
where "kube3" is the name of the k8s pod.
However, if I comment out the import of this dependency (without removing it from the environment: everything stays the same except the code line with the import being commented out), the script works.
What's even weirder is that if I launch the
docker buildx build --bootstrap ...
command from the CLI, and not from the script, it works even when importing the dependency.I've also tried using the library
python_on_whales
, and I get the same issue. Debugging the code, I've found out that the problem presents when trying to inspect the pod callingdocker buildx inspect "kube3" --bootstrap
.I have no idea why this happens. Again, in my CLI everything works, but from the script, it breaks only when explicitly importing the dependency. I searched everywhere online but I haven't found answers. And the problem is not in the building process itself (which doesn't even start) but in inspecting the pod.
The text was updated successfully, but these errors were encountered: