I am happy to announce Guix container images: https://gitlab.com/debdistutils/guix/container/
They are suitable for use in GitLab pipelines. There are many things to continue discuss and resolve. However it is now possible to start a GitLab pipeline job that uses an 'image:' pointing to a container file that were created by `guix pack` and it has network access. Andreas Enge posted a link on how to achieve this with non-free 'docker' and some custom hosted gitlab runners with extra permissions, but my variant uses only free software and the images can be reproduced solely on the GitLab public runners (i.e., no image uploading from a local laptop). As far as I know this hasn't been done before. Successful example job that runs a Guix environment: https://gitlab.com/debdistutils/guix/container/-/jobs/8670483694 Start the container like this: sudo apt-get install podman || guix package -i podman podman run -it registry.gitlab.com/debdistutils/guix/container:latest The README mentions a few works that you will appreciate -- can you suggest ways to resolve these matters? - `export HOME=/` - `export CWD=/` - `guix-daemon --disable-chroot &` - `GUIX_PROFILE=/root/.config/guix/current; . "$GUIX_PROFILE/etc/profile"` - guix package -i fails: `guix perform-download: error: refusing to run with elevated privileges (UID 0)` - GitLab pipeline job entrypoints: three possible entry-point usages behave somewhat different depending on how `guix pack` was invoked - Adding `nss-certs` to the `guix pack` command breaks: `(symlink "NetLock_Arany_=Class_Gold=_F?tan?s?tv?ny.pem" #) Throw to key encoding-error' with args ("scm_to_stringn" "cannot convert wide string to output locale" 84 #f #f)'.` Those things aside, the main problem right now is that I would expect 'guix package -i gcc automake autoconf' to work. However as you can see in the `test-amd64-package-install` job things fail to download seamingly from an intentional privilege check: guix perform-download: error: refusing to run with elevated privileges (UID 0) https://gitlab.com/debdistutils/guix/container/-/jobs/8670514009 What is the best way to resolve this? Ugly insecure workarounds are acceptable too, I didn't find any --insecure or similar. It would be nice to publish a couple of different images, one minimal and one more complete with, say, gcc on it. Thoughts on what packages to include and how to name the images? Doing arm64 images should be straight forward but I get an error running 'guix pull' in the Debian image: https://issues.guix.gnu.org/74925 -- Also I do not know how to push a combined amd64+arm64 image like Debian do with the 'debian:trixie' image doing the right thing for both amd64 and arm64 under the same name. Ideas? Can someone try to use them in some other environments, maybe GitHub actions or Codeberg Woodpecker? Finally, you may wonder why things didn't work before. Some of the major reasons: 1) --max-layer=100 and 2) -S /etc=etc and 3) Missing /etc/protocols etc. GitLab's docker setup doesn't handle many layers, and it happens to just mount a sub-set of layers (see mount output, missing a lot of layers). Which files are put at which layer seems to vary between `guix pack` runs for some reason, making it really hard to debug (sometimes things worked partially, sometimes not, depending on which files ended up visible). I use --max-layers=8 now. Re /etc=etc it seems GitLab's docker setup bind-mounts things below /etc/ and it cannot handle the root /etc symlink. A workaround is to use `lndir` which I use in the `test-amd64-package-install` job. This is limitation of GitLab's docker setup: I tried running a `-S /etc=etc` image on my own GitLab runner based on Trisquel [1] and it worked fine, it mounted things below the symlinked tree properly. Could `guix pack` be teached how to do a lndir-approach for /etc instead of symlink, perhaps? Happy hacking, /Simon [1] https://gitlab.com/debdistutils/debdistreproduce/-/blob/main/gitlab-runner-with-podman-on-trisquel-aramo.md?ref_type=heads
signature.asc
Description: PGP signature
