Add ability to easily run the pattern library (Storybook)

[lb-]

It would be great to have a single command to set up and run the pattern library (Storybook).

Development instructions are here https://docs.wagtail.org/en/stable/contributing/developing.html#using-the-pattern-library

This would need to run two servers, the Wagtail / Django server against the test database and also the Storybook local development server.

e.g. make pattern-library - which would run the following...

export DJANGO_SETTINGS_MODULE=wagtail.test.settings_ui
# Assumes the current environment contains a valid installation of Wagtail for local development.
./wagtail/test/manage.py migrate
./wagtail/test/manage.py createcachetable
./wagtail/test/manage.py runserver 0:8000

# In a separate terminal: - serves by default at :6006
npm run storybook

[lb-]

Here is my first attempt but it's failing - not sure how to get the right 'file' path access and also not sure how to resolve the issue where the non-profile services still run (hence the port conflict as pattern library is hard-coded to use port 8000).

This is using the profiles feature - https://docs.docker.com/compose/profiles/

  db_test:
    container_name: "db_test"
    image: postgres:12.3-alpine
    environment:
      POSTGRES_USER: wagtail
      POSTGRES_DB: wagtail
      POSTGRES_PASSWORD: changeme
    volumes:
      - postgres-data:/var/lib/postgresql/data
    restart: "no"
    expose:
      - "5432"
  web_test:
    container_name: "web_test"
    profiles:
      - pattern-library
    build: ./
    working_dir: /code/wagtail
    command:
      - ./wagtail/test/manage.py migrate
      - ./wagtail/test/manage.py createcachetable
      - python manage.py runserver 0.0.0.0:8000
    restart: "no"
    volumes:
      - ./wagtail:/code/wagtail:delegated,rw
      - node_modules:/code/wagtail/node_modules/
    ports:
      - "8020:8000"
    environment:
      DJANGO_SETTINGS_MODULE: "wagtail.test.settings_ui"
      DATABASE_URL: "postgres://wagtail:changeme@db/wagtail"
      PYTHONPATH: "/code/wagtail:/code/wagtail:$PYTHONPATH"
    depends_on:
      - db_test
      - storybook
  storybook:
    container_name: "storybook"
    profiles:
      - pattern-library
    build:
      context: .
      dockerfile: Dockerfile.frontend
    working_dir: /code/wagtail
    ports:
      - "6006:6006"
    volumes:
      - ./wagtail:/code/wagtail:delegated,rw
      - node_modules:/code/wagtail/node_modules/
    command: bash -c "echo 'Copying node_modules, this may take a few minutes...' && rsync -rah --info=progress2 /node_modules /code/wagtail/ && npm run storybook"
    restart: "no"
    tty: true

makefile

pattern-library: ## Set up the test database and application then run the pattern library
	docker-compose --profile pattern-library up

[lb-]

@jsma just curious, will the changes on #71 lead us down a path where it's easier to start the Docker container with different Django settings / ENV vars?

[jsma]

Goodness, Docker keeps sprouting features and I can't keep up ;)

As far as setting a COMPOSE_PROFILES variable, yes, that could be done in the .env that I introduced.

I'm still digesting the profiles feature...that would mean we could leave the frontend container out of the picture if all you wanted to do was spin up bakerydemo to edit backend Wagtail code? Nice!

It would also allow us to have a single giant docker-compose.yml with all the optional services vs what I'm used to, which is specifying carefully constructed compose files to be merged into a single config e.g. docker compose -f docker-compose.yml -f docker-compose.elastic.yml -f docker-compose.test.yml build depending on the situation.

As far as Django settings, my PR only introduced an .env file for the purposes of the docker build process, which in turn passes the DATABASE_URL to be picked up by bakerydemo's settings. We'll also need a .env for configuring Elasticsearch (setting the version, authentication, etc.) which I'm hoping to polish/update my existing docker-compose.yml for Elastic to contribute soon.

At any rate, I did not want to step on the toes of the existing bakerydemo/.env or docker-compose.yml but there's nothing stopping us from using .env to configure any setting where bakerydemo is expecting environment variables (or any other docker service for that matter).