unofficial mirror of help-guix@gnu.org 
 help / color / mirror / Atom feed
From: Simon Josefsson via <help-guix@gnu.org>
To: "Ludovic Courtès" <ludovic.courtes@inria.fr>
Cc: help-guix@gnu.org,  suhail@bayesians.ca,
	 Cayetano Santos <csantosb@inventati.org>
Subject: Re: Building a Docker image for GitLab-CI
Date: Wed, 18 Dec 2024 00:46:34 +0100	[thread overview]
Message-ID: <87ed25lvol.fsf@kaka.sjd.se> (raw)
In-Reply-To: <87o71ar4j5.fsf@inria.fr> ("Ludovic Courtès"'s message of "Tue, 17 Dec 2024 11:24:14 +0100")

[-- Attachment #1: Type: text/plain, Size: 4067 bytes --]

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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 255 bytes --]

  reply	other threads:[~2024-12-17 23:53 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-02-14 12:36 Building a Docker image for GitLab-CI Suhail
2024-12-15 21:05 ` Cayetano Santos
2024-12-15 21:27   ` Cayetano Santos
2024-12-16 10:42     ` Simon Josefsson via
2024-12-16 11:04       ` Andreas Enge
2024-12-18 19:17         ` Simon Josefsson via
2024-12-18 22:31         ` Cayetano Santos via
2024-12-17  7:52       ` Ludovic Courtès
2024-12-17  8:07         ` Simon Josefsson via
2024-12-17 10:24           ` Ludovic Courtès
2024-12-17 23:46             ` Simon Josefsson via [this message]
2024-12-21 15:33               ` Ludovic Courtès
2024-12-22 18:07                 ` Simon Josefsson via
  -- strict thread matches above, loose matches on Subject: below --
2024-02-13 10:31 Ludovic Courtès
2024-02-14 14:49 ` Andreas Enge
2024-02-14 17:55 ` Efraim Flashner
2024-02-15  8:25   ` Ludovic Courtès
2024-05-31  9:26 ` Reza Housseini
2024-06-04 11:29   ` Ludovic Courtès
2024-06-05  8:55     ` Andreas Enge
2024-06-06  9:23       ` Ludovic Courtès
2024-06-07 10:56         ` Andreas Enge
2024-06-06 11:39     ` Reza Housseini
2024-06-06 13:12       ` Ludovic Courtès

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87ed25lvol.fsf@kaka.sjd.se \
    --to=help-guix@gnu.org \
    --cc=csantosb@inventati.org \
    --cc=ludovic.courtes@inria.fr \
    --cc=simon@josefsson.org \
    --cc=suhail@bayesians.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).