-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Update Docker image to debian 12 #2617
Update Docker image to debian 12 #2617
Conversation
As for the the multi-stage build in Dockerfile, we need to review the existing proposals #2004 or #1900 (in any case, we need to discuss on the new distribution home). About updating the pip packages, one of the Python scripts depends on some legacy APIs of jinja2, so merging this PR will break the website workflow (But note that I'm currently working on redesign the website so pip packages will be updated sooner or later). About the versions in the download page, it's better to drop mentioning unmaintainable versions each package managers in my opinion. The part in the PR I find no issue is the updates of actions. |
Nice, some thoughts
|
Thank you, I caught more gotchas than I thought ;)
I wouldn't recommend it for normal pushes, better to create a separate workflow which only runs when Dockerfiles changed. Those tiny images take a looong time to build :(
I adapted the improvements from the mentioned PRs. In my opinion only the alpine image is needed, it really is tiny. By the way, please, get a GitHub login and push official images, this would make things so much easier, you could copy the correct platform binary to your host so easily:
At the moment it would probably already be x86_64 (can't test your existing workflows locally with
Makefile requires quite a lot of files which aren't needed for the image, but yes, I was able to skip most of the documentation. I would see docker images as a release job only, with the exception if Dockerfile was changed in a PR. |
👍
Sorry ment "make sure it's not broken" of course Yeah maybe trigger on Dockerfile path make sense if it's slow. But is it that much slower then the host builds done in CI?
Yeap think so too. Do we strip the binary btw? 11MB sounded nearly a lot :)
@itchyny @owenthereal what do you think about pushing to github docker registry? in addition to docker hub?
Sorry again, meant "arm64" :) yes at least amd64 and arm64 would be expected of a jq image i think? i wonder how we should do it, there are no arm64 github action runners at the moment so either buildx, very slow but easy to maintain, or do cross build Dockerfile somehow? other ways?
Aha i see, not very familiar with the autoconf/make setup yet. Maybe good to note that jq recently got a bunch of new maintainer so we're kind of in the process to learn understand how things have been done. So maybe we should skip change the build step too much for now and leave it for later clean up/optimization? @itchyny maybe you have some idea about the missing tonumber test mystery? |
👍 I vote for pushing to both and gradually phasing out the docker hub and making ghcr.io the official docker registry |
I also updated GitHub action versions, Python to 3.11 and requirements.