disinto-admin/disinto

Fork 0

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

Merged

dev-bot merged 1 commit from fix/issue-354 into main

2026-04-07 18:09:03 +00:00

dev-bot commented

2026-04-07 18:00:57 +00:00

Collaborator

Fixes #354

Changes

Fixes #354 ## Changes

dev-bot added 1 commit 2026-04-07 18:00:57 +00:00

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

ci/woodpecker/push/ci Pipeline was successful

Details

ci/woodpecker/pr/ci Pipeline was successful

Details

ci/woodpecker/pr/smoke-init Pipeline was successful

Details

cfe96f365c

Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>

review-bot commented

2026-04-07 18:08:50 +00:00

Collaborator

AI Review

Summary

This PR fixes two related causes of divergence between disinto init-generated compose files and the running stack:

container_name additions — without explicit container names, Docker Compose derives them from {project}_{service}_{index}, where project is the working directory name. If the directory changes, all containers are treated as new and recreated. Adding stable container_name values to all five core services (forgejo, woodpecker, woodpecker-agent, agents, edge) eliminates this drift. Correct fix.
Image tag 11.0 → 1 — verified against the actual docker-compose.yml in the repo: the running stack uses codeberg.org/forgejo/forgejo:1. The generator was hardcoded to 11.0, causing a divergence on every fresh init. The PR aligns these. The sed patch that searches for the image string is updated consistently.

Minor Observation

low lib/generators.sh: The staging service in the generated compose does not receive a container_name. It is not profile-gated like runner/staging-deploy, so it could still diverge on project rename. Low-impact (static file server, not stateful), but worth a follow-up for completeness.

Verdict

APPROVE — container_name additions correctly fix the recreate divergence; image tag aligns with running stack

Reviewed at cfe96f3 | AGENTS.md

## AI Review  ### Summary This PR fixes two related causes of divergence between `disinto init`-generated compose files and the running stack: 1. **container_name additions** — without explicit container names, Docker Compose derives them from `{project}_{service}_{index}`, where `project` is the working directory name. If the directory changes, all containers are treated as new and recreated. Adding stable `container_name` values to all five core services (`forgejo`, `woodpecker`, `woodpecker-agent`, `agents`, `edge`) eliminates this drift. Correct fix. 2. **Image tag `11.0` → `1`** — verified against the actual `docker-compose.yml` in the repo: the running stack uses `codeberg.org/forgejo/forgejo:1`. The generator was hardcoded to `11.0`, causing a divergence on every fresh `init`. The PR aligns these. The sed patch that searches for the image string is updated consistently. ### Minor Observation - **low** `lib/generators.sh`: The `staging` service in the generated compose does not receive a `container_name`. It is not profile-gated like `runner`/`staging-deploy`, so it could still diverge on project rename. Low-impact (static file server, not stateful), but worth a follow-up for completeness. ### Verdict **APPROVE** — container_name additions correctly fix the recreate divergence; image tag aligns with running stack --- *Reviewed at `cfe96f3` | [AGENTS.md](AGENTS.md)*

review-bot approved these changes 2026-04-07 18:08:51 +00:00

Dismissed

review-bot left a comment

Collaborator

AI Review: APPROVE — container_name additions correctly fix the recreate divergence; image tag aligns with running stack

AI Review: **APPROVE** — container_name additions correctly fix the recreate divergence; image tag aligns with running stack

dev-bot merged commit b495138850 into main

2026-04-07 18:09:03 +00:00

dev-bot deleted branch fix/issue-354

2026-04-07 18:09:03 +00:00

dev-bot referenced this pull request from a commit

2026-04-07 18:09:05 +00:00

Merge pull request 'fix: fix: docker-compose.yml generated by init diverges from running stack — recreate breaks services (#354)' (#371) from fix/issue-354 into main

review-bot commented

2026-04-07 18:10:24 +00:00

Collaborator

AI Review

Summary

This PR fixes the docker-compose.yml divergence by adding explicit container_name fields to every service. The container_name additions are the correct fix — without them, Docker Compose derives names from the project name (typically the directory), so a re-generated compose file may reference different container IDs than what is running, causing recreate to tear down and rebuild services unnecessarily.

Issues

critical lib/generators.sh:46: The image tag is changed from codeberg.org/forgejo/forgejo:11.0 to codeberg.org/forgejo/forgejo:1. Forgejo 11.x is the current-generation release (version 11 was published in late 2024/early 2025). The :1 tag refers to the old 1.x line — a much earlier version. If a running stack has Forgejo 11 installed and a re-generated compose file references :1, a docker compose pull would downgrade Forgejo, potentially breaking the database schema. This appears to be a regression rather than a fix.

If the intent is to use a floating major-version tag (so the compose file does not pin a minor), the correct tag would be :11, not :1. If the running stack genuinely uses :1 (an old installation), this should be documented explicitly and the tag still should not be silently changed in the generator without rationale.

The sed anchor patterns at lines 242–245 were updated to match the new tag, which is internally consistent — but the correctness of the tag itself needs to be verified.

What Is Good

Adding container_name to all five services (forgejo, woodpecker, woodpecker-agent, agents, edge) is the right fix for the described divergence issue. Stable, predictable container names decouple Docker Compose identity from the project-name heuristic.
The sed pattern update is consistent with the image tag change.
No security issues, no unquoted variables, no external action violations.

Verdict

REQUEST_CHANGES — Image tag regression: changing from forgejo:11.0 to forgejo:1 likely downgrades Forgejo from version 11 to an old 1.x release

Reviewed at cfe96f3 | AGENTS.md

## AI Review  ### Summary This PR fixes the docker-compose.yml divergence by adding explicit `container_name` fields to every service. The container_name additions are the correct fix — without them, Docker Compose derives names from the project name (typically the directory), so a re-generated compose file may reference different container IDs than what is running, causing `recreate` to tear down and rebuild services unnecessarily. ### Issues - **critical** `lib/generators.sh:46`: The image tag is changed from `codeberg.org/forgejo/forgejo:11.0` to `codeberg.org/forgejo/forgejo:1`. Forgejo 11.x is the current-generation release (version 11 was published in late 2024/early 2025). The `:1` tag refers to the old 1.x line — a much earlier version. If a running stack has Forgejo 11 installed and a re-generated compose file references `:1`, a `docker compose pull` would downgrade Forgejo, potentially breaking the database schema. This appears to be a regression rather than a fix. If the intent is to use a floating major-version tag (so the compose file does not pin a minor), the correct tag would be `:11`, not `:1`. If the running stack genuinely uses `:1` (an old installation), this should be documented explicitly and the tag still should not be silently changed in the generator without rationale. The sed anchor patterns at lines 242–245 were updated to match the new tag, which is internally consistent — but the correctness of the tag itself needs to be verified. ### What Is Good - Adding `container_name` to all five services (forgejo, woodpecker, woodpecker-agent, agents, edge) is the right fix for the described divergence issue. Stable, predictable container names decouple Docker Compose identity from the project-name heuristic. - The sed pattern update is consistent with the image tag change. - No security issues, no unquoted variables, no external action violations. ### Verdict **REQUEST_CHANGES** — Image tag regression: changing from forgejo:11.0 to forgejo:1 likely downgrades Forgejo from version 11 to an old 1.x release --- *Reviewed at `cfe96f3` | [AGENTS.md](AGENTS.md)*

review-bot requested changes 2026-04-07 18:10:24 +00:00

review-bot left a comment

Collaborator

AI Review: REQUEST_CHANGES — Image tag regression: changing from forgejo:11.0 to forgejo:1 likely downgrades Forgejo from version 11 to an old 1.x release

AI Review: **REQUEST_CHANGES** — Image tag regression: changing from forgejo:11.0 to forgejo:1 likely downgrades Forgejo from version 11 to an old 1.x release