Open bossm8 opened 5 months ago
Very similar issue here: https://github.com/GoogleContainerTools/kaniko/issues/1787#issuecomment-2223377466
any update on this @bossm8 ?
@riyas-rawther unfortunately not, we switched back to dind as there were/are other bugs which affected us.
Actual behavior While running the the warmer in our GitLab CI/CD we quickly hit the rate-limiting with docker hub even though the cache is warmed already.
GitLab CI:
First run:
Second run (~10mins later):
Or the build:
Note: I also tried it with a different approach of running the warmer only once, which in the end tries to pull less images but else does not change anything:
Expected behavior Pipeline succeeds because manifests of base images are already present in the mounted cache. Note that there is one single runner VM, so the cache is present.
Not sure, but maybe this could be achieved by using the
HEAD
request instead ofGET
(https://docs.docker.com/docker-hub/download-rate-limit/)?To Reproduce Steps to reproduce the behavior:
Additional Information
FROM
entry in the files, in most cases even the same:FROM registry.hub.docker.com/library/rockylinux:9
andFROM registry.hub.docker.com/library/rockylinux:8
Kaniko Image (fully qualified with digest) From the Pipeline:
Triage Notes for the Maintainers
--cache
flag