Pushing images to dockerhub stopped working #1209

gebi · 2020-04-23T18:35:13Z

Actual behavior

Kaniko exits with exit code 1 with the following message and and does not build the image:

error checking push permissions -- make sure you entered the correct tag name,
and that you are authenticated correctly, and try again: checking push permission for
"foo/bar:bionic-99": UNAUTHORIZED: authentication required; [map[Action:pull Class:
Name:mgit/clamav Type:repository] map[Action:push Class: Name:foo/bar Type:repository]]

This worked with the same build pipeline and no changes 3 months ago with the following image:

Using Docker executor with image gcr.io/kaniko-project/executor:debug ...
Pulling docker image gcr.io/kaniko-project/executor:debug ...
Using docker image sha256:2aa254b4837c242c7de87956438eaba70f97a2768ab0870819fd20e09df15cf6 for gcr.io/kaniko-project/executor:debug ...

Expected behavior

Kaniko to upload image to dockerhub like the version 3 months ago was able to.
There where no changes, and it works if i go back to an older kaniko version.

To Reproduce
Steps to reproduce the behavior:

... with the following pseudo .gitlab-ci.yml

image:
  name: gcr.io/kaniko-project/executor:debug
  entrypoint: [""]

stages:
  - foo

build-foo:
  stage: foo
  script:
    - echo "{\"auths\":{\"index.docker.io\":{\"auth\":\"${CI_DOCKERHUB_AUTH}\"}}}" > /kaniko/.docker/config.json
    - >
      /kaniko/executor --context "${CI_PROJECT_DIR}/foo" --dockerfile "${CI_PROJECT_DIR}/foo/Dockerfile"
      --destination foo/bar:blub-${CI_PIPELINE_IID}"
      --destination foo/bar:blub"

... build it

Additional Information

Dockerfile
Please provide either the Dockerfile you're trying to build or one that can reproduce this error.
Build Context
Please provide or clearly describe any files needed to build the Dockerfile (ADD/COPY commands)
Kaniko Image (fully qualified with digest)

Using Docker executor with image gcr.io/kaniko-project/executor:debug ...
Pulling docker image gcr.io/kaniko-project/executor:debug ...
Using docker image sha256:2ec307dcf7f52dcf700ea0fbc65d448f46365cfac69567e8177bf12b80942f54 for gcr.io/kaniko-project/executor:debug ...

Triage Notes for the Maintainers

Description	Yes/No
Please check if this a new feature you are proposing
Please check if the build works in docker but not in kaniko
Please check if this error is seen when you use `--cache` flag
Please check if your dockerfile is a multistage dockerfile

The text was updated successfully, but these errors were encountered:

gebi · 2020-04-23T18:42:51Z

Ah, sidenote, i confirmed that the credentials still work for pushing images to dockerhub, and they work fine, both manually and as mentioned with the old kaniko version.

For now we have pinned the kaniko version to this one mgit/base:kaniko-executor-debug-stable (which also fixes the problem of kaniko unable to build images on bigger FS because of the included busybox on bigger filesystems due to 64bit inodes and the included busybox not being compiled with large file support #656 )

giovanism · 2020-04-30T01:10:19Z

Is this duplicate of #245?

gebi · 2020-04-30T11:23:42Z

I don't think so,
as in 245 they mention multistage builds and long build time. We have just a short build time, no multistage builds and it worked with the version of kaniko from a few months ago perfectly.

Forst · 2020-05-05T12:13:43Z

Encountering this issue as well. The last working version seems to be v0.16.0.

Could #957 be causing the issue perhaps?

gebi · 2020-05-05T19:32:01Z

it seems #1005 describes the same problem with kaniko

gebi · 2020-05-05T21:06:48Z

i can verify that for us too the lastest working kaniko version is v0.16.0

v0.20.0 is not able to build the image, with the following job output:

$ mkdir -p /kaniko/.docker
$ echo "{\"auths\":{\"index.docker.io\":{\"auth\":\"${DOCKERHUB_AUTH}\"}}}" > /kaniko/.docker/config.json
$ mkdir /docker-tmp
$ echo 'FROM debian:stable' >> /docker-tmp/dockerfile
$ echo 'ENTRYPOINT ["/bin/bash", "-c", "echo hello"]' >> /docker-tmp/dockerfile
$ /kaniko/executor --context /docker-tmp --dockerfile /docker-tmp/dockerfile --destination foo/bar:hello-world-latest
error checking push permissions -- make sure you entered the correct tag name, and that you are authenticated correctly, and try again: checking push permission for "foo/bar:hello-world-latest": POST https://index.docker.io/v2/foo/bar/blobs/uploads/: UNAUTHORIZED: authentication required; [map[Action:pull Class: Name:mgit/base Type:repository] map[Action:push Class: Name:mgit/base Type:repository]]Running after_script
Uploading artifacts for failed job
ERROR: Job failed: exit code 1
FATAL: exit code 1

diegosasw · 2020-05-06T11:25:07Z

@gebi thanks, I confirm with the mgit/base:kaniko-executor-debug-stable image I was able to push to DockerHub but with gcr.io/kaniko-project/executor:debug I was experiencing the same error. Thanks!

This is my script

- export BASE64_CREDENTIALS="$(echo -n $DOCKER_HUB_REPOSITORY_USERNAME:$DOCKER_HUB_REPOSITORY_PASSWORD | base64)"
# @see https://github.com/GoogleContainerTools/kaniko/issues/1227 where folder may not exist
- mkdir -p /kaniko/.docker
- echo "{\"auths\":{\"https://index.docker.io/v2/\":{\"auth\":\"$BASE64_CREDENTIALS\"}}}" > /kaniko/.docker/config.json
- /kaniko/executor --context $CI_PROJECT_DIR --dockerfile $CI_PROJECT_DIR/$IMAGE_TAG/Dockerfile --destination $IMAGE_NAME:$IMAGE_TAG

Used variables to make it more meaningful for newbies (like myself 1 hour ago)

macrotex · 2020-05-06T19:47:12Z

This is also happening to us using the lastest version of "debug" (May 6, 2020) attempting to push to GCR. Seeing this error:

E0506 17:32:28.676141      16 aws_credentials.go:77] while getting AWS credentials NoCredentialProviders: no valid providers in chain. Deprecated.
	For verbose messaging see aws.Config.CredentialsChainVerboseErrors

Changing to tag debug-v0.19.0 things start working again.

tejal29 · 2020-05-07T18:12:36Z

@macrotex Can you please use kaniko v0.22.0 https://github.com/GoogleContainerTools/kaniko/releases/tag/v0.22.0 and let us know if it still exists.

macrotex · 2020-05-08T02:32:14Z

This is also happening to us using the lastest version of "debug" (May 6, 2020) attempting to push to GCR. Seeing this error:
E0506 17:32:28.676141      16 aws_credentials.go:77] while getting AWS credentials NoCredentialProviders: no valid providers in chain. Deprecated.
	For verbose messaging see aws.Config.CredentialsChainVerboseErrors
Changing to tag debug-v0.19.0 things start working again.

Version 0.22.0 fixed my issue.

ymage · 2020-05-14T17:06:10Z

I tried to use https://index.docker.io/v1/ instead of v2 one as docker registry url, which seemed to work for me.
Is v2 endpoint really suported by kaniko ?

GTB3NW · 2020-05-15T00:10:44Z

Hey I still get the aws_credentials error:

Using Kubernetes executor with image gcr.io/kaniko-project/executor:debug-v0.22.0 ...

 E0515 00:08:48.365446      15 aws_credentials.go:77] while getting AWS credentials NoCredentialProviders: no valid providers in chain. Deprecated.
	For verbose messaging see aws.Config.CredentialsChainVerboseErrors

anna-codefresh · 2020-05-18T02:39:19Z

I too am getting the same error with v0.22.0. I tested this and the latest version to work is 0.16.0 as @gebi mentioned.

ymage · 2020-05-18T07:59:50Z

This seems to work for docker hub :

$ export DOCKERHUB_AUTH="$(echo -n $DOCKER_HUB_REPOSITORY_USERNAME:$DOCKER_HUB_REPOSITORY_PASSWORD | base64)"
$ echo "{\"auths\":{\"https://index.docker.io/v1/\":{\"auth\":\"${DOCKERHUB_AUTH}\"}}}" > docker.json
$ docker run --rm -v $(pwd):/workspace -v $(pwd)/docker.json:/kaniko/.docker/config.json:ro gcr.io/kaniko-project/executor:v0.22.0 --context=dir:///workspace --dockerfile=Dockerfile --destination=foo/bar:latest

anna-codefresh · 2020-05-18T17:24:10Z

thanks @ymage. I was using the v2 docker endpoint instead of v1.

vistaarjuneja · 2020-07-09T15:52:31Z

+1. I am able to upload docker images with https://index.docker.io/v1 but not https://index.docker.io/v2 with the latest kaniko debug executor image. Is anyone working on this issue?

anjeyy · 2020-08-11T18:22:08Z

And there i was sitting the last sunday half a day thinking to be that stupid to build a simple image which i wanted to push to my private docker hub.

auths: [https://index.docker.io/v2/]

did NOT work for me.

debug (without version)
debug-v0.22.0
debug-v0.19.0

did work for me.

debug-v0.16.0

auths: [https://index.docker.io/v1/]

did work for me.

debug (without version)
debug-v0.22.0
debug-v0.19.0
debug-v0.16.0

What combination should i use, since i have no idea what the difference it's making?

v1
v2

livelace · 2020-08-11T18:43:20Z

works for me:

https://index.docker.io/v1/ + debug-v0.16.0

UP. It seems the real reason was UserAgent in config.json:

"HttpHeaders": {
  "User-Agent": "Docker-Client/19.03.12 (linux)"
}

After removing this section I haven't have any problems with pushing (even with original debug-539ddefcae3fd6b411a95982a830d987f4214251)

tanguydelignieresaccenture · 2020-08-25T19:23:50Z

After being struggled all the day with the issue, trying to push to dockerhub with a previous version of kaniko, debug-v0.18.0, which was fine few months ago in the same context, as @gebi, I was able to push the image using --registry-mirror index.docker.io.

@tejal29 may it be related to dockerhub hostname or default image path that has maybe changed and is no more compatible with kaniko (in old versions at least)?

I'm using auths with https://index.docker.io/v1/ in config.json.

KO:

$ docker run --rm --entrypoint "" -v /host/path/to/kaniko/config.json:/kaniko/.docker/config.json -v /host/path/to/dockerfile/directory/kaniko/20200825-001/build1:/workspace gcr.io/kaniko-project/executor:debug-v0.18.0 /kaniko/executor --context /workspace --dockerfile /workspace/Dockerfile --destination index.docker.io/tanguydelignieres/kaniko_bugs_20200825-001_build1:debug-v0.18.0
INFO[0003] Resolved base name alpine:3.9 to alpine:3.9
INFO[0003] Resolved base name alpine:3.9 to alpine:3.9
INFO[0003] Retrieving image manifest alpine:3.9
INFO[0005] Retrieving image manifest alpine:3.9
INFO[0009] Built cross stage deps: map[]
INFO[0009] Retrieving image manifest alpine:3.9
INFO[0011] Retrieving image manifest alpine:3.9
INFO[0014] Skipping unpacking as no commands require it.
INFO[0014] Taking snapshot of full filesystem...
INFO[0014] Resolving paths
INFO[0014] CMD echo "OK"
error pushing image: failed to push to destination index.docker.io/tanguydelignieres/kaniko_bugs_20200825-001_build1:debug-v0.18.0: UNAUTHORIZED: authentication required; [map[Action:pull Class: Name:tanguydelignieres/kaniko_bugs_20200825-001_build1 Type:repository] map[Action:push Class: Name:tanguydelignieres/kaniko_bugs_20200825-001_build1 Type:repository] map[Action:pull Class: Name:library/alpine Type:repository]]

$

OK with --registry-mirror index.docker.io:

$ docker run --rm --entrypoint "" -v /host/path/to/kaniko/config.json:/kaniko/.docker/config.json -v /host/path/to/dockerfile/directory/kaniko/20200825-001/build1:/workspace gcr.io/kaniko-project/executor:debug-v0.18.0 /kaniko/executor --registry-mirror index.docker.io --context /workspace --dockerfile /workspace/Dockerfile --destination index.docker.io/tanguydelignieres/kaniko_bugs_20200925-001_build1:debug-v0.18.0
INFO[0002] Resolved base name alpine:3.9 to alpine:3.9
INFO[0002] Resolved base name alpine:3.9 to alpine:3.9
INFO[0002] Retrieving image manifest alpine:3.9
INFO[0004] Retrieving image manifest alpine:3.9
INFO[0007] Built cross stage deps: map[]
INFO[0007] Retrieving image manifest alpine:3.9
INFO[0008] Retrieving image manifest alpine:3.9
INFO[0010] Skipping unpacking as no commands require it.
INFO[0010] Taking snapshot of full filesystem...
INFO[0010] Resolving paths
INFO[0010] CMD echo "OK"

$

I confirm I did not face the problem with debug-v1.0.0.

nlamirault · 2020-08-27T10:38:17Z

I try with Kaniko v1.0.0 on Docker Hub v2 endpoint, it fails. It works using v1.

tejal29 · 2020-08-27T22:35:32Z

Thank you folks, I updated the docs to use v1 endpoint instead of v2

tejal29 · 2020-08-27T22:36:37Z

@tanguydelignieresaccenture i am still trying to understand why adding --registry-mirror works for you.

To get around GoogleContainerTools/kaniko#1209 we need to auth using the DockerHub v1 API. As that variable is the "registry" and we have to use a FQDN with Protocol we have to convert to standard registry format for tagging the image, otherwise there's an issue with the auth mechanism where it attempts to normalize the URL and incorrectly parses it. GoogleContainerTools/kaniko#1209

qafro1 · 2021-07-07T10:30:55Z

I'm having the same issue

Kaniko does (no longer?) seem to support authenticating against "docker-hub"'s v2-api-endpoint, as also discussed on GitHub: GoogleContainerTools/kaniko#1209 The suggested workaround seems to be to use the v1-endpoint. So hackily inject it when generating a docker-cfg for kaniko.

msolimans · 2021-08-23T14:18:54Z

I used https://index.docker.io/v1/ and it worked

In k8s:

kubectl create secret docker-registry --docker-server=https://index.docker.io/v1/ --docker-username=x --docker-password=x
then use the secret anywhere you want

===============

using docker:

create docker.json file:

$ export DOCKERHUB_AUTH="$(echo -n userName:password | base64)"
$ echo "{\"auths\":{\"https://index.docker.io/v1/\":{\"auth\":\"${DOCKERHUB_AUTH}\"}}}" > docker.json

then
docker run --rm -v $(pwd)/docker.json:/kaniko/.docker/config.json:ro gcr.io/kaniko-project/executor:debug --context=git://github.com/msolimans/icho --dockerfile=Dockerfile --destination=msolimans/icho:latest

loarca · 2021-09-21T13:31:40Z

Ok sooo, since v1 is deprecated, I don't believe using v1 is the safe option here or is it?
I'm just confused. Isn't v1 supported only by older docker clients? (and thus meaning it would stop working someday)

Which makes me think that, from debug-v0.16.0 to debug-v0.19.0 something change that made the registries think kaniko is an old docker client? and thus blocking kaniko from pushing/pulling on v2? I don't know.

svlentink · 2021-10-16T11:52:49Z

After hours upon hours on this issue and keep getting the Unauthorized error, I did a docker login and found that the config looked as follows:

{
        "auths": {
                "https://index.docker.io/v1/": {
                        "auth": "REDACTED_T0="
                },
                "https://index.docker.io/v2/": {
                        "auth": "REDACTED_T0K"
                }
        }
}

When doing a base64 -d on both, it showed the same value. Thus the issue was that docker login uses a different base64 encode method for v1 and v2. (my password ended with an =)
When using Kaniko I removed the v2 auth and it now works.

sichan-vonage · 2022-04-04T14:16:36Z

We are using Harbor as a self hosted container registry, but I cannot get the authentification to work in the kaniko build. The error is the same as with the official Docker registry:
error checking push permissions -- make sure you entered the correct tag name, and that you are authenticated correctly, and try again: checking push permission for "hub.domain.com/repo/kaniko:f569d627": POST https://hub.domain.com/v2/repo/kaniko/blobs/uploads/: UNAUTHORIZED: unauthorized to access repository: repo/kaniko, action: push: unauthorized to access repository: repo/kaniko, action: push
I also tried the suggested workaround resulting in config.json like this:
{
        "auths": {
                "hub.domain.com/v1": {
                        "auth": "xxxxxxxxxxxx"
                }
}
But the logs/errors stayed the same, i.e. Kaniko still used the https://hub.domain.com/v2/ endpoint. Any hints how I could adapt the workaround to work with Harbor as well?

I'm having the exact same problem, did you ever find the fix to this?

imjasonh · 2022-04-04T15:29:06Z

The index.docker.io key in the config file is special, for backward compatibility with DockerHub specifically. Even if the map key is https://index.docker.io/v1/, this is handled as a special case to mean "auth for index.docker.io, where registry API operations always speak to https://index.docker.io/v2/.../blobs/....

So if you're trying to auth to a Harbor registry at hub.domain.com, the map key should be "hub.domain.com", and not include either /v1 or /v2.

sichan-vonage · 2022-04-04T15:36:04Z

The index.docker.io key in the config file is special, for backward compatibility with DockerHub specifically. Even if the map key is https://index.docker.io/v1/, this is handled as a special case to mean "auth for index.docker.io, where registry API operations always speak to https://index.docker.io/v2/.../blobs/....

So if you're trying to auth to a Harbor registry at hub.domain.com, the map key should be "hub.domain.com", and not include either /v1 or /v2.

I've tried this without the /v1 or /v2 route and it still doesn't work..

In our setup, we are also using a service account to enable us to pull images from AWS ECR for our base image. But then our final built image is pushed to our own private registry. Is there any chance that using a combination of registries is preventing us from pushing to our custom registry?

madrisan · 2022-04-04T16:19:25Z

Have you set a proxy and forgot to no_proxy your local private registry?

sichan-vonage · 2022-04-04T16:35:06Z

Have you set a proxy and forgot to no_proxy your local private registry?

no, we have not set any proxies.

My config.json looks like this:

{
  "auths": {
    "private.registry.net": {
      "username": "admin",
      "password": "XXX",
      "auth": "YYY="
    }
  }
}

and I am setting kaniko destination value to private.registry.net/admin/client-app-poc:latest

The error I'm getting from kaniko is:

error checking push permissions -- make sure you entered the correct tag name, and that you are authenticated correctly, and try again:
checking push permission for "private.registry.net/admin/client-app-poc:latest": POST https://private.registry.net/v2/admin/client-app-poc/blobs/uploads/: UNAUTHORIZED: authentication required; [map[Action:pull Class: Name:admin/client-app-poc Type:repository] map[Action:push Class: Name:admin/client-app-poc Type:repository]]

imjasonh · 2022-04-04T16:38:38Z

So first of all, it probably isn't the cause of the issue, but it would help resolve confusion to not use both username+password and auth; the auth field is meant to be the base64-encoded username+:+password, so just in case they don't match, we don't want any confusion about which one is used. I'd suggest removing the plaintext username+password fields, and just use the base64 auth field.

After removing those, make sure that docker push works -- this will tell us if the auth configured in the file is authorized to perform pushes. If that works and Kaniko doesn't, we have a bug and this debugging information will be really useful.

sichan-vonage · 2022-04-04T17:14:25Z

it's okay I've finally sorted it, very daft mistake, but basically just had the config mounted in the wrong place...

Thank you guys for helping out!

DarkDeddok · 2022-12-15T11:26:47Z

it's okay I've finally sorted it, very daft mistake, but basically just had the config mounted in the wrong place...

Thank you guys for helping out!

you can provide part of the code where you mount?

mohitbhansali · 2023-02-09T14:15:57Z

We are using Harbor as a self hosted container registry, but I cannot get the authentification to work in the kaniko build. The error is the same as with the official Docker registry:
error checking push permissions -- make sure you entered the correct tag name, and that you are authenticated correctly, and try again: checking push permission for "hub.domain.com/repo/kaniko:f569d627": POST https://hub.domain.com/v2/repo/kaniko/blobs/uploads/: UNAUTHORIZED: unauthorized to access repository: repo/kaniko, action: push: unauthorized to access repository: repo/kaniko, action: push
I also tried the suggested workaround resulting in config.json like this:
{
        "auths": {
                "hub.domain.com/v1": {
                        "auth": "xxxxxxxxxxxx"
                }
}
But the logs/errors stayed the same, i.e. Kaniko still used the https://hub.domain.com/v2/ endpoint. Any hints how I could adapt the workaround to work with Harbor as well?
I'm having the exact same problem, did you ever find the fix to this?

Did you mange to resolve this issue?

artemptushkin · 2023-06-20T10:31:26Z

It's still not working with v2 but works with v1 in the config.json file, will this issue address this or we need/have another one?

sgurusamy-rli · 2023-08-09T17:04:39Z

are there any configuration changes required to make it work with docker api v2 (https://index.docker.io/v2?

0xkevin · 2023-10-19T10:16:26Z

We are using Harbor as a self hosted container registry, but I cannot get the authentification to work in the kaniko build. The error is the same as with the official Docker registry:
error checking push permissions -- make sure you entered the correct tag name, and that you are authenticated correctly, and try again: checking push permission for "hub.domain.com/repo/kaniko:f569d627": POST https://hub.domain.com/v2/repo/kaniko/blobs/uploads/: UNAUTHORIZED: unauthorized to access repository: repo/kaniko, action: push: unauthorized to access repository: repo/kaniko, action: push
I also tried the suggested workaround resulting in config.json like this:
{
        "auths": {
                "hub.domain.com/v1": {
                        "auth": "xxxxxxxxxxxx"
                }
}
But the logs/errors stayed the same, i.e. Kaniko still used the https://hub.domain.com/v2/ endpoint. Any hints how I could adapt the workaround to work with Harbor as well?
I'm having the exact same problem, did you ever find the fix to this?
Did you mange to resolve this issue?

+1

alexis974 · 2024-02-07T21:48:50Z

Just tested it today with https://index.docker.io/v2/ and it seems to work.

My gitlab-ci job:

deploy:
  stage: deploy
  image:
    name: gcr.io/kaniko-project/executor:v1.14.0-debug
    entrypoint: [""]
  script:
    - echo -n "{\"auths\":{\"https://index.docker.io/v2/\":{\"auth\":\"$(echo -n ${CI_REGISTRY_USER}:${CI_REGISTRY_PASSWORD} | base64)\"}}}" > /kaniko/.docker/config.json
    - /kaniko/executor
      --context "${CI_PROJECT_DIR}"
      --dockerfile "${CI_PROJECT_DIR}/Dockerfile"
      --destination=docker.io/<user>/<img_name>:<my_tag>

ilyabreev · 2024-06-24T09:39:34Z

Still doesn't work on latest image with private gitlab registry.

docker run -ti --rm -v /code:/workspace -v `pwd`/config.json:/kaniko/.docker/config.json:ro gcr.io/kaniko-project/executor:debug  --dockerfile=./path/Dockerfile --destination=registry.gitlab.local/group/project:latest --insecure --insecure-registry registry.gitlab.local
error checking push permissions -- make sure you entered the correct tag name, and that you are authenticated correctly, and try again: checking push permission for "registry.gitlab.local/group/project:latest": POST http://registry.gitlab.local/v2/group/project/blobs/uploads/: unexpected status code 404 Not Found:

followed by Gitlab 404 page

mlec1 · 2024-08-19T14:01:55Z

Still doesn't work on latest image with private gitlab registry.

Which version of Gitlab are you using ?? It works for me on a private Gitlab with gcr.io/kaniko-project/executor:v1.22.0-debug

artemptushkin · 2024-08-19T14:08:59Z

@mlec1 probably an old I used, it was long time ago for me

xooooooooox · 2024-09-12T16:05:59Z

Building an image with kaniko behind a proxy works for me. (see https://archives.docs.gitlab.com/16.11/ee/ci/docker/using_kaniko.html)

variables:
  CI_REGISTRY: "https://index.docker.io/v1/"
  CI_REGISTRY_USER: <your_dockerhub_username>
  CI_REGISTRY_PASSWORD: <your_dockerhub_password>
  CI_REGISTRY_IMAGE: '<docker_hub_username>/<xxxx>'
  http_proxy: <your-proxy>
  https_proxy: <your-proxy>
  no_proxy: <your-no-proxy>

stages:
  - build

build:
  stage: build
  tags:
    - k8s
  image:
    name: gcr.io/kaniko-project/executor:debug
    entrypoint: [ "" ]
  script:
    - mkdir -p /kaniko/.docker
    - echo "{\"auths\":{\"${CI_REGISTRY}\":{\"auth\":\"$(printf "%s:%s" "${CI_REGISTRY_USER}" "${CI_REGISTRY_PASSWORD}" | base64 | tr -d '\n')\"},\"$(echo -n $CI_DEPENDENCY_PROXY_SERVER | awk -F[:] '{print $1}')\":{\"auth\":\"$(printf "%s:%s" ${CI_DEPENDENCY_PROXY_USER} "${CI_DEPENDENCY_PROXY_PASSWORD}" | base64 | tr -d '\n')\"}}}" > /kaniko/.docker/config.json
    - /kaniko/executor
      --build-arg http_proxy="$http_proxy"
      --build-arg https_proxy="$https_proxy"
      --build-arg no_proxy="$no_proxy"
      --context "${CI_PROJECT_DIR}"
      --dockerfile "${CI_PROJECT_DIR}/Dockerfile"
      --destination "$CI_REGISTRY_IMAGE:${CI_COMMIT_TAG}"
  rules:
    - if: $CI_COMMIT_TAG

gebi mentioned this issue Apr 24, 2020

Failed to push image to Docker Hub #835

Open

superbarne mentioned this issue May 6, 2020

Failing to check push permissions banzaicloud/drone-kaniko#35

Open

brianseeders added a commit to brianseeders/kibana-ci-service that referenced this issue May 6, 2020

Try pinning kaniko version. See GoogleContainerTools/kaniko#1209

a8c2850

tejal29 added area/registry For all bugs having to do with pushing/pulling into registries kind/bug Something isn't working priority/p1 Basic need feature compatibility with docker build. we should be working on this next. gitlab labels May 7, 2020

tanguydelignieresaccenture mentioned this issue Aug 26, 2020

Regression since v0.19.0 using --cache=true with shell parameter expansion in RUN instruction of Dockerfile #1399

Open

ahmedzidan mentioned this issue Oct 21, 2021

Error while pushing image to docker registry #1792

Open

keturn mentioned this issue Oct 26, 2021

build: parallel agents for the different jdks MovingBlocks/JenkinsAgentPrecachedJava#2

Merged

paladin-devops mentioned this issue Feb 7, 2022

Remote operations for docker-pull hashicorp/waypoint#2780

Closed

MaesterZ mentioned this issue Feb 10, 2022

EOF on AWS ECR API POST to check push permissions #1935

Closed

aaron-prindle added the kind/friction label Jun 20, 2023

Xysto mentioned this issue Apr 8, 2024

Kaniko and proxy set up #2252

Open

Pushing images to dockerhub stopped working #1209

Pushing images to dockerhub stopped working #1209

Comments

gebi commented Apr 23, 2020

gebi commented Apr 23, 2020

giovanism commented Apr 30, 2020

gebi commented Apr 30, 2020

Forst commented May 5, 2020

gebi commented May 5, 2020

gebi commented May 5, 2020 • edited Loading

diegosasw commented May 6, 2020 • edited Loading

macrotex commented May 6, 2020

tejal29 commented May 7, 2020

macrotex commented May 8, 2020

ymage commented May 14, 2020

GTB3NW commented May 15, 2020

anna-codefresh commented May 18, 2020

ymage commented May 18, 2020 • edited Loading

anna-codefresh commented May 18, 2020

vistaarjuneja commented Jul 9, 2020

anjeyy commented Aug 11, 2020 • edited Loading

livelace commented Aug 11, 2020 • edited Loading

tanguydelignieresaccenture commented Aug 25, 2020 • edited Loading

nlamirault commented Aug 27, 2020 • edited Loading

tejal29 commented Aug 27, 2020

tejal29 commented Aug 27, 2020

qafro1 commented Jul 7, 2021 • edited Loading

msolimans commented Aug 23, 2021 • edited Loading

loarca commented Sep 21, 2021

svlentink commented Oct 16, 2021 • edited Loading

sichan-vonage commented Apr 4, 2022

imjasonh commented Apr 4, 2022

sichan-vonage commented Apr 4, 2022

madrisan commented Apr 4, 2022

sichan-vonage commented Apr 4, 2022

imjasonh commented Apr 4, 2022

sichan-vonage commented Apr 4, 2022 • edited Loading

DarkDeddok commented Dec 15, 2022

mohitbhansali commented Feb 9, 2023

artemptushkin commented Jun 20, 2023

sgurusamy-rli commented Aug 9, 2023

0xkevin commented Oct 19, 2023

alexis974 commented Feb 7, 2024

ilyabreev commented Jun 24, 2024

mlec1 commented Aug 19, 2024 • edited Loading

artemptushkin commented Aug 19, 2024

xooooooooox commented Sep 12, 2024

gebi commented May 5, 2020 •

edited

Loading

diegosasw commented May 6, 2020 •

edited

Loading

ymage commented May 18, 2020 •

edited

Loading

anjeyy commented Aug 11, 2020 •

edited

Loading

livelace commented Aug 11, 2020 •

edited

Loading

tanguydelignieresaccenture commented Aug 25, 2020 •

edited

Loading

nlamirault commented Aug 27, 2020 •

edited

Loading

qafro1 commented Jul 7, 2021 •

edited

Loading

msolimans commented Aug 23, 2021 •

edited

Loading

svlentink commented Oct 16, 2021 •

edited

Loading

sichan-vonage commented Apr 4, 2022 •

edited

Loading

mlec1 commented Aug 19, 2024 •

edited

Loading