How do you use step:entrypoint?

[fracai]

Today I created a step that looks something like:

steps:
  list-tags:
    image: ghcr.io/regclient/regctl:v0.5.6
    commands:
      - regctl tag ls ghcr.io/regclient/regctl

It turns out that regctl is a scratch container and produces an error with:
Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "/bin/sh": stat /bin/sh: no such file or directory: unknown

I noticed that Woodpecker v2.2.0 adds support for overriding the container entrypoint.
I adapted the configuration, but I can't seem to get this working.

The following just prints the regctl help message as if only the first argument is making it to the entrypoint:

steps:
  list:
    image: ghcr.io/regclient/regctl:v0.5.6
    entrypoint:
      - /regctl tag ls ghcr.io/regclient/regctl

The same is true if I use:

steps:
  list:
    image: ghcr.io/regclient/regctl:v0.5.6
    entrypoint: ["/regctl", "tag", "ls", "ghcr.io/regclient/regctl"]

And, oddly, the same if I specify garbage for the entrypoint:

steps:
  list:
    image: ghcr.io/regclient/regctl:v0.5.6
    entrypoint:
      - /regctlblahblah tag ls ghcr.io/regclient/regctl

The entrypoint only seems to take effect if commands is also set:

steps:
  list:
    image: ghcr.io/regclient/regctl:v0.5.6
    entrypoint:
      - /regctlgarbage
    commands:
      -  tag ls ghcr.io/regclient/regctl

resulting in:
Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: exec: "/regctlgarbage": stat /regctlgarbage: no such file or directory: unknown

So if I use the valid entrypoint:

steps:
  list:
    image: ghcr.io/regclient/regctl:v0.5.6
    entrypoint:
      - /regctl
    commands:
      -  tag ls ghcr.io/regclient/regctl

The output is still no good:
unknown command "echo $CI_SCRIPT | base64 -d | /bin/sh -e" for "regctl"

In this case, it looks like the commands parameter is being converted as normal to the CI_SCRIPT and then passed to the /regctl entrypoint.
I can further validate this by moving the commands back to the entrypoint and supplying a placeholder command:

steps:
  list:
    image: ghcr.io/regclient/regctl:v0.5.6
    entrypoint: ["/regctl", "tag", "ls", "ghcr.io/regclient/regctl"]
    commands:
      - --

This yields: accepts 1 arg(s), received 2
That's output from regctl indicating it has received extra arguments.

Is this a bug in how entrypoint is being handled?
Actually, I'm inclined to think it is that. Or at least an undocumented behavior.

woodpecker/pipeline/backend/docker/convert.go

Line 45 in c8fa718

if len(step.Commands) != 0 {

Unless I'm overlooking another change, that if statement shows that the entrypoint is only modified if commands are also specified. But, if commands are specified, they're supplied as an argument to the entrypoint as if that entrypoint was still the default /bin/sh.

So, am I ultimately going about this the wrong way?

Granted, I could build from the container to add the expected shell, but I'm hoping there's another way to solve this without creating custom containers.

[qwerty287]

You should separate the command and its args:

steps:
  list:
    image: ghcr.io/regclient/regctl:v0.5.6
    entrypoint:
      - /regctl
      - tag
      - ls
      - ghcr.io/regclient/regctl

The entrypoint only seems to take effect if commands is also set:

If this is really the case (I didn't test), that's a bug.

The output is still no good:
unknown command "echo $CI_SCRIPT | base64 -d | /bin/sh -e" for "regctl"

Yes, but we don't have a good way to run scripts currently. I know that command execution needs a refactor, maybe I can take a look at some point.

[zc-devs]

Doesn't work, v2.2.2

Test 1

skip_clone: true
steps:
  curl:
    image: curlimages/curl
    entrypoint:
      - /usr/bin/curl
    commands:
      - http://google.com

curl: (3) URL rejected: Malformed input to a URL function

pod-1.yaml
woodpecker-agent-1.log

Test 2

skip_clone: true
steps:
  curl:
    image: curlimages/curl
    entrypoint:
      - /usr/bin/curl
      - http://google.com

curl: try 'curl --help' or 'curl --manual' for more information

pod-2.yaml
woodpecker-agent-2.log

[qwerty287]

Yes, if you have command defined, an argument of the entrypoint is echo $CI_SCRIPT | base64 -d | /bin/sh -e.

As I said already: This needs more work again. I'll try to look into it.

[fracai]

Thanks for taking a look.

I wonder if something like this would work:

if len(step.Commands) > 0 && len(step.Entrypoint) > 0 {
    return nil
}
if len(step.Commands) > 0 || len(step.Entrypoint) > 0 {
    env, entry, cmd := common.GenerateContainerConf(step.Commands, e.info.OSType)
    for k, v := range env {
        configEnv[k] = v
    }
    if len(step.Commands) > 0 {
        config.Entrypoint = entry
        config.Cmd = []string{cmd}
    }
    if len(step.Entrypoint) > 0 {
        config.Entrypoint = step.Entrypoint
        config.Cmd = []string{}
    }
}

There's probably a better way to restrict specifying both entrypoint and commands.

[zc-devs]

Depends on command definition.

I would like syntax below be supported:

image: curlimages/curl
entrypoint:
  - /usr/bin/curl
commands:
  - "-v"
  - "--insecure"
  - https://google.com

image: alpine
entrypoint:
  - /bin/bash
  - "-c"
commands:
  - echo Hello; printenv;

Especially the first one.

#3216 should help.

Instead of commands there, probably, should be args.

[qwerty287]

Yes, we somehow need to not use the script approach anymore, but execute commands separately.

What's your idea with the first example you gave? To run /usr/bin/curl -v --insecure https://google.com?
Because that changes the current way how commands is working.
Instead it should execute:

1. /usr/bin/curl -v
2. /usr/bin/curl --insecure
3. /usr/bin/curl https://google.com

This would not make sense with curl, but with a shell:

entrypoint: [/bin/sh, "-c"]
commands:
  - echo 1
  - echo 2

1. /bin/sh -c "echo 1"
2. /bin/sh -c "echo 2"

If it would be possible to run /bin/sh -c "echo 1" "echo 2", this would be fine, but this doesn't work.

Instead of commands there, probably, should be args.

You don't need a separate key for this. I assume your first example should demonstrate this usecase, so why don't you use this?

image: curlimages/curl
entrypoint:
  - /usr/bin/curl
  - "-v"
  - "--insecure"
  - https://google.com

It looks like this currently does not work, but that's a bug. Or would this have a different result for Kubernetes?

[zc-devs]

What's your idea with the first example you gave? To run /usr/bin/curl -v --insecure https://google.com?

Yes. I treated commands as args.
Define a Command and Arguments for a Container, ENTRYPOINT.

There are always executable/program/entrypoint and its arguments. Step is one-shot execution, runs one process. There are two cases.

1. Program is some interpreter like Bash, PowerShell, Python. This executable takes script as one of the args. So WP's commands is just syntax sugar in case of Shell, that built script from commands.
2. Program is just regular... program. Then there is no magic and we have to feed it by arguments. Simple as it gets.

---

I propose:

1. Use commands only in case of interpreter. You can override default entrypoint, for example:

entrypoint:
  - /bin/bash
  - "-x"
  - "-e"
 commands:
  - echo Hello
  - printenv

As it works now, commands are converted to script and feeds as -c argument.
2. Add keyword args, that will be used in case of general porgram:

entrypoint:
  - /usr/bin/curl
 args:
  - "-v"
  - "--insecure"
  - https://google.com

Moreover, you can use args without entrypoint. In that case image's entrypoint will be used:

steps:
  build:
    image: gcr.io/kaniko-project/executor:v1.18.0
    args:
      - --context
      - ./
      - --build-arg
      - VERSION=123
      - --destination
      - harbor.domain.net/project/image:123

3. Prohibit image from using in local backend. There is entrypoint for that already. And commands/args for different use cases (see points 1,2 above).

[qwerty287]

Prohibit image from using in local backend. There is entrypoint for that already. And commands/args for different use cases (see points 1,2 above).

Except this point (will be hard to do with e.g. schema), your suggestion is probably the best.
(EDIT: Don't know why I thought this, shouldn't be hard to do)

[qwerty287]

Here we go: #3269