Repository navigation
fix(deploy): resolve compose project from container labels for no-env calls - #101
Merged
Merged
Conversation
… calls Follow-up to #99 review. ps/logs/down that run without `op run` now go through a compose_p helper (installed per job into $RUNNER_TEMP) that reads the project name from the containers' com.docker.compose.project.working_dir label, falling back to the stack name. `-p "$stack"` silently missed when Compose normalises the dir name (dots, uppercase, leading _/-) or a compose file sets a top-level name:, leaving teardown/rollback a no-op (exit 0) and orphaning containers. Also: teardowns no longer require the compose file to exist (down targets the project label; missing file is now a notice), the health check validates stack names like the other loops, redundant export -f removed, and ensure-shared-networks documents that label-based down removes a project-labelled network even after it is marked external.
Reviewer's GuideThe workflow now determines the effective Docker Compose project from container labels for all no-environment Sequence diagram for label-based Compose project resolutionsequenceDiagram
participant Workflow
participant Helper as compose_p
participant Docker
participant Compose
Workflow->>Helper: compose_p(stack, args)
Helper->>Docker: ps -a filtered by working_dir label
Docker-->>Helper: Effective project label
alt matching containers found
Helper->>Compose: docker compose -p project args from /
else no matching containers or ps failure
Helper->>Compose: docker compose -p stack args from /
end
Compose-->>Workflow: ps, logs, or down result
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
![sourcery-ai[bot]](https://avatars.githubusercontent.com/in/48477?s=60&v=4){kind=small}
There was a problem hiding this comment.
Hey - I've found 4 issues
Prompt for AI Agents
Please address the comments from this code review:
## Individual Comments
### Comment 1
<location path=".github/workflows/deploy.yml" line_range="407" />
<code_context>
+ [[ -n "$compose_file" ]] \
+ || echo "::notice::compose file missing for removed stack $stack; tearing down by project label"
+ echo "🛑 Stopping $stack"
+ compose_p "$stack" down || echo "::warning::down failed for $stack"
done
</code_context>
<issue_to_address>
**Teardown stops a sibling stack**
When two stack directories resolve to the same Compose project name, `compose_project` resolves a project name from one stack's working-directory label, but `docker compose down` acts on that project name, not that working directory. When two stack directories normalize to the same project name or specify the same top-level `name:`, tearing down either one also stops the other stack's containers.
Reject duplicate resolved project names before deployment, or make teardown target only containers belonging to the selected working directory.
Also at `.github/workflows/deploy.yml:696`, `.github/workflows/deploy.yml:801`, `.github/workflows/deploy.yml:1224`, `.github/workflows/deploy.yml:1296`.
</issue_to_address>
### Comment 2
<location path=".github/workflows/deploy.yml" line_range="1296" />
<code_context>
+ [[ -n "$compose_file" ]] \
+ || echo "::notice::compose file missing for removed stack $stack; tearing down by project label"
+ echo "🛑 Stopping $stack"
+ compose_p "$stack" down || echo "::warning::down failed for $stack"
done
</code_context>
<issue_to_address>
**Rollback stacks fail to restart**
When a rollback tears down a stack while a project-labelled network is idle, configured as shared or external, and needed by a restored stack, `compose_p`'s `down` removes the network. Rollback's earlier `ensure-shared-networks.sh` runs before these teardowns and is not rerun, so a later `up` fails.
Preserve shared or external networks during teardown, or rerun `ensure-shared-networks.sh` after teardown and before redeployment.
Also at `.github/workflows/deploy.yml:1224`.
</issue_to_address>
### Comment 3
<location path=".github/workflows/deploy.yml" line_range="362" />
<code_context>
+ p=$(docker ps -a \
+ --filter "label=com.docker.compose.project.working_dir=${LIVE_REPO_PATH%/}/$1" \
+ --format '{{.Label "com.docker.compose.project"}}' 2>/dev/null \
+ | sort -u | awk 'NR == 1') || p=""
+ printf '%s\n' "${p:-$1}"
+ }
</code_context>
<issue_to_address>
**Other project containers remain running**
When containers from multiple Compose project names share a stack's working-directory label, such as after a project-name change, `compose_project` sorts the labels and returns only the first, so `compose_p` runs health checks or `down` against just that project; the other project's containers remain running or the wrong containers are checked.
Handle all matching project labels, or uniquely identify the intended project instead of silently choosing the first.
Also at `.github/workflows/deploy.yml:860-862`, `.github/workflows/deploy.yml:1083-1084`.
</issue_to_address>
### Comment 4
<location path=".github/workflows/deploy.yml" line_range="363" />
<code_context>
+ --filter "label=com.docker.compose.project.working_dir=${LIVE_REPO_PATH%/}/$1" \
+ --format '{{.Label "com.docker.compose.project"}}' 2>/dev/null \
+ | sort -u | awk 'NR == 1') || p=""
+ printf '%s\n' "${p:-$1}"
+ }
+ # usage: compose_p <stack> <compose args...>
</code_context>
<issue_to_address>
**Orphaned project resources remain**
When a stack has no containers but still has project-labelled resources, and its Compose project name differs from its stack name, `compose_project` falls back to the stack name, so `compose_p ... down` targets the wrong project and leaves the remaining project-labelled resources behind.
Identify the project from remaining Compose resources before falling back to the stack name.
Also at `.github/workflows/deploy.yml:364`, `.github/workflows/deploy.yml:862`, `.github/workflows/deploy.yml:1084-1085`.
</issue_to_address>Sourcery assessment
Needs a human reviewer. 4 findings to address first, and if project-label resolution selects the wrong Compose project or the no-file Compose commands do not behave as expected, health checks and rollback/teardown can fail, or the wrong containers can be stopped during a production deployment. Reverting restores the previous commands, but it cannot undo an outage, failed deployment, or containers already removed.
Blocking findings: .github/workflows/deploy.yml:407, .github/workflows/deploy.yml:1296, .github/workflows/deploy.yml:362, .github/workflows/deploy.yml:363
Sourcery review: when containers from more than one Compose project share a stack's working_dir label (e.g. leftovers after a project rename), compose_project returned only the first, so health checks missed the others and down left them running. compose_projects now returns all distinct matches and compose_p runs the command for each (stdin from /dev/null so compose can't eat the loop input), failing if any project's command fails.
…; review nits Independent review of #101: with no containers in the stack dir, compose_p fell back to `-p <stack>`, which matches a same-named project running from any directory — teardown (now ungated on the compose file) could down it and the health check could pass on its containers. compose_projects now returns nothing in that case (down no-op, health check fails as "no containers"). The foreign check captures docker output before grep -q to avoid SIGPIPE under pipefail. Nits: update the stale project-name comment, drop the unused helper source in Deploy dockge, and build the health-check failed_stacks JSON with jq.
owine
added a commit
that referenced
this pull request
Oct 10, 2026
…ir labels (#103) QA review of #101. compose_projects is now scripts/deployment/lib/compose-project.sh, checked out at job.workflow_sha and copied to $RUNNER_TEMP by the deploy, health-check and rollback jobs (replaces three inline "keep in sync" copies). - Stale working_dir: containers reused from an older checkout/manual `up` keep their original working_dir label, so a stack whose containers all came from another dir also named <stack> is now resolved by its normalised project name (with a ::warning::) instead of returning nothing. Previously a critical stack in that state failed the health check ("no containers") and triggered a rollback every deploy. - Foreign same-named project: still left alone, but now with a ::warning:: instead of a silent no-op down. - The fallback no longer passes the raw stack name to `docker compose -p` (rejected for uppercase/dots); the label lookup uses the normalised name. - health-check gains a compose-workflow checkout; rollback's checkout is now unconditional (its continue-on-error moves to the network step only). - New scripts/testing/test-compose-project.sh (17 cases, fake docker on PATH).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follow-up to #99, from an independent review of 82ffe9a (no blockers; these were the latent findings). Land before Renovate bumps the consumer pins past b293264, so callers pick up both together.
Changes
compose_phelper (installed per job into$RUNNER_TEMP/compose-project.sh, three identical copies in deploy / health-check / rollback): resolves the stack's Compose project from the containers'com.docker.compose.project.working_dirlabel (fallback: stack name) and runsdocker compose -p <project>from/. Replaces-p "$stack"at all 9 no-env call sites (removed-stack teardown, 3× diagnosticsdc, 2× failure cleanup, health check, per-stack + whole-tree rollback teardown).-p "$stack"silently no-op'd (exit 0, orphaned containers) when Compose normalises the dir name (., uppercase, leading_/-— all allowed by the stack regex) or a file sets top-levelname:.awk 'NR==1'nothead(no SIGPIPE under pipefail); a failingdocker psfalls back instead of aborting.downtargets the project label; a missing file is now a::notice::.export -f dump_failed_stack(only called from subshells).ensure-shared-networks.shdocuments that label-baseddownremoves a project-labelled network even after the file marks itexternal(only when idle).compose_p.Verification
cdlines).My.Stack→ resolvesmystack,psfinds it,downremoves it (previously a silent no-op); top-levelname: someothername→ resolves + removed; unknown stack → fallback, 0 rows; trailing slash onLIVE_REPO_PATHhandled.dozzleto the expected project with correct container counts; extracted health-check script →status=healthyon both.Summary by Sourcery
Resolve no-environment Compose projects from container labels to make diagnostics, health checks, and cleanup reliable across normalized or explicitly named stacks.
Bug Fixes:
Enhancements:
Documentation: