CI evidence upload

CI pipelines upload evidence to LaneSync so the EVIDENCING stage can verify quality gates and power scorecards. Bootstrapped workflows do this with the LaneSync upload action — your CI writes standard report files, and LaneSync normalizes them server-side.

LaneSync receives report files only — never your source code. This is identical on Full and Lite (Minimal) plans. The upload action strips code snippets from SARIF before sending, and tool-generated coverage HTML (which embeds source files) is never uploaded — LaneSync renders the coverage view from the parsed coverage numbers instead.

Overview

The action runs on your development branch (environment dev), release branches (staging), and published releases (production). Pull request runs skip the upload.

Bootstrapped workflow

During bootstrap LaneSync pushes a language-specific CI workflow plus the upload action to .github/actions/lanesync-upload/action.yml. The workflow’s last step is:

- name: Upload evidence to LaneSync
  uses: ./.github/actions/lanesync-upload
  if: always()
  with:
    api-url: ${{ vars.SDLC_API_URL || 'https://lanesync.dev' }}
    api-key: ${{ secrets.LANESYNC_API_KEY }}
    dev-branch: "main"                # your development branch
    release-prefix: "release/"        # your release branch prefix
    pipeline: "CI — Build & Test"     # example — must match a check in sdlc.yaml

if: always() uploads evidence even when tests fail, so failures are recorded for audit. The upload itself never fails your build — problems appear as workflow warnings and in the job summary.

Self-hosted customers set the SDLC_API_URL repository variable. See Enterprise self-hosting.

Action inputs

Input	Default	Description
`api-url`	`https://lanesync.dev`	LaneSync API base URL
`api-key`	empty	LaneSync API key; when empty the action uses GitHub OIDC
`dev-branch`	`main`	Pushes to this branch upload as `dev`
`release-prefix`	`release/`	Pushes to `<prefix>*` upload as `staging`, version = branch suffix
`pipeline`	`CI — Build & Test`	Evidence type; should match a required check in `sdlc.yaml`

Outputs: evidence-id and upload-status (success | failed | skipped).

Supported report formats

The action picks up these files from the workspace root (or standard build directories) automatically:

Report	Formats and file names
Unit tests	JUnit XML (`pytest-junit.xml`, `phpunit-junit.xml`, `ctest-junit.xml`, `test-results.xml`, `junit.xml`, all `target/surefire-reports/TEST-.xml`, all `build/test-results//TEST-*.xml`), `jest-results.json`, `go-test.json`, `rspec-results.json`
Coverage	Cobertura (`coverage/cobertura.xml`, `coverage/cobertura-coverage.xml`, `coverage.xml`), JaCoCo (`target/site/jacoco/jacoco.xml`, `build/reports/jacoco/test/jacocoTestReport.xml`), Clover (`coverage/clover.xml`), LCOV (`coverage/lcov.info`), Go (`coverage.out`)
SAST	SARIF 2.1 — `sast.sarif` (OpenGrep, Semgrep, CodeQL, …)
CVE	Trivy JSON — `trivy.json`

Coverage format is detected from file content, so a mislabeled file is still parsed correctly. Files larger than 5 MB are skipped with a warning. LaneSync derives unit test counts, the coverage percentage, and SAST/CVE counts from the parsed reports, so the evidence badge, the detail view, and your sdlc.yaml quality gates always agree. SARIF severities follow the same grading as Semgrep/OpenGrep and GitHub code scanning:

SARIF	LaneSync bucket
rule `security-severity` ≥ 9.0	critical
`security-severity` 7.0–8.9, or level `error`	high
`security-severity` 4.0–6.9, or level `warning`	medium
`security-severity` below 4.0, or level `note`	low

A numeric security-severity always wins over the level. A result without a level inherits the rule’s defaultConfiguration.level, then warning (SARIF §3.27.10). Bootstrapped workflows scan source only: OpenGrep excludes .github, coverage/, the generated unit-tests.html/integration-tests.html, and the language’s build and dependency directories (build, target, dist, node_modules, vendor, …). Tool-generated report HTML and third-party code never count against your SAST gates. Trivy reports every severity (CRITICAL,HIGH,MEDIUM,LOW) so the max_medium gate can be enforced. Gradle workflows resolve a gradle.lockfile for the scan when none is committed, because Trivy reads Gradle dependencies only from lockfiles.

Report views

The View full report and Download links on the Quality Insights page serve self-contained HTML that LaneSync renders from the parsed reports: unit tests (failures first, with messages and stack traces), coverage (lowest-covered files first), SAST findings, and CVEs (most severe first, with fixed versions). Each page records the repository, version, environment, and CI run, so a downloaded copy is self-describing audit evidence. Views open in a sandboxed page with no scripts. Code snippets are never stored.

Authentication

LaneSync API key

A workspace admin creates a key in Settings → System → CI API Keys
Store it as the repository secret LANESYNC_API_KEY
The bootstrapped workflow passes it to the action via api-key

When using an API key, the org in the payload must match the key’s workspace.

GitHub Actions OIDC

When no API key is set, the action requests a short-lived GitHub OIDC token with audience lanesync. The job needs:

permissions:
  id-token: write
  contents: read

No long-lived secrets are required — the token is cryptographically bound to the repository. Tenant is always derived from the verified token or API key, never from an unauthenticated org field.

POST /api/evidence/upload

Auth: Authorization: Bearer <lsk_* API key | OIDC JWT> Required fields: org, repo, version, pipeline, metrics The body may be sent gzip-compressed with Content-Encoding: gzip (the action always does). The decompressed body may be up to 25 MB.

{
  "org": "acme",
  "repo": "api",
  "version": "1.4.0",
  "environment": "staging",
  "pipeline": "CI — Build & Test",
  "run_id": "35814220887",
  "metrics": {
    "unit_tests": { "total": 122, "passed": 120, "failed": 2 },
    "coverage": { "line_percent": 91 },
    "sast_scan": { "vulnerabilities": { "critical": 0, "high": 1, "medium": 0 } },
    "security": { "tool": "trivy", "vulnerabilities": { "critical": 0, "high": 0, "medium": 0 } }
  },
  "test_report_files": [{ "filename": "pytest-junit.xml", "content": "<testsuites>…" }],
  "coverage_files": [{ "filename": "cobertura.xml", "format": "cobertura", "content": "<coverage…" }],
  "sast_files": [{ "filename": "sast.sarif", "format": "sarif", "content": "{…}" }],
  "cve_files": [{ "filename": "trivy.json", "format": "trivy", "content": "{…}" }],
  "reports": { "unit_tests": "<html>…</html>" }
}

Field	Notes
`run_id`	GitHub Actions run id (`GITHUB_RUN_ID`). LaneSync links the evidence to `https://github.com/<org>/<repo>/actions/runs/<run_id>`. With OIDC auth, the verified token’s `run_id` claim is used instead
`metrics`	CI-computed summary. Unit test, coverage and SAST/CVE counts are overridden by LaneSync when the matching report file parses successfully. An `integration_tests` block with `total: 0` is dropped, so “not run” is never shown as passing
`test_report_files`	Parsed into individual test cases and linked to features (Quality tracking)
`coverage_files`, `sast_files`, `cve_files`	Normalized into per-file coverage, SAST findings, and CVE findings. Re-uploading for the same milestone, pipeline, and environment replaces the previous findings
`reports`	Optional fallback HTML views keyed by `unit_tests`, `integration_tests`, `sast_scan`, `security`. Each is replaced by the LaneSync-rendered view when the matching report file parses. A `coverage` entry is always ignored

Response:

{
  "evidenceId": "uuid",
  "message": "Evidence uploaded successfully",
  "structured": { "coverageFiles": 42, "sastFindings": 1, "cveFindings": 0, "persisted": true }
}

Status	Condition
`200`	Success
`400`	Missing required fields
`401`	Missing or invalid CI credentials
`403`	`org`/`repo` does not match token identity
`404`	Org not installed or no open milestone
`413`	Body larger than 25 MB after decompression

The action retries network errors, 429, and 5xx up to three times; other statuses are reported once as a warning.

Upload a single test report

POST /api/evidence/upload-report — multipart form, file field report. Same CI auth required. Use this for ad-hoc JUnit uploads outside the standard pipeline.

Pipeline identity

Set the upload action pipeline input to the exact GitHub check name for that workflow (the same name you list under required_checks in sdlc.yaml). Bootstrapped CI always produces unit-tests.html, integration-tests.html, and coverage/index.html (placeholders on empty repos) so day-zero bootstrap never blocks, and uploads them together with sast.sarif, trivy.json, and the native test and coverage reports as a workflow artifact. That artifact stays in your GitHub account; coverage/index.html is not sent to LaneSync.

Custom pipelines

If you maintain your own workflow instead of the LaneSync template:

Add LaneSync to an existing CI pipeline

Emit standard reports from your tests and scanners, then add the upload action as the last step.

Troubleshooting

Issue	Fix
Summary shows “Upload: Skipped (no credentials)“	Add the `LANESYNC_API_KEY` secret, or `permissions: id-token: write` for OIDC
`401` CI authentication required	API key revoked or OIDC token not minted — check the workflow warnings
`403` org/repo mismatch	Ensure body `org`/`repo` match the GitHub repo running the workflow
`404` no open milestone	Create a milestone with a matching version string
Tests show 0 total	Check the “Collect reports” log line `Detected: tests=[…]` — your report file name must be in the supported list above
Coverage shows 0%	Confirm the coverage file exists after tests and is one of the supported formats
Evidence not showing	Uploads run only on the development branch, release branches, and published releases — not on pull requests

See API Reference for full endpoint documentation.

Get Started

Concepts

Guides

Dashboard

Reference

Enterprise

CI evidence upload

Overview

Bootstrapped workflow

Action inputs

Supported report formats

Report views

Authentication

LaneSync API key

GitHub Actions OIDC

POST /api/evidence/upload

Upload a single test report

Pipeline identity

Custom pipelines

Add LaneSync to an existing CI pipeline

Troubleshooting

​Overview

​Bootstrapped workflow

​Action inputs

​Supported report formats

​Report views

​Authentication

​LaneSync API key

​GitHub Actions OIDC

​POST /api/evidence/upload

​Upload a single test report

​Pipeline identity

​Custom pipelines

Add LaneSync to an existing CI pipeline

​Troubleshooting

Overview

Bootstrapped workflow

Action inputs

Supported report formats

Report views

Authentication

LaneSync API key

GitHub Actions OIDC

POST /api/evidence/upload

Upload a single test report

Pipeline identity

Custom pipelines

Troubleshooting