[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’.
- Re: Building a Docker image for GitLab-CI, Cayetano Santos, 2024/12/15
- Re: Building a Docker image for GitLab-CI, Cayetano Santos, 2024/12/15
- Re: Building a Docker image for GitLab-CI, Simon Josefsson, 2024/12/16
- Re: Building a Docker image for GitLab-CI, Ludovic Courtès, 2024/12/17
- Re: Building a Docker image for GitLab-CI, Simon Josefsson, 2024/12/17
- Re: Building a Docker image for GitLab-CI, Ludovic Courtès, 2024/12/17
- Re: Building a Docker image for GitLab-CI, Simon Josefsson, 2024/12/17
- Re: Building a Docker image for GitLab-CI,
Ludovic Courtès <=
- Re: Building a Docker image for GitLab-CI, Simon Josefsson, 2024/12/22
- Container image entrypoints on Gitlab (was: Re: Building a Docker image for GitLab-CI), Simon Josefsson, 2024/12/23
- Re: Container image entrypoints on Gitlab, Simon Josefsson, 2024/12/25
- GitLab container /etc symlink problem (was: Re: Building a Docker image for GitLab-CI), Simon Josefsson, 2024/12/23
- Re: Building a Docker image for GitLab-CI, Simon Josefsson, 2024/12/25