Promote env detection to chunk env init, remove sidecar env/build - #438
Draft
schurchleycci wants to merge 3 commits into
Draft
Promote env detection to chunk env init, remove sidecar env/build#438schurchleycci wants to merge 3 commits into
schurchleycci wants to merge 3 commits into
Conversation
Moves chunk sidecar env and chunk sidecar build into a new top-level chunk env detect command with --format json|dockerfile. Detection is no longer a sidecar-specific concern, and the docker build step is removed from the CLI — callers run docker themselves. Acceptance test renamed from sidecars_build_e2e_test.go to env_detect_e2e_test.go; e2eRunBuild split into e2eRenderDockerfile and e2eDockerBuild to make the two-step flow explicit. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
chunk env init now writes Dockerfile.test by default; --format json opts into the JSON spec. This better reflects the intended use as a project initialization step (detect stack, produce Dockerfile, cache to config) rather than a pure inspection command. Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
schurchleycci
changed the title
hanabel1
reviewed
Jul 14, 2026
| Example: | ||
| chunk sidecar env --dir . | chunk sidecar build --dir .`, | ||
| RunE: func(cmd *cobra.Command, _ []string) error { | ||
| if tag != "" && !validDockerTag.MatchString(tag) { |
Contributor
There was a problem hiding this comment.
we're dropping chunk's tag validation here now that docker build is run by the user instead of by chunk. it'll still reject a bad tag, with its own error - but wasn't sure if it was intentional - just a ux thing i guess!
Contributor
Author
There was a problem hiding this comment.
Yeah, this was intentional - under the assumption we may as well just have the user run docker build themselves
hanabel1
reviewed
Jul 14, 2026
| prompt = f"""You are debugging an environment detection tool inside the chunk CLI. | ||
|
|
||
| `chunk sidecar env` analyses a repository, detects its tech stack, and writes a | ||
| `chunk env detect` analyses a repository, detects its tech stack, and writes a |
Contributor
There was a problem hiding this comment.
err i might be missing this but i can not find the detect subcommand. naming mismatch?
Contributor
Author
There was a problem hiding this comment.
Good catch, this was a naming mismatch - fixed now!
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
hanabel1
approved these changes
Jul 15, 2026
jesseworld22
added a commit
that referenced
this pull request
Aug 13, 2026
The getting-started guide walked new users through build-prompt and code review as its numbered path, with sidecars below it under a heading still marked '(preview)'. Someone following the steps in order never touched a sidecar. README framed the two as co-equal capabilities. Restructure so the sidecar loop is the primary path: - GETTING_STARTED: sidecar creation and the dev loop become Steps 3 and 4, skills become Step 5, and build-prompt/review move below the sidecar material as 'Team review context'. Drop the '(preview)' label. Group the detail sections under a 'Sidecar reference' heading. Lead the auth step with CircleCI, since that is what sidecars need. - README: drop the 'two main capabilities' framing, move context generation below the sidecar quick start. - AGENTS.md: describe sidecars as the primary capability. - SKILLS.md: lead the intro with sidecar setup and the dev loop, and point first-time readers at chunk-sidecar-setup. Also adds the chunk-sidecar-setup skill to the getting-started skills table, which listed only four of the five installed skills. Command-level details in 'Environment setup', 'Syncing', 'First-time sidecar setup', and 'Hook behavior' are left alone pending #438, #462, #491, and #501, which change those commands. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
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
2 participants
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.
Summary
The thinking here: if we want to use dockerfiles as the basis for spinning up lots of sidecars, having a command to generate the dockerfile directly, rather than as a side effect of
chunk sidecar env | chunk sidecar build --dir, may be a smoother experience.chunk env initas a new top-level command that detects a repository's tech stack and writesDockerfile.testto--dir(default), or prints the environment spec as JSON (--format json). The detected spec is saved to.chunk/config.jsonfor reuse bychunk sidecar setup.validate.gothat referencedchunk sidecar env build(a command that never existed); it now correctly suggestschunk sidecar sync.Before / after
Test plan
task testpasses (acceptance + unit)chunk env initwritesDockerfile.testand prints its pathchunk env init --format jsonprints the env spec to stdoutchunk env init --no-saveskips writing.chunk/config.jsonchunk sidecar setupstill works (reuses cached spec from config)🤖 Generated with Claude Code