# Exercise 2 — Volumes, .env, and a Three-Service Stack (medium)
#
# Assume a .env file sits next to this compose file containing:
#   POSTGRES_PASSWORD=devpass123
#
# STEP 1: `api` service, build: ./api, depends_on `db`.
# STEP 2: `db` service, image postgres:16-alpine, with a NAMED volume
#         `pg-data` mounted at /var/lib/postgresql/data (so data survives
#         `docker compose down` without -v).
# STEP 3: `db`'s POSTGRES_PASSWORD environment value must come from the
#         .env file via variable substitution (${POSTGRES_PASSWORD}), NOT
#         be hardcoded in this file — this is the point of the exercise.
# STEP 4: `worker` service, build: ./worker, that shares the SAME image as
#         `api` conceptually but runs a different command — use `build`
#         pointing at the same ./api context, and override the default
#         command with a `command:` key running "worker" instead of the
#         image's default CMD.
# STEP 5: declare the top-level named volume `pg-data`.
#
# No YAML interpreter self-check — verify against the CHECKLIST below.

services:
  api:
    build: ./api
    depends_on:
      - db

  db:
    image: postgres:16-alpine
    environment:
      # TODO 1: pull from .env via substitution, do not hardcode the value
      POSTGRES_PASSWORD: TODO
    volumes:
      # TODO 2: named volume pg-data mounted at the Postgres data dir
      - TODO

  worker:
    # TODO 3: same build context as api
    build: TODO
    # TODO 4: override the default command to run "worker" instead of
    #         whatever CMD the image normally runs
    command: TODO
    depends_on:
      - db

# TODO 5: declare pg-data as a top-level named volume
volumes:
  TODO:

# ---------------------------------------------------------------------------
# CHECKLIST:
# [ ] `db`'s POSTGRES_PASSWORD uses ${POSTGRES_PASSWORD} substitution, and
#     `docker compose config` shows it correctly resolved to "devpass123"
#     when a .env file with that value sits alongside this file.
# [ ] `pg-data:/var/lib/postgresql/data` appears under `db.volumes`, using
#     the NAMED volume (not a host bind-mount path starting with `./` or
#     `/`).
# [ ] `pg-data` is declared under the top-level `volumes:` key.
# [ ] `worker` builds from the same `./api` context as `api` but has its
#     own `command:` overriding the image's default.
# [ ] `docker compose down` (WITHOUT -v) followed by `docker compose up`
#     again would still see the same `pg-data` volume — reasoned about
#     from the file, since named volumes are not removed by a plain
#     `down`.
# ---------------------------------------------------------------------------