fix: prefer .cds marker for project root, add full-stack install smoke test - #512
Merged
Conversation
…e test - find_project_root()/resolve_project_root() now check for a .cds directory (CDS's own state marker, created by cds get/cds use) before falling back to .git/pyproject.toml when walking up from cwd. This prevents an unrelated ancestor repository (e.g. a dotfiles repo at $HOME) from being mistaken for the CDS project root when working in a plain directory such as ~/tmp. - Add regression tests covering both the .cds-preferred case and the existing .git/pyproject.toml fallback for fresh repo checkouts. - Extend build-python-package.yml (reused by testpypi.yml and pypi.yml) with a full cds get -> cds init -> cds up smoke test against the built wheel, from an empty directory with no source checkout on CDS_PROFILE_PATH/CDS_MODULE_PATH. This exercises the real end-user install flow before publishing, catching packaging/get-fetched-layout bugs that a plain 'pip install .' smoke test would miss. - Update RELEASE.md and docs/packaging.md to document the new automated full-stack check. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
SemTiOne
requested changes
Aug 25, 2026
SemTiOne
left a comment
SemTiOne
left a comment
Collaborator
There was a problem hiding this comment.
Good work! However, there are some issues (see inline comments below).
SemTiOne
self-requested a review
August 25, 2026 07:45
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.
Problem
Running
cds get/cds use/cds upfrom a plain working directory (e.g.~/tmp) that happens to sit under an unrelated ancestor directory containing its own.git(like a dotfiles repo at$HOME) causedfind_project_root()/resolve_project_root()to walk past the actual working directory and resolve profiles/modules/config against that unrelated repo instead.Fix
find_project_root()andresolve_project_root()incli/main.pynow check for a.cdsdirectory (CDS's own state marker, created bycds get/cds use) at each ancestor level, checked alongside the existing.git/pyproject.tomlmarkers. A.cds-marked working directory is now recognized as the project root immediately, rather than being shadowed by an unrelated ancestor repo further up the tree..cdsyet) still fall back to.git/pyproject.tomlas before — no behavior change for normal development.CI: full-stack install smoke test
Also closes a gap in release validation: nothing previously exercised the real end-user flow of installing purely from a built wheel (no source checkout) and running
cds get→cds init→cds upagainst a fresh directory.build-python-package.yml(reused bytestpypi.ymlandpypi.yml) now does exactly that — installing the wheel, fetching a profile viacds get --local, initializing it, and bringing up the full docker compose stack, confirming every service reports healthy before the package is published. This is the only check that would have caught bugs limited to the packaged/cds get-fetched layout (missing bundled assets, project-root resolution regressions, etc.).Verified locally end-to-end: built the wheel, installed into a fresh venv, and ran
cds get/cds init/cds upfrom an empty$HOME-based directory — full stack (dagster-daemon,dagster-user-code,dagster-webserver,keydb,postgres,superset,superset-init) came up healthy.Tests
.cds-preferred case and the.git/pyproject.tomlfallback.539 tests, OK (skipped=1).make lint: all checks pass.Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com