Skip to main content
LaneSync goes beyond pass/fail CI badges. It ingests test evidence from your pipelines, links results to features, and surfaces regressions across releases.

​
How evidence flows in

  1. CI runs on your release branch (bootstrapped workflow templates include an evidence upload step)
  2. Pipeline POSTs metrics and report paths to /api/evidence/upload
  3. LaneSync parses JUnit XML and other report formats
  4. Tests link to features via sdlc.yaml patterns, CI env vars, or feat_<issue#> naming in test metadata
  5. Feature-labelled GitHub issues are classified into a stable FEAT-ID (one capability can span several issues — e.g. original work + regression fix)
  6. 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.

​
Linking tests to features

LaneSync resolves test cases to features through multiple strategies: Example sdlc.yaml mapping:
This is separate from issue → FEAT-ID classification (below).

​
Classifying GitHub issues into features

Issues with the feature label appear on the Quality Features tab. LaneSync assigns each issue to a FEAT-ID (stable hash tied to the repo and issue number when it owns a new capability). Regression or fix work should reference the original feature explicitly. LaneSync stores a short link reason on each issue (visible in the dashboard) so auditors can see why an issue shares a FEAT-ID. Removing the feature label hides the issue from the Features tab but keeps history (untracked).

​
Regression detection (anomalies)

Regression is a test result change, not “a new GitHub issue.” LaneSync compares the current release you are viewing against the last release deployed to production (baseline). Comparisons are per environment (staging vs staging, dev vs dev), using each test’s latest run in scope. Anomalies include:
  • Tests that passed at baseline and fail on the current release
  • Tests that failed at baseline and pass now (fixes)
  • Other status flips between baseline and current
Optional query params: milestone, environment. The API response includes current and baseline milestone versions.
If no prior production deployment exists, baseline is empty and the anomaly list is empty (not an error). Coverage drops and flaky patterns may appear in exports when coverage evidence is uploaded; primary anomaly detection today is pass/fail per test case ID (tc-id). View anomalies from the dashboard Quality tab (milestone detail) or via 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:
Bootstrapped CI templates produce placeholder HTML reports even when no tests exist yet, so evidence upload never blocks day-zero repos.

​
CI configuration

Bootstrapped workflows default SDLC_API_URL to https://lanesync.dev. Self-hosted deployments should set the SDLC_API_URL repository variable. See CI evidence upload.