Compare commits

..
3 Commits
Author SHA1 Message Date
Sharang ParnerkarandClaude Opus 4.8 9717a1efda fix(onboarding): targets visibility + unified pipeline by default
CI / Check (pull_request) Successful in 5m36s
CI / Detect Changes (pull_request) Has been skipped
CI / Deploy Agent (pull_request) Has been skipped
CI / Deploy Dashboard (pull_request) Has been skipped
CI / Deploy Docs (pull_request) Has been skipped
CI / Deploy MCP (pull_request) Has been skipped
The onboarding wizard created OnboardedTargets that were invisible in the
dashboard, and triggering a scan failed with "Repository <id> not found":
`/targets/{id}/scan` went through `run_scan`, which consulted the global
`unified_pipeline` flag and fell to the legacy repository pipeline (reads
`repositories`, not `onboarded_targets`).

Agent
- Add `ComplianceAgent::run_target_scan`, always dispatching to the unified
  `run_target` pipeline. The target-scan endpoint operates on
  `onboarded_targets` by construction, so it must not depend on the
  transition flag. `trigger_target_scan` now calls it.
- Default `UNIFIED_PIPELINE` to on (no legacy `repositories` data in prod);
  set `UNIFIED_PIPELINE=0` to opt back to the legacy pipeline.
- Scheduler now scans `onboarded_targets` (via `run_target_scan`) instead of
  the legacy `repositories` collection.

Dashboard
- New Targets page (`/targets`): lists onboarded targets with detected type,
  artifacts, findings count, applicable-scans matrix (on expand), plus Run
  scan and Delete. Sidebar "Repositories" nav becomes "Targets".
- Remove the "Add Repository" form from the Repositories page — onboarding
  is the single entry point (private-repo auth + issue tracker move into the
  onboarding flow, revisable on the target).
- Add `delete_target` server fn.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-07-13 09:22:03 +02:00
sharang 669e1f1b03 feat(onboarding): scan-trigger endpoint + wizard Run-Scan button (#153)
CI / Check (push) Has been skipped
CI / Detect Changes (push) Successful in 4s
CI / Deploy Agent (push) Successful in 3m34s
CI / Deploy Dashboard (push) Successful in 2m56s
CI / Deploy Docs (push) Has been skipped
CI / Deploy MCP (push) Has been skipped
2026-07-12 22:19:32 +00:00
sharang 9e70bd1c8e ci: don't cancel-in-progress for main-branch runs (only pull_request) (#152)
CI / Detect Changes (push) Successful in 3s
CI / Check (push) Has been skipped
CI / Deploy Agent (push) Has been skipped
CI / Deploy Dashboard (push) Has been skipped
CI / Deploy Docs (push) Has been skipped
CI / Deploy MCP (push) Has been skipped
2026-07-12 22:08:58 +00:00
+5 -2
View File
@@ -29,10 +29,13 @@ env:
CARGO_NET_RETRY: "10"
CARGO_HTTP_MULTIPLEXING: "false"
# Cancel in-progress runs for the same branch/PR
# Cancel superseded PR runs, but NEVER cancel main-branch runs — those build and
# deploy per-service images, and cancelling one merge's deploy when the next
# merge lands leaves a service un-deployed (as happened between two back-to-back
# merges). So cancel-in-progress only for pull_request events.
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
cancel-in-progress: ${{ github.event_name == 'pull_request' }}
jobs:
# ---------------------------------------------------------------------------