Service containers have their working directory changed when launched

[Gr3q]

Component

server

Describe the bug

From 2.7.0 if I add a service container that had WORKDIR set in Dockerfile the service won't be able to find files via relative paths (or it expects to find files in it's current folder).

Workaround: Set directory manually on the service

Steps to reproduce

1. Create a container that has WORKDIR set to something you know the contents of and set CMD and ENTRYPOINT to ls
2. Add said container to a pipeline as a service (with no commands ofc)
3. Observe the output, it should be different from WORKDIR's contents.

Expected behavior

Working directory inside the container should be left alone and be the same set in the container.

System Info

{"source":"https://github.com/woodpecker-ci/woodpecker","version":"2.7.0"}

docker-compose config:

version: '3'

services:
  woodpecker-server:
    image: woodpeckerci/woodpecker-server:v2.7.0
    ports:
      - 5000:8000
      - 10000:9000
    volumes:
      - ./data:/var/lib/woodpecker/
      - /etc/ssl/certs:/etc/ssl/certs:ro
      - /etc/timezone:/etc/timezone
      - /etc/docker/certs.d:/etc/docker/certs.d:ro
    environment:
      - WOODPECKER_OPEN=true
      - WOODPECKER_HOST=REDACTED
      - WOODPECKER_GITEA=true
      - WOODPECKER_GITEA_URL=REDACTED
      - WOODPECKER_GITEA_CLIENT=a3439c88-9061-4ce7-b3dc-64500fd5257f
      - WOODPECKER_GITEA_SECRET=REDACTED
      - WOODPECKER_GITEA_SKIP_VERIFY=true
      - WOODPECKER_AGENT_SECRET=REDACTED
      - WOODPECKER_ADMIN=Gr3qi
      # - WOODPECKER_LOG_LEVEL=debug
      - WOODPECKER_AUTHENTICATE_PUBLIC_REPOS=true
      #- WOODPECKER_MIGRATIONS_ALLOW_LONG=true
      - WOODPECKER_BACKEND_DOCKER_VOLUMES=/etc/ssl/certs:/etc/ssl/certs:ro,/etc/timezone:/etc/timezone,/etc/docker/certs.d:/etc/docker/certs.d:ro
  # woodpecker-agent:
    # image: woodpeckerci/woodpecker-agent:v2.6.0
    # command: agent
    # restart: always
    # depends_on:
      # - woodpecker-server
    # volumes:
      # - /var/run/docker.sock:/var/run/docker.sock
      # - /etc/ssl/certs:/etc/ssl/certs:ro
      # - /etc/timezone:/etc/timezone
      # - /etc/docker/certs.d:/etc/docker/certs.d:ro
    # environment:
      # - WOODPECKER_SERVER=woodpecker-server:9000
      # - WOODPECKER_AGENT_SECRET=REDACTED
      # - WOODPECKER_BACKEND_DOCKER_VOLUMES=/etc/ssl/certs:/etc/ssl/certs:ro,/etc/timezone:/etc/timezone,/etc/docker/certs.d:/etc/docker/certs.d:ro

Additional context

No response

Validations

• Read the docs.
• Check that there isn't already an issue that reports the same bug to avoid creating a duplicate.
• Checked that the bug isn't fixed in the next version already [https://woodpecker-ci.org/faq#which-version-of-woodpecker-should-i-use]

[6543]

this migth happen if the service has no commands (as usual) and no environment set, it will count as plugin. and plugins get set there working directory.

using the directory is no workaround but the solution!

this is done because of security considerations.

I think we should add an hint to use directory into the docs :)

In any case normally you should not have to set a workdir as it will be set to the root of where the workflow workspace is mounted at.

@Gr3q does this answer/solve your issue and could you propose a good place where to put that hint into the docs?

[Gr3q]

If you want to put it somewhere it should be above https://woodpecker-ci.org/docs/usage/services#configuration where you note that any container setting WORKDIR in it's Dockerfile might not work as expected and you need to redefine it with the directory field.

this migth happen if the service has no commands (as usual) and no environment set, it will count as plugin. and plugins get set there working directory.

I have environment set.

services:
  - name: database
    image: linuxserver/mariadb
    pull: true
    environment:
      - TZ=Europe/London
      - MYSQL_USER=dockeruser
      - MYSQL_ROOT_PASSWORD=root
      - MYSQL_PASSWORD=testpw
      - MYSQL_DATABASE=api

  - name: signing-server
    image: REDACTED
    pull: true
    # Unfortunately this is needed now...
    directory: /api
    environment:
      - TEST_MODE=True
      - TEST_SIGN_CLIENT_ID=test
      - TEST_SIGN_CLIENT_SECRET=test

In any case normally you should not have to set a workdir as it will be set to the root of where the workflow workspace is mounted at.

This is only good in the use case where a service you want to run might depend on (uses files from) the repo the pipeline runs on.

For the use case when you just want to run something like redis/db as a service it doesn't make sense. To use the workaround you also need to have knowledge about the internals of the image used, which is not always the case.

The question is how the affected images are treated. Either:

• The fault is with the image in question, meaning they should work with their WORKDIR changed. An upstream bug report would need to be opened.
• Or docker images can reasonably assume that the WORKDIR is not changed when their own RUN or ENTRYPOINT commands are used. In this case the fault is whoever runs the image incorrectly.

[6543]

hmm 🤔

well that's not completely wrong ... it has to be improved.

1. document it
2. make it work with WORKDIR set for services ... but we have to consider both cases, the one where users have services using repo files and one who dont

[Gr3q]

Some addition info that the linter says I shouldn't use directory on services

[linter]unit-tests-with-cache: servicesMust validate one and only one schema (oneOf)
[linter]unit-tests-with-cache: services.1Additional property directory is not allowed

[6543]

-> #4127

[pat-s]

Did this get fixed by #4127?

[6543]

I would say #3993 (comment) + mentioned issue should fix it ...

PS: feel free to open a new one if something similar appears and reference this issue here