Commit Graph

18 Commits

Author SHA1 Message Date
71b64baf45 chore: release v0.5.0 2026-09-09 15:58:45 +02:00
a3c08f6eaa refactor: put every filesystem write behind one module 2026-09-08 15:43:44 +02:00
d7626d9f5e refactor: give every command we run a type of its own 2026-09-08 15:43:42 +02:00
d11b0c68cd feat: drop dotenvy 2026-09-07 13:11:36 +00:00
9d63233d9a feat: detect the django and postgres services
ahab guessed that the django service is called django and the postgres one db,
falling back on AHAB_DJANGO_CONTAINER and AHAB_POSTGRES_CONTAINER. The standard
project layout happens to agree, but nothing enforces it, and a stack naming
them web and database could not use ahab without setting both variables.

One `docker compose config --format json` call, roughly 120ms, resolves the
stack even while it is down, and the services are identified from what they
are rather than what they are called:

- postgres is the service whose image is a postgres flavour, matching postg,
  timescale, pgvector or citus. Nothing else counts.
- django is the service that both builds an image and has
  DJANGO_SETTINGS_MODULE in its environment. A celery worker sharing the same
  build and env_file matches too, so published ports break the tie: the service
  answering requests wins.

Neither guess is allowed to be wrong quietly. No match, or two candidates that
cannot be told apart, is an error naming the services it looked at. There is no
variable to fall back on: both container variables are gone, along with the
guessed defaults they backed up, so an ambiguous stack is fixed in the compose
file rather than worked around per developer.

Every service lookup goes through these rules, so `compose exec` and the whole
django group agree on which container they mean.

POSTGRES_USER and POSTGRES_DB come off the detected service, so dropdb,
createdb, pg_restore and pg_dump stop assuming the role and database are both
literally `db`, falling back to that only when the service declares neither.

Note that env_file entries are merged into a service's environment, so
POSTGRES_* is not safe for identifying the database service: one such line in a
project's .env would make the django service match as well. That is why
identification uses the image and only credentials use the environment.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-09-07 13:11:35 +00:00
c52683e53c chore: upgrade dependencies 2026-09-04 11:23:08 +02:00
63d04a9393 chore: release v0.4.2 2026-03-02 14:51:03 +01:00
27a1ec6d2c chore(release): v0.4.1 2026-02-26 17:45:58 -05:00
e5eddb39f7 chore(release): v0.4.0 2026-02-24 08:53:28 -05:00
7912e9a516 chore(release): v0.3.2 2025-07-01 17:37:36 +02:00
568d126fc2 test: add imports to doc snippets 2025-07-01 17:36:36 +02:00
3077420db2 feat!: respect COMPOSE_FILE env and remove docker command
Read COMPOSE_FILE from env and use it if it is set. Default is still
docker/local/docker-compose.yaml.

BREAKING CHANGE: Removed docker subcommand. Added deprecation notice to
compose subcommand.
2024-10-25 09:37:13 +02:00
7bf76d3ff2 release: v0.3.0
Various qol improvements and custom CommandBuilder mark v0.3.0 release
2023-06-02 17:20:19 +02:00
55d4ae3f6f release: version 0.2.0
Command renamings and compltion generation marks v0.2.0 of `ahab`.
2023-05-27 13:32:46 +02:00
61e7556997 feat: add clap_complete for generating completion files
`ahab generate <shell>` can now be used to generte completion files for
this tool.
2023-05-27 13:28:05 +02:00
22d263dfaa release: v0.1.0
First release of `ahab` cli. All functionality from initial design is
now implemented which means we can move on to adding new stuff and
improving existing stuff.
2023-05-24 00:01:18 +02:00
4762c991a3 feat: finish docker compose cli
Implemented basic wanted functionality for docker compose subcommands.
We currently assume that docker-compose.yaml file is located in
local/docker/ folder.
2023-05-21 23:41:15 +02:00
f6e9c7953a feat: initial commit
Add initial dependencies and change gitignore
2023-05-21 22:12:45 +02:00