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 <w...@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.
signature.asc
Description: PGP signature