n the pipeline, no container
uploads. Stage0 creates Debian+Guix that builds a pure Guix stage1
which builds the final Stage2 images. The content of these images
appears to be reproducible, but alas the docker images itself aren't:
https://issues.guix.gnu.org/75090
No need for --disable-chroot
Simon Josefsson via writes:
>>> 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 tr
ot;"]
image: debian:stable
The last one is what I suppose most people want to use. One shouldn't
have to specify entrypoint's when using GitLab CI/CD images.
My Guix container:latest works on these three variants:
image:
name: debian:stable
entrypoint: [&quo
Ludovic Courtès writes:
>> - 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.
Yes, I discov
Hi Simon!
Simon Josefsson 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
n<#secure method=pgpmime mode=sign>
Hi Andreas,
Nice work ! I’ve been playing a bit with it, but failed miserably to
use your image, as you can see:
https://gitlab.com/csantosb/gitlabci/-/jobs/8681019372
This is my dummy yaml file:
https://gitlab.com/csantosb/gitlabci/-/blob/test
Guix container, which seems like progress (whoohoo!). tl;dr:
>
> at work we are using gitlab CI to build guix docker containers and run a
> node on openshift for the bordeaux build farm:
>https://gitlab.inria.fr/enge/plm-guix
> The README.md is completely outdated and serves main
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 conta
Simon Josefsson skribis:
> Yes it seems like a GitLab/docker-specific problem since I don't get the
> same /etc when running the generated image locally.
>
> There is this interesting entry in /proc/mounts:
>
> https://gitlab.com/debdistutils/guix/container/-/jobs/8652014833#L343
>
> overlay / ov
ec 16 10:15 hostname
>> -rw-r--r-- 1 0 0 283 Dec 16 10:15 hosts
>> lrwxrwxrwx 1 0 0 12 Dec 16 10:15 mtab -> /proc/mounts
>> -rw-r--r-- 1 0 0 841 Dec 16 10:15 resolv.conf
>>
>> There is no /etc/protocols! No wonder things doesn't work.
>
> And th
6 10:15 mtab -> /proc/mounts
> -rw-r--r-- 1 0 0 841 Dec 16 10:15 resolv.conf
>
> There is no /etc/protocols! No wonder things doesn't work.
And that’s in spite of you running ‘guix pack … net-base -S /etc=etc’.
Could it be that something in podman/Docker/GitLab-CI overrides /etc
). tl;dr:
at work we are using gitlab CI to build guix docker containers and run a
node on openshift for the bordeaux build farm:
https://gitlab.inria.fr/enge/plm-guix
The README.md is completely outdated and serves mainly as a reminder to
myself on how this docker thing works; every time I lo
'guix
pack' and creates a container using 'podman' and uploads it into:
registry.gitlab.com/debdistutils/guix/container:pack
I suspect the problem is happening in the 'guix pack' or 'podman load'
commands here. Output from last successful run:
https://gitlab.com/deb
In the test-entry branch, I’m testing the trick in the guix-on-docker
repository, where the entrypoint is given a guix script.
https://gitlab.com/csantosb/gitlabci/-/jobs/8648429390
Getting closer ...
--
Cayetano Santos
GnuPG Key: https://meta.sr.ht/~csantosb.pgp
FingerPrint: CCB8 1842 F9
I just setup a toy project, here:
https://gitlab.com/csantosb/gitlabci
Here, I reproduce the steps to build a docker image using guix system
image, and set te entrypoint to "", as you can see.
Still, a piece in the puzzle is missing, ideas ?
https://gitlab.com/csantosb/gitlabci/-/jobs/
Am Thu, Jun 06, 2024 at 11:23:20AM +0200 schrieb Ludovic Courtès:
> (It’s possible to sidestep that problem for instance by having GitLab-CI
> offload to a runner in a machine that you control, where Guix is
> installed. But I’m looking for a solution that could work
> out-of-th
Reza Housseini skribis:
> Ludovic Courtès writes:
>
>> That’s nice, but unless I’m mistaken, Guix is missing from the image,
>> right?
>>
>> My goal would be to be able to use Guix within the image, so I can have
>> GitLab-CI spawn ‘guix build’ commands (
Ludovic Courtès writes:
> That’s nice, but unless I’m mistaken, Guix is missing from the image,
> right?
>
> My goal would be to be able to use Guix within the image, so I can have
> GitLab-CI spawn ‘guix build’ commands (or similar).
Oh sorry this was a misunderstanding from my
Hi,
Andreas Enge skribis:
> Am Tue, Jun 04, 2024 at 01:29:22PM +0200 schrieb Ludovic Courtès:
>> My goal would be to be able to use Guix within the image, so I can have
>> GitLab-CI spawn ‘guix build’ commands (or similar).
>
> with a colleague we have set up such a system
Hello,
Am Tue, Jun 04, 2024 at 01:29:22PM +0200 schrieb Ludovic Courtès:
> My goal would be to be able to use Guix within the image, so I can have
> GitLab-CI spawn ‘guix build’ commands (or similar).
with a colleague we have set up such a system. He has started from a Debian
image and wri
Hi Reza,
Reza Housseini skribis:
>> Has anyone succeeded in building a Docker image suitable for use in
>> GitLab-CI?
>
> I normally do the following and it seems to work fine with our gitlab
> instance:
>
> registry=registry.gitlab.ost.ch:45023/sciceg/teaching/eeu
Ludovic Courtès writes:
sorry forgot to include the list...
Hi Ludo
> Has anyone succeeded in building a Docker image suitable for use in
> GitLab-CI?
I normally do the following and it seems to work fine with our gitlab
instance:
registry=registry.gitlab.ost.ch:45023/sciceg/te
Hi,
Efraim Flashner skribis:
> In the past I used a script to install guix using the shell script and
> then ran guix pull before building my package. I suppose you could use
> a Debian image and run 'guix pull' first before building something.
I could… but that’d be cheating. :-)
Ludo’.
On Tue, Feb 13, 2024 at 11:31:28AM +0100, Ludovic Courtès wrote:
> Hello Guix!
>
> Has anyone succeeded in building a Docker image suitable for use in
> GitLab-CI? I haven’t. Here’s what I tried.
In the past I used a script to install guix using the shell script and
then ran guix
Am Tue, Feb 13, 2024 at 11:31:28AM +0100 schrieb Ludovic Courtès:
> Has anyone succeeded in building a Docker image suitable for use in
> GitLab-CI? I haven’t. Here’s what I tried.
A colleague of mine just found this:
https://gitlab.com/daym/guix-on-docker/
:-)
Andreas
Ludovic Courtès writes:
> Initially, I built an image with ‘guix system image -t docker …’ but
> that doesn’t work because then the image’s “entry point” is shepherd,
> but shepherd never returns.
Did you try resetting the entrypoint in .gitlab-ci.yml using the
image:entrypoint keyword? [1]
[1]
Hello Guix!
Has anyone succeeded in building a Docker image suitable for use in
GitLab-CI? I haven’t. Here’s what I tried.
Initially, I built an image with ‘guix system image -t docker …’ but
that doesn’t work because then the image’s “entry point” is shepherd,
but shepherd never returns
Hi Wolf,
Patch is now submitted, see following for details.
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64171
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=64173
Now we find out what I forgot. ;-)
Thanks again for your help,
Graham
On Tue, 13 Jun 2023 at 17:56, Graham Addis wrote:
>
> Hi Wo
Hi Wolf,
Well I managed to sort it out last weekend.
I have added a --docker-entry-point option which can be invoked
multiple times to provide the docker EntryPoint value in exec form.
I have left the --entry-point behaviour alone except the
--docker-entry-point takes precedence.
I still have t
Hi Wolf,
Similar to what I was trying, which didn't work. I'll try to have a go
one evening and try and work out where I went wrong.
Thanks again. Graham
On Mon, 5 Jun 2023 at 18:35, wolf wrote:
>
> On 2023-06-05 16:37:50 +0100, Graham Addis wrote:
> > Hi Wolf,
> >
> > Not a particularly succes
On 2023-06-05 16:37:50 +0100, Graham Addis wrote:
> Hi Wolf,
>
> Not a particularly successful weekend...
>
> As --entry-point was used by other pack methods I thought the best
> option would be to add a --docker-entry-point just for the docker
> format and pass it into the build as an extra-opti
Hi Wolf,
Not a particularly successful weekend...
As --entry-point was used by other pack methods I thought the best
option would be to add a --docker-entry-point just for the docker
format and pass it into the build as an extra-option like for deb and
rpm formats.
However I couldn't work out ho
Hi Wolf,
On Thu, 1 Jun 2023 at 22:55, wolf wrote:
>
> On 2023-05-31 18:47:03 +0100, Graham Addis wrote:
> > I could use the equivalent format for --entry-point
> >
> > --entry-point executable --entry-point param1 --entry-point param2
> >
> I think that is a reasonable idea. Only downside is tha
On Thu, 1 Jun 2023 at 23:04, wolf wrote:
> I did not know Guix does not currently support the shell form. In that light
> I
> think it should not be implemented, since once your idea (arguments for entry
> point) is implemented, it will be trivial for end-user to emulate it if so
> desired.
Tha
On 2023-05-30 07:52:57 +0100, Graham Addis wrote:
> Hi Worf,
>
> Thanks for the response, see below.
>
> On Mon, 29 May 2023 at 20:41, wolf wrote:
> >
> > On 2023-05-24 18:04:47 +0100, Graham Addis wrote:
> > > Dear people,
> > >
> > >
On 2023-05-31 18:47:03 +0100, Graham Addis wrote:
> Hi Wolf,
>
> On Tue, 30 May 2023 at 07:52, Graham Addis wrote:
> >
> > ENTRYPOINT ["executable", "param1", "param2"] # The exec form, which
> > is the preferred form:
>
> I realised that pack takes multiple symlink(s) using
>
> --symlink /bin=
Hi Wolf,
On Tue, 30 May 2023 at 07:52, Graham Addis wrote:
>
> ENTRYPOINT ["executable", "param1", "param2"] # The exec form, which
> is the preferred form:
I realised that pack takes multiple symlink(s) using
--symlink /bin=bin --symlink /opt=opt
I could use the equivalent format for --entry-
Hi Worf,
Thanks for the response, see below.
On Mon, 29 May 2023 at 20:41, wolf wrote:
>
> On 2023-05-24 18:04:47 +0100, Graham Addis wrote:
> > Dear people,
> >
> > I tried to create a docker image to use in a gitlab-ci instance but it
> > failed because I couldn&
On 2023-05-24 18:04:47 +0100, Graham Addis wrote:
> Dear people,
>
> I tried to create a docker image to use in a gitlab-ci instance but it
> failed because I couldn't use --entry-point="bin/sh -l -c" or
> equivalent, basically the gitlab-runner complains that it can
Dear people,
I tried to create a docker image to use in a gitlab-ci instance but it
failed because I couldn't use --entry-point="bin/sh -l -c" or
equivalent, basically the gitlab-runner complains that it can't run
binaries.
I've managed to get it working by making som
Ludovic Courtès writes:
> Hello! I’m late to the party but I’m interested in this discussion… :-)
> GitLab CI can run jobs directly in a Docker image:
> https://docs.gitlab.com/ce/ci/docker/using_docker_images.html
> So it would be interesting to have any easy way for people
Le lundi 27 juillet 2020 à 09:46 +0200, Ludovic Courtès a écrit :
> > I prefer the solution in which the pack is a .tar.gz that is
> > directly
> > untarred to /; this way it can be run on a shared unprivileged
> > runner
> > and the storage can be achieved in the run
t gitlab server will not let you use the provided
> docker registry, and so the only option will be to push to docker hub.
Yes. What I had in mind was that you would create that image, upload it
to a registry GitLab-CI can pull from, and then refer to that image in
your ‘.gitlab-ci.yml’.
> I
.
I prefer the solution in which the pack is a .tar.gz that is directly
untarred to /; this way it can be run on a shared unprivileged runner
and the storage can be achieved in the runner itself, via the gitlab CI
cache.
divoplade
Hello!
I’m late to the party but I’m interested in this discussion… :-)
Jérémy Korwin-Zmijowski skribis:
> I am experimenting with Gitlab CI for a Guile project I am working on.
> It is managed with Hall and I would like to benefit the Guix features.
GitLab CI can run jobs directl
Jérémy Korwin-Zmijowski writes:
> Hey Guixters !
>
> I am experimenting with Gitlab CI for a Guile project I am working on.
> It is managed with Hall and I would like to benefit the Guix features.
>
> Does anyone has done that before ?
> Is there a way to get a Guix docker
Jérémy Korwin-Zmijowski writes:
> I the meantime I would like to try to put a Guix's docker image on
> dockerhub and use it in Framagit/Gitlab if it is possible...
This would be fantastic, please let us know about your progress :)
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Descr
Hello,
Le lundi 06 juillet 2020 à 14:25 +0200, Jérémy Korwin-Zmijowski a
écrit :
> Thank you for the new yaml file ! Unfortunately, I didn't manage to
> use
> this one yet. I have to do more experiments I guess.
I do, too. In the mean time, I think we would be very happy to have a
debian package.
Le jeudi 25 juin 2020 à 23:32 +0200, divoplade a écrit :
> Hello Jérémy,
>
> I have a new solution (it is quite different from the previous one)
> in
> which it is possible to run guix commands within a job, while still
> caching most of the files (see attached). I am sorry, my fork of your
> proj
.
Anyways, everything will be way easier once we have a proper debian
package for guix:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=850644
divoplade
Le samedi 20 juin 2020 à 10:42 +0200, Jérémy Korwin-Zmijowski a écrit :
> Hey Guixters !
>
> I am experimenting with Gitlab CI fo
Hi Zimoun !
Thank you for taking time to help over here !
Thanks to divoplade, we succedded to make something up for relative
simple projects (I don't know how it goes for more complicated ones).
If anybody feel interested :
https://framagit.org/Jeko/guile-dummy
Cheers,
Jérémy
Hi Jérémy,
On Sat, 20 Jun 2020 at 10:42, Jérémy Korwin-Zmijowski
wrote:
> - printf '\n' | ./guix-install.sh
[...]
>[1592641832.155]: [ FAIL ] unsupported init system; run the daemon
>manually:
> /root/.config/guix/current/bin/guix-daemon --build-users-
>group=guixbuild
>
I tried to apply the caching as you did, but I error during project
configuration.
https://framagit.org/Jeko/guile-dummy/-/jobs/1029866
Jérémy
Le mardi 23 juin 2020 à 12:15 +0200, Jérémy Korwin-Zmijowski a écrit :
> Hey divoplade !
>
> Thank you very much for sharing your hack ! The caching sec
Hey divoplade !
Thank you very much for sharing your hack ! The caching section is very
interesting... Does it save time between runs ?
After a lot of attempts, I ended up with a green pipeline but it takes
43 minute to complete haha
https://framagit.org/Jeko/guile-dummy/-/pipelines
Jérémy
Le samedi 20 juin 2020 à 15:40 +0200, Ricardo Wurmus a écrit :
>
> Can you specify a different Docker image? Then you could create one
> containing Guix with “guix pack -f docker”.
>
I am not the owmer of the Gitlab instance, so I think I can't... But I
can ask to the admin haha. Worth the shot
ackage, it
will be way easier.
divoplade
Le samedi 20 juin 2020 à 10:42 +0200, Jérémy Korwin-Zmijowski a écrit :
> Hey Guixters !
>
> I am experimenting with Gitlab CI for a Guile project I am working
> on.
> It is managed with Hall and I would like to benefit the Guix
> features.
>
Jérémy Korwin-Zmijowski writes:
> Hey Guixters !
>
> I am experimenting with Gitlab CI for a Guile project I am working on.
> It is managed with Hall and I would like to benefit the Guix features.
>
> Currently, I struggle to run Guix inside the default Debian sta
Hey Guixters !
I am experimenting with Gitlab CI for a Guile project I am working on.
It is managed with Hall and I would like to benefit the Guix features.
Currently, I struggle to run Guix inside the default Debian stable
docker image (framagit.org).
Here is my .gitlab-ci.yml
58 matches
Mail list logo
