Re: guix docker on gitlab-ci

[wolf <wolf@wolfsden.cz>]

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

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 <wolf@wolfsden.cz> 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't use --entry-point="bin/sh -l -c" or
> > > equivalent, basically the gitlab-runner complains that it can't run
> > > binaries.
> >
> > Would this be better using just bin/sh for the entry point and passing the -l
> > and -c as an arguments?
> 
> Probably, but I don't think that's an option in gitlab ci and anyway
> it would be nice to support the docker options.
> 
> > > I've managed to get it working by making some changes to guix/scripts/pack.scm
> > >
> > > Adding a fn in docker-image, just before the call to
> > > build-docker-image, to create a list from the string passed in from
> > > --entry-point="bin/sh -l -c"
> > >
> > >             (define (make-docker-exec-form prefix value)
> > >               (cond
> > >                ((equal? value '())
> > >                 '())
> > >                ((equal? prefix '())
> > >                 (string-split value #\space))
> > >                (else
> > >                 (let ((values (string-split value #\space)))
> > >                   (cons
> > >                    (string-append prefix "/" (car values))
> > >                    (cdr values))))))
> >
> > If I read this right (sorry, still somewhat new to guile), you basically split
> > the --entry-point argument on spaces and use those parts as separate values to
> > invoke, is that correct?  If so, how would you pass a binary that has space in
> > the name (joke example: `/bin/ba sh') into the entry-point?
> 
> Basically, yes, and you are right about the problem.
> 
> I looked through all the guix documentation I could find and the only
> other place I saw that a list was passed in an option was for URLs and
> they were separated by spaces.
> 
> > > And replacing the setting of entry-point in the build-docker-image call to:
> > >
> > >                                 #:entry-point (make-docker-exec-form
> > > #$profile #$entry-point)
> > >
> > > The call to build-docker-image takes a list for entry-point, and it
> > > all works fine as far as I can tell.
> > >
> > > Before I send in a patch, some questions:
> > >
> > > Am I missing something?
> > >
> > > Am I on the right track?
> >
> > In my opinion (which you are free to disagree with :) ), I think it would be
> > better to either have /bin/sh as an entry-point (and pass -l -c as arguments
> > when starting the container, if required) or create a wrapper script /bin/shlc
> > that would exec /bin/sh with correct arguments.
> 
> Yep, lots of possible workarounds, but it seems to me that it would be
> better spending the time adjusting the pack command to fit the spec.
> 
> > Few random ideas: Maybe the same format Containerfiles use for cmd and
> > entrypoint directives could be used?  Maybe the --entry-point could also (in
> > addition to a string) accept a list of strings (LISP list)?
> 
> Sounds good to me. Do you have a reference for the json for this? (Not
> a big deal as I think I've worked it out from the code, but it's
> always nice to have the specs...)
> 
> From the Dockerfile reference for ENTRYPOINT
> https://docs.docker.com/engine/reference/builder/#entrypoint there are
> two fomrs:
> 
> ENTRYPOINT ["executable", "param1", "param2"] # The exec form, which
> is the preferred form:
> 
> ENTRYPOINT command param1 param2 # The shell form:
> 
> To implement the shell form I'd need to update build-docker-image in
> guix/docker.scm
> https://git.savannah.gnu.org/cgit/guix.git/tree/guix/docker.scm#n139
> to take a string instead of/ as well as the list it currently takes.
> Then update docker-image in guix/scripts/pack.scm
> https://git.savannah.gnu.org/cgit/guix.git/tree/guix/scripts/pack.scm#n592
> 
> Invocation would then simply be --entry-point="command param1 param2"
> 
> To implement the exec form (preferred according to docker) I wouldn't
> need to touch guix/docker.scm, but I would probably need to change the
> parsing for --entry-point as well as updating docker-iimge.

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.

> 
> I prefer the second option, for which all I need is some guidance on
> the option syntax
> 
> .e.g. --entry-point=["command", "param1", "param2"]
> 
> Suggestions please. :)
> 
> I could implement both and test for a string or a list and choose
> between the shell and exec forms from there, but to be consistent with
> the existing implementation.
> 
> Once I'm clear about the best approach for this, I could add the CMD
> too, if that would be useful.
> https://docs.docker.com/engine/reference/builder/#cmd
> 
> One strange thing, I couldn't see the need for prefixing the profile
> to the ENTRYPOINT command:
> https://git.savannah.gnu.org/cgit/guix.git/tree/guix/scripts/pack.scm#n670
> I took it out and everything seems to work, so I'm not sure what
> problem it is fixing. Anybody any idea?

Wild guess, but it might depend on your container runtime (whether it uses execv
or execvp). Absolute path feels somewhat more robust.

> 
> Thanks,
> 
> Graham
>

W.

-- 
There are only two hard things in Computer Science:
cache invalidation, naming things and off-by-one errors.

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