You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When running devsy workspace up . with the docker provider on a compose-based devcontainer, devsy ignored the configured compose project name and always used the sanitized random runner id, spawning a separate compose project instead of reusing an existing one. This PR resolves the project name following the @devcontainers/cli reference precedence so an existing compose project is reused.
Precedence (final, aligned with the reference)
COMPOSE_PROJECT_NAME from the shell session.
COMPOSE_PROJECT_NAME from the collected .env files (first definition wins). devsy passes these same files to docker compose --env-file, so reading COMPOSE_PROJECT_NAME from the same set keeps devsy and the runtime compose invocation consistent.
The sanitized random runner id (devsy's analog of the reference's directory-basename fallback).
devsy passes the resolved name via --project-name, which is Docker Compose's highest-precedence override — exactly the mechanism devsy was already using, just with the wrong value.
Comparison with the official specification
Dev Containers spec (containers.dev): the name field is "A name for the dev container displayed in the UI" — a display name, not a compose project name. The spec's Docker Compose section is silent on project-name derivation. So devcontainer.jsonname is not used.
@devcontainers/cli reference (getProjectName in src/spec-node/dockerCompose.ts): resolves COMPOSE_PROJECT_NAME (shell) → COMPOSE_PROJECT_NAME (<cwd>/.env) → top-level name: (with a guard distinguishing a user-declared name: from compose-go's injected default) → directory basename. devsy matches this ladder, using the random runner id as its final fallback to preserve existing behavior.
Docker Compose (docs.docker.com/compose/how-tos/project-name/): -p flag > COMPOSE_PROJECT_NAME env > top-level name: > project-dir basename > current-dir basename. Since devsy passes the resolved name via --project-name, step 1 (the -p flag) is what takes effect.
TopLevelComposeName reads raw compose fragments, so it only returns user-declared names — never compose-go's injected name: devcontainer default, which is the same distinction the reference's fragment re-check makes.
Known divergence from the reference
devsy reads COMPOSE_PROJECT_NAME from .devcontainer/.env and compose-dir .env files in addition to <workspace>/.env, whereas the reference reads only <workspace>/.env. This is intentional: devsy already passes all of these as --env-file to docker compose, so they are part of compose's own resolution at runtime. Reading from the same set keeps the computed name and the runtime name identical, which is what makes "reuse the existing compose project" work.
Changes
pkg/devcontainer/compose.go:
loadComposeProject no longer unconditionally overwrites the project name with the random runner id; it calls the new resolveComposeProjectName.
resolveComposeProjectName implements the precedence above.
Env-file collection is split into baseEnvFiles (devcontainer config-dir .env + workspace-root .env, used to resolve $COMPOSE_FILE and COMPOSE_PROJECT_NAME) and composeDirEnvFiles (.env files colocated with the resolved compose files, added after compose-file resolution). Deduplication preserves first-seen order.
pkg/compose/projectname.go (new): pure, testable helpers ProjectNameFromEnvFiles and TopLevelComposeName, plus the ComposeProjectNameEnv constant.
pkg/compose/helper.go: added SanitizeProjectName (exported wrapper around the existing sanitization logic) so the devcontainer layer can sanitize the random-id fallback without re-implementing version-dependent character rules.
Notes
stopDockerCompose / deleteDockerCompose are unaffected: they derive the project name from the running container's com.docker.compose.project label, which compose sets from --project-name at up time, so they stay consistent with the new resolution.
The loaded project's Name from compose-go is intentionally not trusted directly, because compose-go falls back to the project directory's base name when no explicit name source is present. Each higher-precedence source is read explicitly instead.
Testing
New unit tests for ProjectNameFromEnvFiles, TopLevelComposeName, and SanitizeProjectName in pkg/compose/projectname_test.go.
New unit tests for resolveComposeProjectName (all precedence levels, multi-file last-wins), baseEnvFiles (collection + dedup), composeDirEnvFiles, and appendEnvFiles in pkg/devcontainer/compose_projectname_test.go.
go vet, gofmt, golines, and golangci-lint v2.12.2 (--new-from-rev=origin/main) all clean; go build ./... passes.
E2e: the full Test up-docker-compose suite is green in CI, including four new specs that assert the resolved project name (top-level compose name:, COMPOSE_PROJECT_NAME from .env, COMPOSE_PROJECT_NAME from the shell, and reuse of the existing compose project on a second up). The shared findComposeContainer helper now resolves the actual compose project name from the dev container labels (rather than assuming the sanitized workspace UID) so the existing multi-service, shutdown, v2-features, and updateRemoteUserUID specs stay green alongside the new ones.
The only failing CI checks are Test up-workspaces (git exit-128) and Test self-update (update --dry-run network call failing instantly at 0.08s) — both environmental flakes unrelated to this change (this PR only touches compose project-name resolution and the up-docker-compose helper; neither test exercises compose). They passed on the prior commit on this same branch and fail from network/git-runner conditions, not from these code changes.
This PR was created by an AI agent (OpenHands) on behalf of the user.
AI Reviewer: run a review on demand. To trigger the first review automatically, go to your organization or repository integration settings. AI can make mistakes. Always validate suggestions.
TIP This summary will be updated as you push new changes.
⚠️ This PR contains unsigned commits. To get your PR merged, please sign those commits (git rebase --exec 'git commit -S --amend --no-edit -n' @{upstream}) and force push them to this branch (git push --force-with-lease).
If you're new to commit signing, there are different ways to set it up:
Sign commits with gpg
Follow the steps below to set up commit signing with gpg:
When running devsy workspace up . with the docker provider on a
compose-based devcontainer, devsy previously ignored the configured compose
project name and always used the sanitized random runner id, spawning a
separate compose project instead of reusing an existing one.
Resolve the project name by trusting compose-go's own resolved
project.Name whenever the user named the project explicitly (shell
COMPOSE_PROJECT_NAME, a .env file, or a compose file's top-level name),
falling back to the sanitized random runner id only when compose-go would
otherwise fall back to its directory-basename default. Delegating to
compose-go (rather than re-parsing compose files by hand) keeps devsy
consistent with Docker Compose's own precedence and correctly interpolates
compose name fields that use variable substitution.
devcontainer.json's name field is deliberately not consulted: per the Dev
Containers spec it is a UI display name, not a compose project name.
Add unit tests for the resolution precedence, including compose-go's own
present-but-empty-shell-env edge case, and an e2e spec plus testdata
(docker-compose-nested-envfile) reproducing the reported issue's exact
layout: a .env colocated with the compose file in a subdirectory distinct
from the workspace root and .devcontainer/.
Document the resolution precedence in the devcontainer.json docs page,
clarifying that devcontainer.json's name does not affect the compose
project name.
Resolves#999.
Note: CodeRabbit is an incremental review system and does not re-review already reviewed commits. This command is applicable only when automatic reviews are paused.
@skevetter, you've reached your PR review limit, so we couldn't start this review.
Next review available in:31 minutes
Limit details: You’ve used the included review currently available.
You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.
How can I continue?
After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.
To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.
How do review limits work?
CodeRabbit enforces per-developer PR review limits within each organization.
For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.
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
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.
Resolves #999.
Summary
When running
devsy workspace up .with the docker provider on a compose-based devcontainer, devsy ignored the configured compose project name and always used the sanitized random runner id, spawning a separate compose project instead of reusing an existing one. This PR resolves the project name following the@devcontainers/clireference precedence so an existing compose project is reused.Precedence (final, aligned with the reference)
COMPOSE_PROJECT_NAMEfrom the shell session.COMPOSE_PROJECT_NAMEfrom the collected.envfiles (first definition wins). devsy passes these same files todocker compose --env-file, so readingCOMPOSE_PROJECT_NAMEfrom the same set keeps devsy and the runtime compose invocation consistent.name:(last declaration wins, matching multi-file override semantics).devsy passes the resolved name via
--project-name, which is Docker Compose's highest-precedence override — exactly the mechanism devsy was already using, just with the wrong value.Comparison with the official specification
containers.dev): thenamefield is "A name for the dev container displayed in the UI" — a display name, not a compose project name. The spec's Docker Compose section is silent on project-name derivation. Sodevcontainer.jsonnameis not used.@devcontainers/clireference (getProjectNameinsrc/spec-node/dockerCompose.ts): resolvesCOMPOSE_PROJECT_NAME(shell) →COMPOSE_PROJECT_NAME(<cwd>/.env) → top-levelname:(with a guard distinguishing a user-declaredname:from compose-go's injected default) → directory basename. devsy matches this ladder, using the random runner id as its final fallback to preserve existing behavior.docs.docker.com/compose/how-tos/project-name/):-pflag >COMPOSE_PROJECT_NAMEenv > top-levelname:> project-dir basename > current-dir basename. Since devsy passes the resolved name via--project-name, step 1 (the-pflag) is what takes effect.TopLevelComposeNamereads raw compose fragments, so it only returns user-declared names — never compose-go's injectedname: devcontainerdefault, which is the same distinction the reference's fragment re-check makes.Known divergence from the reference
devsy reads
COMPOSE_PROJECT_NAMEfrom.devcontainer/.envand compose-dir.envfiles in addition to<workspace>/.env, whereas the reference reads only<workspace>/.env. This is intentional: devsy already passes all of these as--env-filetodocker compose, so they are part of compose's own resolution at runtime. Reading from the same set keeps the computed name and the runtime name identical, which is what makes "reuse the existing compose project" work.Changes
pkg/devcontainer/compose.go:loadComposeProjectno longer unconditionally overwrites the project name with the random runner id; it calls the newresolveComposeProjectName.resolveComposeProjectNameimplements the precedence above.baseEnvFiles(devcontainer config-dir.env+ workspace-root.env, used to resolve$COMPOSE_FILEandCOMPOSE_PROJECT_NAME) andcomposeDirEnvFiles(.envfiles colocated with the resolved compose files, added after compose-file resolution). Deduplication preserves first-seen order.pkg/compose/projectname.go(new): pure, testable helpersProjectNameFromEnvFilesandTopLevelComposeName, plus theComposeProjectNameEnvconstant.pkg/compose/helper.go: addedSanitizeProjectName(exported wrapper around the existing sanitization logic) so the devcontainer layer can sanitize the random-id fallback without re-implementing version-dependent character rules.Notes
stopDockerCompose/deleteDockerComposeare unaffected: they derive the project name from the running container'scom.docker.compose.projectlabel, which compose sets from--project-nameatuptime, so they stay consistent with the new resolution.Namefrom compose-go is intentionally not trusted directly, because compose-go falls back to the project directory's base name when no explicit name source is present. Each higher-precedence source is read explicitly instead.Testing
ProjectNameFromEnvFiles,TopLevelComposeName, andSanitizeProjectNameinpkg/compose/projectname_test.go.resolveComposeProjectName(all precedence levels, multi-file last-wins),baseEnvFiles(collection + dedup),composeDirEnvFiles, andappendEnvFilesinpkg/devcontainer/compose_projectname_test.go.go vet,gofmt,golines, andgolangci-lint v2.12.2(--new-from-rev=origin/main) all clean;go build ./...passes.Test up-docker-composesuite is green in CI, including four new specs that assert the resolved project name (top-level composename:,COMPOSE_PROJECT_NAMEfrom.env,COMPOSE_PROJECT_NAMEfrom the shell, and reuse of the existing compose project on a secondup). The sharedfindComposeContainerhelper now resolves the actual compose project name from the dev container labels (rather than assuming the sanitized workspace UID) so the existing multi-service, shutdown, v2-features, andupdateRemoteUserUIDspecs stay green alongside the new ones.Test up-workspaces(git exit-128) andTest self-update(update --dry-runnetwork call failing instantly at 0.08s) — both environmental flakes unrelated to this change (this PR only touches compose project-name resolution and theup-docker-composehelper; neither test exercises compose). They passed on the prior commit on this same branch and fail from network/git-runner conditions, not from these code changes.This PR was created by an AI agent (OpenHands) on behalf of the user.