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’
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 w
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]
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
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
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
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
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
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
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.
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
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
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 some changes to gu
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 peop
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’.
&g
lse).
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 di
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
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
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
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
>
.
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
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
e, 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.
>
&g
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
43 matches
Mail list logo
