Background & problem

Users quite often define maintenance scripts, test suites, debugging systems in their Compose files which they don't want to run when they do docker-compose up.

Personally, this is something I've wanted since almost the start. My daily paper cut is writing docker-compose run web ./test.sh instead of docker-compose run test.

I wrote a diplomatic aggregation of potential solutions and data points in #1896. This is an opinionated proposed solution we can use as a strawman.

Proposed solution

I propose we add a top-level tasks configuration option, which takes the same options as the services option. It's a bit like a service, but doesn't start when you run docker-compose up. It only works with docker-compose run. Service and task names must be unique so they don't collide.

As an example, let's add a task to the Django getting started guide app:

services:
  db:
    image: postgres
    environment:
      - POSTGRES_DB=postgres
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=postgres
  web:
    build: .
    command: python manage.py runserver 0.0.0.0:8000
    volumes:
      - .:/code
    ports:
      - "8000:8000"
    depends_on:
      - db
tasks:
  test:
    build: .
    entrypoint: python manage.py test
    depends_on:
     - db

You would run the tests by running docker-compose run test.

Because we've specified entrypoint in the task definition, we can also pass arguments to the tests: docker-compose run test myapp/test_views.py

Questions

• What am I not thinking about?
• tasks is a nice bike shed -- go at it
• How does this interact with Compose spec?
• Having to specify entrypoint instead of command is a bit clumsy. Users will automatically write command then wonder why their arguments aren't working as expected. Maybe there is a better solution here?

/cc @aanand @shin- in case there is any historical knowledge I am not aware of. (hi!)