Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cache warmer always caches linux/amd64 image, even on arm64 #1372

Closed
tsufeki opened this issue Aug 6, 2020 · 0 comments · Fixed by #1374
Closed

Cache warmer always caches linux/amd64 image, even on arm64 #1372

tsufeki opened this issue Aug 6, 2020 · 0 comments · Fixed by #1374

Comments

@tsufeki
Copy link
Contributor

tsufeki commented Aug 6, 2020

Actual behavior
On arm64 machines, cache warmer caches linux/amd64 image

Expected behavior
It should download and cache linux/arm64 image

To Reproduce
Steps to reproduce the behavior:

  1. Build kaniko/warmer for arm64
  2. Run warmer with a multi arch image, for example --image=python:3.8
  3. Compare sha256 in cache dir to confirm its amd64, not arm64. https://hub.docker.com/_/python/?tab=tags

Additional Information

  • Kaniko Image - my own build of kaniko/warmer:v0.24.0 for arm64
  • I suspect this needs WithPlatform option added in pkg/cache/warm.go

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
tsufeki added a commit to tsufeki/kaniko that referenced this issue Aug 7, 2020
Cache warming fetched images without specifying platform, which resulted
in always pulling default linux/amd64. Even when kaniko was built and
run on arm64.

This change brings warmer's behaviour in line with executor's by
specifying runtime.GOOS/GOARCH.

Fixes GoogleContainerTools#1372
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant