fix: docker-compose.yml generated by init diverges from running stack — recreate breaks services #354

New issue

Closed

opened 2026-04-07 12:39:20 +00:00 by dev-bot · 0 comments

dev-bot commented

2026-04-07 12:39:20 +00:00

Collaborator

Problem

The docker-compose.yml is generated by disinto init (via lib/generators.sh). When init is re-run or the compose template changes, the generated compose can diverge from the running stack. Running docker compose up -d <service> then recreates containers with different settings, breaking the factory.

Observed: docker compose up -d edge recreated Forgejo on a new network (disinto_default instead of disinto_disinto-net). The old Woodpecker and agents containers stayed on the old network. Forgejo came up with a different container name (disinto-forgejo vs disinto-forgejo-1). Services could no longer reach each other.

Specific issues found:

Forgejo image tag changed from 11.0 to 1 (template default vs actual)
Network name changed (disinto_disinto-net vs disinto_default)
Container names changed (-1 suffix vs no suffix)
Edge service was missing from the running stack but present in the generated compose

Root cause

The compose file is treated as both a template (generated by init) and a runtime config (used by docker compose up/down). When the template changes, it creates a gap between what's running and what the compose file describes.

Proposed solution

The compose file should not be regenerated on re-run if it already exists. disinto init line that generates compose should skip if the file exists (it already does this for some files: "already exists, skipping"). Verify this check works for docker-compose.yml.

For image tag drift: the compose template should use the same tag as the running instance. Either pin the version in projects/*.toml or detect the running version.

Affected files

bin/disinto or lib/generators.sh (compose generation — ensure skip-if-exists)
docker-compose.yml template (pin Forgejo image tag)

Acceptance criteria

disinto init re-run does not regenerate docker-compose.yml if it exists
docker compose up -d <service> does not recreate unrelated services
Network name is consistent between generated compose and running stack

## Problem The docker-compose.yml is generated by `disinto init` (via lib/generators.sh). When init is re-run or the compose template changes, the generated compose can diverge from the running stack. Running `docker compose up -d <service>` then recreates containers with different settings, breaking the factory. Observed: `docker compose up -d edge` recreated Forgejo on a new network (disinto_default instead of disinto_disinto-net). The old Woodpecker and agents containers stayed on the old network. Forgejo came up with a different container name (disinto-forgejo vs disinto-forgejo-1). Services could no longer reach each other. Specific issues found: - Forgejo image tag changed from 11.0 to 1 (template default vs actual) - Network name changed (disinto_disinto-net vs disinto_default) - Container names changed (-1 suffix vs no suffix) - Edge service was missing from the running stack but present in the generated compose ## Root cause The compose file is treated as both a template (generated by init) and a runtime config (used by docker compose up/down). When the template changes, it creates a gap between what's running and what the compose file describes. ## Proposed solution The compose file should not be regenerated on re-run if it already exists. `disinto init` line that generates compose should skip if the file exists (it already does this for some files: "already exists, skipping"). Verify this check works for docker-compose.yml. For image tag drift: the compose template should use the same tag as the running instance. Either pin the version in projects/*.toml or detect the running version. ## Affected files - bin/disinto or lib/generators.sh (compose generation — ensure skip-if-exists) - docker-compose.yml template (pin Forgejo image tag) ## Acceptance criteria - [ ] `disinto init` re-run does not regenerate docker-compose.yml if it exists - [ ] `docker compose up -d <service>` does not recreate unrelated services - [ ] Network name is consistent between generated compose and running stack