How evidence flows in
- CI runs on your release branch (bootstrapped workflow templates include an evidence upload step)
- Pipeline POSTs metrics and report paths to
/api/evidence/upload - LaneSync parses JUnit XML and other report formats
- Tests link to features via
sdlc.yamlpatterns, CI env vars, or GitHub issue references - Dashboard shows scorecards, anomalies, and exportable reports
Evidence upload requires CI authentication (GitHub OIDC or LaneSync API key). Tenant is derived from the verified token — not from an unauthenticated
org body field.Feature linking
LaneSync resolves test cases to features through multiple strategies:
Example
sdlc.yaml mapping:
Regression detection
Between releases, LaneSync compares test run history per test case ID (tc-id). Anomalies include:
- Tests that passed in the previous release but fail now
- New failures on features marked as release-critical
- Coverage drops beyond configured thresholds (when coverage reports are uploaded)
GET /api/quality/anomalies.
Quality reports
Export aggregated quality data for auditors or release reviews:
Filter by owner, repo, milestone, test type, and environment.
Multi-environment uploads
LaneSync CI templates upload evidence for all three environments automatically:
Each environment keeps its own evidence row per milestone so you can compare dev vs staging vs production quality side-by-side in the scorecard. See CI evidence upload for configuration details.
Required artifacts
The evidencing stage can require specific artifact types before approval:CI configuration
Bootstrapped workflows defaultSDLC_API_URL to https://lanesync.dev. Self-hosted deployments should set the SDLC_API_URL repository variable. See CI evidence upload.