Skip to content
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

Closed

Conversation

reneleonhardt
Copy link

I also updated GitHub action versions, Python to 3.11 and requirements.

@itchyny
Copy link
Contributor

itchyny commented Jun 17, 2023

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.

@wader
Copy link
Member

wader commented Jun 17, 2023

Nice, some thoughts

  • Would it make sense to build docker image during CI to make sure it's broken?
  • Do we need debian image if we do a static alpine build? how do ppl usually use these image? just run them or copy binary from them?
  • Add amd64 to be multi arch?
  • If only the jq binary is copied in the last step can we skip generate documentation and install python?

@reneleonhardt
Copy link
Author

reneleonhardt commented Jun 18, 2023

Nice, some thoughts

Thank you, I caught more gotchas than I thought ;)

* Would it make sense to build docker image during CI to make sure it's broken?

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 :(

* Do we need debian image if we do a static alpine build? how do ppl usually use these image? just run them or copy binary from them?

I adapted the improvements from the mentioned PRs. In my opinion only the alpine image is needed, it really is tiny.
Those who want to copy the binary into their own image could just do:
COPY --from=jqlang/jq /jq /usr/local/bin/

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:

docker create --name jq jqlang/jq
docker cp jq:/jq /usr/local/bin/
docker rm jq
* Add amd64 to be multi arch?

At the moment it would probably already be x86_64 (can't test your existing workflows locally with act), but yes, I would definitely recommend a multi-platform image as a mac user ;)
I could create an example workflow for that when Dockerfiles changed.

* If only the jq binary is copied in the last step can we skip generate documentation and install python?

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.
The manual tests are not regenerated without python, but in my opinion this should be done in other build jobs anyway (where you already have python). Dockerfile now just relies on the man.test in Git, I regenerated it manually.
Oddly enough the tonumber test was missing in the current manual, I kept it in the commit.

I would see docker images as a release job only, with the exception if Dockerfile was changed in a PR.

@wader
Copy link
Member

wader commented Jun 18, 2023

Nice, some thoughts

Thank you, I caught more gotchas than I thought ;)

👍

* Would it make sense to build docker image during CI to make sure it's broken?

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 :(

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?

* Do we need debian image if we do a static alpine build? how do ppl usually use these image? just run them or copy binary from them?

I adapted the improvements from the mentioned PRs. In my opinion only the alpine image is needed, it really is tiny. Those who want to copy the binary into their own image could just do: COPY --from=jqlang/jq /jq /usr/local/bin/

Yeap think so too. Do we strip the binary btw? 11MB sounded nearly a lot :)

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:

docker create --name jq jqlang/jq
docker cp jq:/jq /usr/local/bin/
docker rm jq

@itchyny @owenthereal what do you think about pushing to github docker registry? in addition to docker hub?

* Add amd64 to be multi arch?

At the moment it would probably already be x86_64 (can't test your existing workflows locally with act), but yes, I would definitely recommend a multi-platform image as a mac user ;) I could create an example workflow for that when Dockerfiles changed.

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?

* If only the jq binary is copied in the last step can we skip generate documentation and install python?

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. The manual tests are not regenerated without python, but in my opinion this should be done in other build jobs anyway (where you already have python). Dockerfile now just relies on the man.test in Git, I regenerated it manually. Oddly enough the tonumber test was missing in the current manual, I kept it in the commit.

I would see docker images as a release job only, with the exception if Dockerfile was changed in a PR.

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?

@owenthereal
Copy link
Member

what do you think about pushing to github docker registry? in addition to docker hub?

👍 I vote for pushing to both and gradually phasing out the docker hub and making ghcr.io the official docker registry

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants