fix(cli): resolve list/wait projects by repo URL, not directory name (COR-1577)#122
Open
juangaitanv wants to merge 2 commits into
Open
fix(cli): resolve list/wait projects by repo URL, not directory name (COR-1577)#122juangaitanv wants to merge 2 commits into
juangaitanv wants to merge 2 commits into
Conversation
…(COR-1577) list/wait now resolve the canonical project via GET /api/v1/projects?repo_url= (with an old-backend safety guard and CWD-name fallback when there's no git remote); dropped the brittle client-side scan.project==name filter; added mutually-exclusive --project-name/--repo override flags; replaced the silent empty table and bare "Error querying scan list" with clear miss messages. CLI-only — no backend/persisted-state changes. Residual of COR-1493.
Addresses four review findings on the COR-1577 repo-URL resolver:
1. Boundary-aware repo match (was a substring `contains`): the backend's
`repo_url__icontains` returns siblings like `org/repo-v2` for slug
`org/repo`, and the old guard could confirm the wrong project. Now matches
on a path-segment boundary (equal or ends-with `/<slug>`, after stripping
`.git`/trailing slash).
2. Subdirectory invocation: resolution used `Repository::open`, which only
succeeds at the repo root, so `list`/`wait` from a subdir fell back to the
subdir basename. New `discover_repo_url` walks up via `Repository::discover`.
3. Surface hard resolver failures: `resolve_project` now returns a Result and
propagates network/auth/5xx from `/projects` instead of silently falling
back to the local-directory project; a clean no-match (or 404 on an old
backend) stays a soft fallback.
4. Skip redundant resolution: `list --issues --scan-id` hits
`/scan/{id}/issues`, which ignores the project, so the extra `/projects`
round-trip is now skipped.
Adds unit tests (boundary match, sibling rejection, 404-soft vs 5xx-hard) and
integration tests (no `/projects` call for `--issues --scan-id`, resolution
from a subdirectory).
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
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.
What & why
corgea list,corgea list --issues, and standalonecorgea waitresolved "which project" by the current-directory basename and asked the backend for an exact, case-sensitive match againstProject.name. When the checkout directory name differs from the stored project name — the Bank of Hope case, dirdotnet-azure-web-tsbvs projectbohappdev/dotnet-azure-web-tsb— three commands misbehaved:corgea list --issues→ exit 1, "Project with name '…' doesn't exist."corgea list→ exit 0, silent empty scan table (no error)corgea wait(no--scan-id) → exit 1, "Error querying scan list"This is the residual of COR-1493 (which fixed only the
corgea scan→ report-results path). Relates to COR-1577.Approach (CLI-only)
The ticket suggested threading
project_id/scan_id, but the listing endpoints accept neither as a query param. Instead this uses an identity the CLI already has and the backend already indexes — the repo URL:GET /api/v1/projects?repo_url=<git remote slug>, then drive the existing name-basedquery_scan_list/get_scan_issueswith the returned canonical name.repo_urlcontains the slug. Pre-COR-1426 doghouse ignores the param and returns all projects; the guard rejects that, so resolution falls back cleanly.scan.project == project_namefilter.--project-name/--repooverride flags tolistandwait.No doghouse changes, no new persisted CLI state, no new backend query param.
Files
src/utils/generic.rs—extract_repo_slug(org/repo slug; keeps Azure_git).src/utils/api.rs—/projectsresolver (resolve_project_by_repo) with the old-backend guard, and theresolve_projectorchestrator.src/main.rs—--project-name/--repoflags onList/Wait, threaded through.src/list.rs— resolve once (non-SCA arm), drop the client filter, clear miss messaging, keep--jsonstdout clean.src/wait.rs— resolve once, build the scan URL from the resolved numeric id, actionable miss message.src/scan.rs— semgrep/snyk paths now thread their existingproject_nameas the override (thewait::runproject_idarg was not dead after all). BLAST flow untouched.tests/— 14 new integration tests (list_resolution.rs,wait_resolution.rs) + shared helpers, plus 5 new unit tests.Testing
cargo build,cargo clippy --all-targets -- -D warnings,cargo fmt --check: clean.cargo test: 456 passed, 0 failed.Notes for reviewers / ship-gates
src/scan.rschange is display-only for the semgrep/snyk post-scan results URL; the primary BLAST scan flow uses a separateUploadZipResultand never calls the modifiedwait::run.list/list --issues/waiton a mismatched checkout against doghouse ≥ COR-1426; the fallback path against a pre-COR-1426 instance;--repo <unknown slug>; the semgrep/snyk results link.