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,
> > >
> > > 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.
>
