poky-entry: make compatible with standard docker invocation

[andred]

This had two issues:

• the command to execute was expected to be passed via --cmd, rather than just the remaining arguments as per usual practice when using 'docker run' to start a container
• it ignored any --workdir passed via the docker command, and instead expected the workdir to be passed as an argument to the entrypoint

Both are non-standard behaviour, and in particular conflict with the Jenkins docker plugin's expected use of docker images, as that relies on standard behaviour.

We now:

• (try to) check if a --workdir was given in the docker arguments, by checking if the current directory is different from the image's default '/home/yoctouser'
• accept additional arguments without a --cmd flag. Any remaining arguments now specify the command (and its optional arguments) to run

Signed-off-by: André Draszik andre.draszik@jci.com

[rewitt1]

Hi @andred,

In your commit message you say "This had two issues:", what is this?

Also if you give an example command line using the poky-container using "standard docker invocation" which is what you desire, vs. what you are considering non-standard, it will help me understand.

[andred]

Hi @rewitt1,

'this' in the first sentence refers to poky-entry.py in particular, but more generally how this image expects itself to be started.

A normal docker run command line would be e.g (adopted from the runtests.sh script, which I have forgotten to modify in my patch): docker run --rm -v $LOCAL_WDIR:/workdir:Z --workdir=/workdir $IMAGE "/workdir/$i" whereas this image wants to be started as docker run --rm -v $LOCAL_WDIR:/workdir:Z $IMAGE --workdir=/workdir --cmd="/workdir/$i" i.e.:

• --workdir as a docker run argument vs. --workdir as a poky-entry.py argument
• command to execute as CMD (as per Dockerfile spec) vs. extra argument --cmd= needed for poky-entry.py

The problem with that is:

• the workdir argument in poky-entry.py is duplicating functionality that already exists in plain docker run. People are already used to passing --workdir= as docker run argument, and also no existing generic infrastructure knows about this difference, e.g. the Jenkins docker-workflow plugin. It already passes --workdir as part of docker run, but I have to duplicate this for no benefit when using this image
• as per docker best practices, the image should be able to run as though it was a command: https://docs.docker.com/develop/develop-images/dockerfile_best-practices/#entrypoint Again, people are already used to that, and also existing generic infrastructure expects this to be the case, e.g. the Jenkins docker-workflow plugin will fail to work otherwise with the following message: ERROR: The container started but didn't run the expected command. Please double check your ENTRYPOINT does execute the command passed as docker run argument. See https://docs.docker.com/engine/userguide/eng-image/dockerfile_best-practices/#entrypoint for entrypoint best practices.

Does this make it more clear? If yes, I'll update the commit message (and also update the runtests.sh script)

[rewitt1]

Yes I understand.

Originally, I didn't want anyone to be able to use the container as a general purpose container for running arbitrary commands. The reasoning behind that was so that if a user said "The container isn't working", I wouldn't ever have to worry about commands that didn't use the entry point. The "--cmd" argument was intended for testing only.

However, if it is useful for you to be able to run arbitrary commands, such as a script to run bitbake similar to runbitbake.py, then this change makes sense.

I'll add my questions about the changes to the review.

[rewitt1]

@andred, If you're wondering why I force pushed to your branch, its because I tried using the github web editor to fix a merge conflict, and it replaced the original commit with the merge commit. I'm really not sure what happened.

The new commit that I pushed to your branch, is your original commit with the merge conflict fixes. I wanted to make sure you got credit and the history stayed around.