3 ms·

I (or rather, jenkins) builds all my software in it, I don't actually use it for containerizing final applications. In a nutshell, for me the value is in trivi

by csirac2 12y ago

I (or rather, jenkins) builds all my software in it, I don't actually use it for containerizing final applications. In a nutshell, for me the value is in trivial repeatability. I can reproduce the entire build toolchain, test environment and produce artifacts all from a few KiB git repo which centres around the Dockerfile and submodules to dependencies. Some of my ARM stuff takes hours to cross-compile and involves enormous amounts of fiddly babysitting normally. Dockerfiles have RUN statements (think lines a shell script) which are cached. My adjustments toward the end of a Dockerfile take only seconds to test and produces the exact same result as if it had really run each statement from the start, which doesn't sound like much but turns out (for me) to be pretty liberating compared to constantly trying to fight other automation where you have to dance around short-circuiting stuff to re-use bits of a past build to save time and get only a handful of "pristine" iterations in a day (that might differ to the iterations you rolled by hand).

voltagex_ 12y ago
I'd be super interested if you could share any of your ARM cross-compilation Dockerfiles.
- csirac2 12y ago
  They've got a lot of idiosyncrasies at the moment, some of it working around the fact ADD some/directory/ could never be cached (so my build scripts maintain some.directory.tar.gz and those are ADDed instead), but I really should. I guess I'd put it under my github profile (I'm also csirac2 there). There's two types of ARM builds, ones which can cross-compile and those that can't. The ones which can't cross-compile are done with qemu-binfmts and we chroot into an ARM filesystem and run the build there. Perhaps the only useful contribution would be the fact that I persist the ccache up to the docker host with a shared ccache volume, and that helps enormously especially for the qemu-binfmts builds which can be quite slow.
  - voltagex_ 12y ago
    Where does your original (non-qemu) toolchain come from? Is that built inside or outside of a container?
    - csirac2 12y ago
      (em)debian provides nearly enough of what I need most of the time. The trigger for going to a ARM chroot is when I can't get build dependencies installed properly on an amd64 host. Either that or the thing I'm compiling just isn't developed to be cross-compiler friendly and it's too much work to hotwire it to be so. For example, say I need libfoo, I have an amd64 host (being the docker container). Sometimes I just can't get the libfoo:armhf or libfoo-dev:armhf package installed because it would break/conflict with the amd64 host's version of it in some way. xapt often helps but then sometimes screws up by re-packaging something that has an "all" arch (non-arch-specific) to something armhf specific (eg. foo-data). This ultimately either conflicts with the host or fails to be named properly in such a way that it meets the build-deps of the project. Sometimes I know it would be easier in some cases to avoid the debian packaging ecosystem, but for my workflow and distribution requirements it brings a lot of benefits. Edit: see here https://wiki.debian.org/EmdebianToolchain https://wiki.debian.org/EmdebianToolchain

by csirac2 12y ago

voltagex_ 12y ago

I'd be super interested if you could share any of your ARM cross-compilation Dockerfiles.

csirac2 12y ago
They've got a lot of idiosyncrasies at the moment, some of it working around the fact ADD some/directory/ could never be cached (so my build scripts maintain some.directory.tar.gz and those are ADDed instead), but I really should. I guess I'd put it under my github profile (I'm also csirac2 there). There's two types of ARM builds, ones which can cross-compile and those that can't. The ones which can't cross-compile are done with qemu-binfmts and we chroot into an ARM filesystem and run the build there. Perhaps the only useful contribution would be the fact that I persist the ccache up to the docker host with a shared ccache volume, and that helps enormously especially for the qemu-binfmts builds which can be quite slow.
- voltagex_ 12y ago
  Where does your original (non-qemu) toolchain come from? Is that built inside or outside of a container?
  - csirac2 12y ago
    (em)debian provides nearly enough of what I need most of the time. The trigger for going to a ARM chroot is when I can't get build dependencies installed properly on an amd64 host. Either that or the thing I'm compiling just isn't developed to be cross-compiler friendly and it's too much work to hotwire it to be so. For example, say I need libfoo, I have an amd64 host (being the docker container). Sometimes I just can't get the libfoo:armhf or libfoo-dev:armhf package installed because it would break/conflict with the amd64 host's version of it in some way. xapt often helps but then sometimes screws up by re-packaging something that has an "all" arch (non-arch-specific) to something armhf specific (eg. foo-data). This ultimately either conflicts with the host or fails to be named properly in such a way that it meets the build-deps of the project. Sometimes I know it would be easier in some cases to avoid the debian packaging ecosystem, but for my workflow and distribution requirements it brings a lot of benefits. Edit: see here https://wiki.debian.org/EmdebianToolchain https://wiki.debian.org/EmdebianToolchain