Configure sdlc.yaml

This guide walks through configuring sdlc.yaml for your repository. LaneSync reads this file from GitHub on every stage-details request.

Before you start

Repo setup wizard completed (or sdlc.yaml exists at repo root)
You know your GitHub Actions job names (they must match required_checks exactly)
You have decided: trunk-based or release-branch workflow

Base structure

version: v1
name: my-app

stages:
  planning: { ... }
  development: { ... }
  testing: { ... }
  evidencing: { ... }
  deployment: { ... }

Stage-by-stage configuration

Planning

planning:
  require_milestone: true
  require_issues_assigned: true

Ensures every release has a milestone and assigned owners before development.

Development

development:
  branch: main
  deploy_target: dev
  required_checks:
    - CI — Build & Test

required_checks lists GitHub Actions check names that must pass on main. Only failures on these checks block the stage.

Testing

Release-branch
Trunk-based

testing:
  branch_pattern: "release/*"
  deploy_target: staging
  required_checks:
    - CI — Build & Test

Create release/v1.0.0 after development. Gates evaluate the release branch.

Omit or adjust branch_pattern during wizard setup for trunk-based flow. Required checks run on main.

Evidencing

evidencing:
  required_reviewers:
    min_approvals: 1
    teams:
      - engineering-leads

Quality reports arrive via the lanesync-upload action in CI and staging deploy workflows. teams maps to GitHub teams that can approve the evidence PR.

Deployment

deployment:
  target: production
  promotion: manual
  requires_evidence_approval: true

Production promotion stays manual until you integrate automated deploy workflows.

Quality gates (`quality_gates`)

The repo setup wizard Quality gates step pre-fills recommended defaults (aligned with Sonar Sonar way coverage and zero-tolerance security posture, plus OWASP Dependency-Check-style CVE limits). They are written to sdlc.yaml unless you clear fields or choose Do not enforce quality gates.

Field	Wizard default	Notes
`coverage.min_line_percent`	80	Common CI gate for line coverage
`security.max_critical` / `max_high`	0 / 0	No critical or high CVEs
`security.max_medium`	20	Bounded medium backlog
`sast_scan.max_critical` / `max_high`	0 / 0	No critical or high SAST findings
`sast_scan.max_medium`	10	Bounded medium SAST backlog

quality_gates:
  coverage:
    min_line_percent: 80
  security:
    max_critical: 0
    max_high: 0
    max_medium: 20
  sast_scan:
    max_critical: 0
    max_high: 0
    max_medium: 10

Clear individual wizard fields to omit that check from YAML. After bootstrap, edit the block in GitHub like any other policy change — the webhook refreshes live gate resolution within ~60 seconds. Gate Verdict on Quality reports and the HTML export (click GO or NO-GO) use these thresholds together with required CI checks.

Staging environment (`hasStaging`)

The repo wizard hasStaging toggle controls whether your pipeline includes a staging environment between development and production. When enabled (Dev → Staging → Prod), bootstrap generates:

deploy_target: staging under stages.testing
Staging deploy workflow templates (when you do not already have deployment workflows)
Staging deploy workflow includes lanesync-upload (pipeline name matches your staging required check)

When disabled (Dev → Prod), the testing stage omits the staging deploy target and staging-specific artifacts. Required checks still run — on the release branch or development branch depending on release model.

Enable staging when QA validates releases in a pre-production environment before evidencing and production promotion.

Release model (`releaseModel`)

The wizard releaseModel field sets how code moves from development to testing.

Trunk (trunk)
Release-branch (release-branch)

Development and testing both target the development branch (usually main). There is no separate release branch to cut.In sdlc.yaml, stages.testing.branch_pattern equals the development branch name — for example main.Best for: Continuous delivery teams that ship directly from trunk.

After development completes, you cut a release branch (e.g. release/v1.2.0) from the development branch. Testing gates evaluate checks on that branch.In sdlc.yaml, stages.testing.branch_pattern uses your release prefix — for example release/** when the wizard prefix is release/.Use Cut release branch in the milestone dashboard to create the branch. See Milestone details — Branch Actions.

SDLC Enforce is always required regardless of release model. Only checks listed in required_checks block a stage when they fail.

Apply changes

Edit sdlc.yaml in a branch
Open a PR and merge to the default branch
LaneSync webhook fires → re-parses checks → updates rulesets → re-syncs milestones

After renaming a CI job, update required_checks in the same PR as the workflow change to avoid phantom BLOCKING badges.

Validate configuration

Check	How
Check names match CI	Compare with `.github/workflows/*.yml` job `name:` fields
Rulesets updated	GitHub → Repository → Rulesets
Stage details reflect file	Dashboard → Milestone → Stage details (live read, 60s cache)

Full schema

See sdlc.yaml schema reference for every field and constraint.

Update LaneSync Workflows

Refresh managed GitHub Actions templates — separate from editing sdlc.yaml.

Add LaneSync to existing CI

Keep your pipeline; wire evidence and gates manually.

Get Started

Concepts

Guides

Dashboard

Reference

Enterprise

Configure sdlc.yaml

Before you start

Base structure

Stage-by-stage configuration

Quality gates (`quality_gates`)

Staging environment (`hasStaging`)

Release model (`releaseModel`)

Apply changes

Validate configuration

Full schema

Update LaneSync Workflows

Add LaneSync to existing CI

​Before you start

​Base structure

​Stage-by-stage configuration

​Quality gates (quality_gates)

​Staging environment (hasStaging)

​Release model (releaseModel)

​Apply changes

​Validate configuration

​Full schema

​Related

Update LaneSync Workflows

Add LaneSync to existing CI

Before you start

Base structure

Stage-by-stage configuration

Quality gates (`quality_gates`)

Staging environment (`hasStaging`)

Release model (`releaseModel`)

Apply changes

Validate configuration

Full schema

Related