Add --wait to corgea upload and print scan page URL when not waiting

[Ibrahimrahhal]

Summary

The corgea upload command previously uploaded a report and only printed a generic "Go to <base_url> to see results." line, with no way to track the specific scan or block until it completed. This brings upload in line with corgea scan:

• Adds a --wait flag to corgea upload. When set, the command blocks until the uploaded scan completes and prints the results (reusing the same wait::run flow as corgea scan semgrep/snyk).
• When --wait is not set, the command now prints the scan page URL (<url>/project/<project>?scan_id=<id>) so the user can track results in the web app, mirroring the tracking link shown by a regular blast scan.

Changes

• src/main.rs: add the wait: bool arg to the Upload subcommand and wire the handler to either wait or print the tracking URL based on the returned ScanUploadResult.
• src/scan.rs:
  • ScanUploadResult now carries project_name so the tracking URL can be built when the server does not return a project_id.
  • read_file_report / read_stdin_report now return Option<ScanUploadResult> instead of discarding it.
  • Added build_scan_url and print_scan_tracking_url helpers.
• src/scanners/fortify.rs: parse now returns Option<ScanUploadResult> so .fpr uploads support --wait and URL printing too.
• skills/corgea/SKILL.md: documented --wait and the default tracking-URL behavior.

Notes

• If the server does not return a scan id (e.g. failed/empty upload), neither waiting nor URL printing occurs — the existing behavior is preserved.
• ./harness check passes (clippy strict, fmt, 448 tests).

Testing

• ./harness check — clippy fix, format, strict clippy, tests (448 passed), deps skill drift: all pass.

  

[cursor]

Production review of --wait / scan-URL tracking for corgea upload. Found concrete merge blockers around project identity when waiting, and --wait failing open when the upload response has no scan id. Details in the inline comments.

  

_{Sent by Cursor Automation: pr-flow}

[cursor]

--wait uses the wrong project identity (breaks --project-name and CI uploads)

ScanUploadResult now carries project_name, but this call discards it:

wait::run(&corgea_config, Some(result.scan_id), result.project_id);

wait::run always re-derives the project from the CWD and unconditionally queries that project's scan list before using the provided scan_id:

pub fn run(config: &Config, scan_id: Option<String>, project_id: Option<String>) {
    let project_name = match utils::generic::get_current_working_directory() { ... };
    let scans_result =
        utils::api::query_scan_list(&config.get_url(), Some(&project_name), Some(1), None);
    // Err => process::exit(1)  — even when scan_id was already known

Impact

• corgea upload report.json --project-name my-svc --wait uploads to my-svc, then waits against the CWD project. If that CWD project is missing/unreachable, wait exits 1 after a successful upload.
• In CI, upload_scan names the project {GITHUB_REPOSITORY}-{GITHUB_PR} (src/scan.rs ~204–214), which almost never matches the checkout directory name — so upload --wait in Actions is likely to fail or print the wrong fallback URL when project_id is absent.

Fix

1. Extend wait::run to accept the upload’s project_name (or skip query_scan_list entirely when scan_id is Some).
2. Pass result.project_name through from this call site (and ideally from run_semgrep / run_snyk too).
3. Add a regression test: upload with --project-name ≠ CWD + --wait must not query/exit on the CWD project.

[cursor]

--wait fails open when the upload returns no scan id

If upload_scan succeeds but the response has no sast_scan_id (allowed for non-chunked uploads — only chunked treats a missing id as hard failure), result is None and this block is skipped. With --wait set, the process still exits 0 without waiting or printing results.

Impact: Users/CI that pass --wait get a false success: the command claimed it would block until completion, but it did not.

Fix: When *wait is true and result is None, error and exit(1) (e.g. “upload succeeded but server did not return a scan id; cannot wait”). Optionally also harden upload_scan so a missing sast_scan_id on any successful response is always a hard failure.

[cursor]

New URL helper / wait wiring has no tests

build_scan_url encodes the production contract for the new default tracking link (project_id vs project_name fallback), and the Upload handler’s --wait vs print-URL branch is entirely untested. ./harness check only re-runs existing suites — nothing asserts this behavior.

Impact: Easy to ship broken links (wrong project segment) or regress the --wait path without CI noticing — especially the project_id = None fallback that motivated adding project_name to ScanUploadResult.

Fix: Add unit tests for both build_scan_url branches, plus a focused test (or CLI expectation) that --wait is not a no-op when wait was requested and that the wait path receives the upload’s project name.

[cursor]

Stale generic “Go to {base_url}” undercuts the new tracking URL

upload_scan still always prints Go to {base_url} to see results. before the caller prints the specific /project/.../?scan_id=... link via print_scan_tracking_url. Users now see two different destinations for the same upload.

Impact: Misleading output (and noisier CI logs) right as this PR’s value prop is “print the scan page URL.”

Fix: Drop or gate this generic line when a ScanUploadResult (with scan id) is being returned, and let the new tracking helper be the sole post-upload navigation hint.

[juangaitanv]

The fallback inserts project_name unencoded into the URL path. CI names include owner/repo, so the generated tracking link routes to the wrong project. Encoding the path segment would keep the fallback link valid.

[yhoztak]

LGTM