Scuba Runs the Entrypoint Before Every Command

[xanarin]

Currently, Scuba adds the entrypoint to the beginning of every command in the generated command.sh script. This can cause unexpected behavior with entrypoints that are only supposed to run once. After a discussion with @JonathonReinhart, it seems best to have the defined entrypoint call the scuba-generated command.sh script, and not have the entrypoint inserted before every command in the script.

Currently the call chain is:

scubainit ---> script --->  ----------------------------
                           | set -e                     |
                           | MY_ENTRYPOINT command1     |
                           | MY_ENTRYPOINT command2     |
                           | MY_ENTRYPOINT command3     |
                            ----------------------------

After the resolution of this issue, it will be:

scubainit ---> MY_ENTRYPOINT --->  ---------------
                                  | set -e        |
                                  | command1      |
                                  | command2      |
                                  | command3      |
                                   ---------------

[JonathonReinhart]

Also from today's discussion, for posterity:

ENTRYPOINT is used by Docker images in two general ways:

Command-style or single application images -- Here, the ENTRYPOINT encapsulates the primary use of the container. Arguments to docker run are intended to be arguments to the dockerized application.

Some examples of this type of image:

• jrottenberg/ffmeg -- docker run jrottenberg/ffmpeg -stats -loop 0 ...
• jreinhart/echo -- docker run jreinhart/echo hello
  • This is actually used by Scuba's tests

A hook -- Here, the ENTRYPOINT is a script that performs some start-up action like starting a daemon, and then typically does exec "$@" to "get out of the way" and run the user command. The first argument to docker run is a command to run, followed by arguments.

---

The advent of multi-line aliases (scripts), led to this interesting problem: How should Scuba treat the ENTRYPOINT when there are multiple lines of the script to run? The answer is: It depends on the type of image:

For single application images, the current behavior (prepending the entrypoint to each line of the script) actually makes sense. For example:

.scuba.yml

image: jreinhart/echo
aliases:
  doit:
    script:
      - line one
      - line two
      - line three

Output:

$ scuba doit
line one
line two
line three

These boutique images seem to be the minority; Scuba is much more interested in "normal" images, where the given arguments are expected to be run as a command. For these normal images, the current behavior is very wrong. An entrypoint that starts a daemon would do so for every line of the script.

It is unfortunately impossible to detect at runtime what type of image entrypoint is being used. So Scuba is at a bit of an impasse. While the current behavior is more usually wrong than right, it is the current behavior; to change it requires a major version bump according to semver. (Sidenote: I'd like to drop support for Python 2.6 anyway, so maybe now is the time!)

With all that said, here is my proposal:

• Scuba 3 changes the default behavior to assume a "normal" image is being used

  • It invokes ENTRYPOINT /bin/sh script and the entrypoint is expected to exec "$@"

• An option to keep the Scuba 2 behavior could be added to .scuba.yml. E.g.:

  image: jreinhart/echo
  aliases:
      foo:
          script:
              - hello
              - world
          entrypoint_per_line: True