ci: Move from Incus to Docker for image building #7
Conversation
|
@lool - I think this change will make things easier to introduce future work I'll be doing for enabling the IT team's AWS runners. We can hold off on this until then, or proceed with this now and probably reduce deltas in that future work. Either way works for me. |
|
Looks great! At first I thought you'd use the debos provided containers, but I actually prefer the clear and only dependency on trixie here (I was checking if we could see the debos version in the log, and we can because it's apt install-ed, so we see which one gets downloaded). I was expecting runs with the container image to be slightly faster since we're saving on host updates, but they are actually slightly worse; here's the breakdown of yesterday's daily run vs the last run from this PR: 
Shame that this conflicts with this other PR #5 that I've been trying to get in for a few days, I guess yours should go in first and I should rebase it again |
|
There's also a -lite version of the debian OCIs; I'm making a mental note to give them a spin some day |
|
fwiw i'd recommend using the upstream debos docker images |
|
@obbardc Cool to have you join the conversation :) What do you see as pros and cons of using the debos docker image? I like the idea of putting the CI in the shoes of an end-user running trixie, and apt install-ing tools from trixie to build an image; this means there's also a single provider for the build-environment (Debian) |
Let's do your change first. Mine is pretty easy to apply |
|
@lool your suggestion makes sense ! |
Appreciate it @doanac; I've merged #5 so probably this one here will need rebasing now; I've left a few minor suggested improvements here even if I'd be happy to merge this as is. |
|
@doanac I see this fails to build now, this is because I split the single debos call into two; one to build the rootfs and one to build the image. I used to run the whole build under a single debos call that was using the QEMU backend; under the QEMU backend you can do whatever you want, including debootstrap, mounting stuff etc. When I had to generate two types of images, I wanted to share the creation of the rootfs, so I am running debos a first time but without a backend, which means it's doing its actions directly on the host rather than QEMU. This works under Incus, but not under Docker, since it's not a privileged container, so creating device nodes as part of debootstrap doesn't work. I guess you should go back to running everything under qemu, unless privileged docker is an option and works (not sure); not using qemu for the rootfs had brought a nice speed benefit, too bad! |
|
CI is currently broken with some weird deb.debian.org errors, but looking at the CI run for pull request #5 (https://github.com/qualcomm-linux/qcom-deb-images/actions/runs/14306586823/job/40091770134), the build was about 10mn faster when not using the QEMU backend for the rootfs: |
doanac
force-pushed
the
incus-to-docker
branch
2 times, most recently
from
040eb9d to
cfe4d0a
Compare
Docker is supported as a first-class citizen in GitHub Actions. This change removes a few actions we were having to perform. This change will also make the upcoming move to AWS self-hosted runners easier. Signed-off-by: Andy Doan <[email protected]>
3 participants
Docker is supported as a firt-class citizen in GitHub Actions. This change removes a few actions we were having to perform. This change will also make the upcoming move to AWS self-hosted runners easier.