-
-
Notifications
You must be signed in to change notification settings - Fork 111
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
docker: Build for debian by default #450
Comments
Hi @SimonKagstrom ! Hijacking this issue, as it's somewhat related to an issue on our CICD pipeline. We used And also saw the dockerhub image was uploaded a few days ago. It'd be great if there were alpine + debian images in DockerHub, but that would be a burden on maintenance. I will build kcov in our container using debian instead, but just in case you hear from anyone else with issues like this one 👍 Cheers |
What was the failure? @williamdes might also be interested, although I take the responsibility since I pushed for alpine-based docker builds :-) |
Can you share your workflow? I think there is maybe something wrong as my CI does not pass as I said here #437 (comment) |
My pipelines are executed on a private GitLab repository, but they simply run
With the change to alpine, running My first intention was to pin the Then I searched for an -slim or ubuntu etc. image, and noticed there was only an Alpine image (which is already very useful to have :)). My fix was to update the first stage in the container to build kcov with debian, and then copy just the binary for the final image:
|
BTW, I think the image is useful for others testing it, and maybe for CI tests in this repo. And I wouldn't want to add any extra burden on the maintainer 🙂 The The tag in DockerHub would be helpful to allow me to procrastinate a bit, and fix it later, but not a big issue 👍 Thanks a lot again for kcov! (p.s. I also updated our CI to drop |
I have to read all this soon |
Well, I see that this can be a problem, and I'm maybe inclined to go with a debian-based image as default. However, is this really how the docker images should be used? In this case, it fails since the image is copied from an alpine-based build, but I guess it could also fail if e.g., the debian version would mismatch after the copy? Anyway, I'd say we revert back to debian for the docker images, and that's probably good enough for now. Maybe in the future, it could make sense to build for alpine as well. |
There are some initiatives to have support to both 1, but I never tried that. For popular images it's common to have a glibc and musl version. But for smaller projects I believe it's totally fine to a) provide instructions only, b) provide a Dockerfile only, c) provide a single image on DockerHub without promises that it can be used in production. Any of these are fine for me (and the option a), is pretty much what you have in INSTALL, that's enough for anyone to build a container). I know maintaining Open Source projects is hard, and there is already a toll on doing that and having to make something that's a bit generic and works for everybody. But IMHO, your personal life & happiness maintaining the project comes first.
Up to you, but it really does not bother me at all to have to build it on my CICD. Maybe later I will be able to use it if Debian stable adds kcov (I couldn't install it with bookworm), or if I switch to a Ubuntu based image. There are probably other workarounds... but being able to have coverage for my shell scripts with kcov is already a great thing 🙂 Thanks! p.s.: Not sure how you are building and uploading the images, but most (if not everything?) of that nowadays can be automated with GitHub Actions, which helps to ease a bit the burden of testing, maintaining the images, uploading to DockerHub, tagging, etc. Footnotes |
@williamdes already did the transition to bookworm, so I'll revert to that and hopefully it should be easier to use in this usecase. In #444 , there's also some work to make it easier for debian packaging, but even with an updated version, the distribution version will always lag behind.
Yeah, @williamdes did a lot of improvements there, so it's automated, so not much burden to maintain (except waiting for the builds). I rephrased this issue to be more aligned with the discussion :-) Will create a new one for the original issue. |
As I'm using this at $work, I can also help here with testing/doc/code/etc. if needed 🙂 Thank you @SimonKagstrom ! |
Ha, but I really liked the alpine version and need it for my GitHub actions to be quick Could we have both versions on docker hub? and vxx-alpine and vxx is bookworm |
@williamdes yes, sounds like a splendid idea! While I don't use kcov from docker builds personally, I tend to base my other docker builds on alpine since it's generally faster and smaller, so having both sounds good. I only just started on the change (so far failing the build), but feel free to take over! I'm also on MacOS and haven't bothered with a docker setup locally, so it's kind of a churn to test the changes for me. |
Okay, working on it! |
Done #452 |
@kinow there is now official documentation on how to copy kcov into your Dockerfile |
Documentation tested, and it worked like a charm. I've reverted my previous changes, and our Docker image is now a lot simpler. Thanks @SimonKagstrom , @williamdes ! 🙇 |
Good to test in musl.
The text was updated successfully, but these errors were encountered: