crunchloop / crunchloop/devcontainer
compose: RenderEntrypointWrapper doesn't gate entrypoint/command on overrideCommand
- 主要语言
- Go
- 星标
- 5
- 派生
- 0
- 平均合并
- 6 小时 17 分钟
- 30 天内合并 PR
- 15
描述
## Summary
`compose.RenderEntrypointWrapper` (added in #103) is a faithful port of the reference `devcontainers/cli` `generateFeaturesComposeOverrideContent`, with one deliberate gap: it does **not** implement `overrideCommand` gating of the original entrypoint/command.
## Reference behavior
In `src/spec-node/dockerCompose.ts` the CLI computes:
```ts
const userEntrypoint = overrideCommand ? [] : composeEntrypoint || (imageEntrypoint…);
const userCommand = overrideCommand ? [] : composeCommand || (imageCmd…);
// …emits `command: ` only when userCommand !== composeCommand
```
When `overrideCommand` is **true**, both the original entrypoint and command are zeroed — the generated wrapper runs the feature entrypoints, then `exec "$@"` hits empty args and falls through to the `while sleep 1 & wait $!; do :; done` keep-alive.
## Our behavior
`RenderEntrypointWrapper` always preserves the original entrypoint (service's `entrypoint:`, else the image `ENTRYPOINT`) and never zeroes the command or emits a `command:` override. We do not read `cfg.OverrideCommand` on the compose path at all (`serviceToRunSpec` also ignores it).
## Why this is low priority
Per the dev container spec, `overrideCommand` defaults to **false for Docker Compose** (true only for image/Dockerfile). With it false, the reference takes the `composeEntrypoint || …` / `composeCommand || …` branches — i.e. preserves exactly what we preserve. So for the default compose case (and the DAP devcontainer this was built for), our output is behaviorally equivalent to upstream.
The only divergence is an explicit `"overrideCommand": true` on a **compose** devcontainer: upstream would drop the service command and rely on the wrapper's keep-alive; we keep the command.
## Options
- Implement `overrideCommand` gating in the compose path for full parity (zero entrypoint/command + emit keep-alive command when `overrideCommand` is true), or
- Leave as-is and document the limitation.
## Related
- PR #103 (compose feature security metadata + entrypoint chaining)
- Separate follow-up: image-source (non-compose) entrypoint chaining is also not yet implemented (`newRunSpec` doesn't consume `cfg.Entrypoints`).
贡献指南
调研方向
首先定位 compose.RenderEntrypointWrapper 和 serviceToRunSpec,然后将它们的行为与 src/spec-node/dockerCompose.ts 和 newRunSpec 路径进行比较。确认 cfg.OverrideCommand 的表示方式,并测试明确的 compose overrideCommand=true 情况。完成的标准是:通过将 entrypoint 和 command 置零并保留 keep-alive 行为来与 upstream 匹配,或者在选择该选项时记录这一限制。
由索引模型根据 Issue 内容生成。
评估
- 技术栈
- docker, docker-compose, go
- 领域
- devops, infrastructure
- Issue 类型
- 功能
- 难度
- 4/5
- 预计耗时
- 3-5 天
- 活跃度
- 冷清
- 描述清晰度
- 基本清楚
- 新手友好度
- 48/100