sdlc.yaml

sdlc.yaml is the single source of truth for SDLC policy. Independent repositories use their root file. Organization-managed repositories resolve <org>/.github/sdlc.yaml with optional permitted repository customization. See organization setup. LaneSync reads it from GitHub — never hardcode check names or workflow names in application code.

File location

Independent repository setup places the file at the repository root:

your-repo/
  sdlc.yaml          ← repo root
  .github/workflows/

Organization setup places the shared file at <org>/.github/sdlc.yaml. Covered repositories need a root sdlc.yaml only when the organization allows customization and that repository uses it. See Configure an organization for inheritance and GitHub ruleset locations. LaneSync bootstraps the root file during independent repository setup. You edit configuration like any other source file — commit, push, and LaneSync reconciles the effective policy after the webhook.

Minimal example

version: v1
name: my-app

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

stages:
  planning:
    require_milestone: true
    require_issues_assigned: true

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

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

  evidencing:
    required_reviewers:
      min_approvals: 1

  deployment:
    target: production
    promotion: manual
    requires_evidence_approval: true

Schema overview

Top-level key	Purpose
`version`	Config schema version (currently `v1`)
`name`	Display name for the repository in LaneSync
`stages`	Per-stage gate configuration
`features`	Optional test-to-feature mapping patterns

See the full sdlc.yaml schema reference.

Live reads vs database cache

LaneSync maintains two views of your config:

Consumer	Source	Freshness
`GET /api/milestones/:id/stage-details`	Live from GitHub	60s cache TTL
Sync engine, rulesets, DB `required_checks`	Parsed on webhook push	May lag until push fires

The database required_checks column is a cache. When you rename a CI job, update sdlc.yaml and push — the webhook re-parses checks, updates the DB, re-applies rulesets, and re-syncs milestones through a revision-tracked propagation path. Partial failures remain blocked until recovery.

Propagation on push

When sdlc.yaml is pushed to the default branch: All four steps must happen together. If you add a new consumer of required_checks, wire it into handleSdlcYamlChange in the webhook handler.

Required checks naming

Check names in required_checks must match GitHub Actions job check names (the job name: field, or its job key when no name is set) exactly:

development:
  required_checks:
    - CI — Build & Test    # ← must match workflow job name

GitHub renders checks as Workflow name / Job name. Rulesets match the job portion only. A successful check displayed as Deploy to Staging / deploy therefore satisfies deploy; it does not satisfy a required check named Deploy to Staging. LaneSync-generated deployment starters use the wizard’s first stage-specific check as the job name. Checks inherited from an earlier stage keep the job that already reports them, and every additional required check needs its own reporting job. LaneSync never falls back to project-specific default check names. The only infrastructure constant is SDLC Enforce.

Trunk-based vs release-branch

Release-branch (default)
Trunk-based

development:
  branch: main
testing:
  branch_pattern: "release/*"

Cut release/v1.0.0 after development completes. Testing gates evaluate checks on the release branch.

Configure during the repo setup wizard to promote from main without a release branch.Testing gates evaluate checks on the trunk branch directly.

Feature mapping (optional)

Link test files to external feature IDs for quality tracking:

features:
  - pattern: "src/__tests__/auth*"
    system: github
    external_id: "42"

See Quality tracking.

Get Started

Concepts

Guides

Dashboard

Reference

Enterprise

File location

Minimal example

Schema overview

Live reads vs database cache

Propagation on push

Required checks naming

Trunk-based vs release-branch

Feature mapping (optional)

​File location

​Minimal example

​Schema overview

​Live reads vs database cache

​Propagation on push

​Required checks naming

​Trunk-based vs release-branch

​Feature mapping (optional)

File location

Minimal example

Schema overview

Live reads vs database cache

Propagation on push

Required checks naming

Trunk-based vs release-branch

Feature mapping (optional)