help-guix
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Building a Docker image for GitLab-CI


From: Ludovic Courtès
Subject: Re: Building a Docker image for GitLab-CI
Date: Sat, 21 Dec 2024 16:33:50 +0100
User-agent: Gnus/5.13 (Gnus v5.13)

Hi Simon!

Simon Josefsson <simon@josefsson.org> skribis:

> I am happy to announce Guix container images:
>
> https://gitlab.com/debdistutils/guix/container/
>
> They are suitable for use in GitLab pipelines.

Yay!

> - guix package -i fails: `guix perform-download: error: refusing to
>   run with elevated privileges (UID 0)`

Should be fixed by running guix-daemon with
“--build-users-group=whatever” so that downloads run as one of the build
users, not as root.

> - GitLab pipeline job entrypoints: three possible entry-point usages
>   behave somewhat different depending on how `guix pack` was invoked

This image uses Guix installed on Debian though, no?

> - 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)'.`

You need to run guix-daemon in a UTF-8 locale like “C.UTF-8” (which is
supported out-of-the-box).

See also <https://issues.guix.gnu.org/75007>.

> 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.

Interesting.  Did you find points in the code (Docker? GitLab?) about
this subset of layers being mounted?

> 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?

It could symlink individual files and make /etc a directory.  (What’s
‘lndir’, if I may ask?)

Thanks for the investigation and all!

Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]