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