Skip to content

Adopt SDETKit in your repository (canonical)

Use this page if: you are introducing SDETKit to a team-owned repository and need a staged rollout plan.

Not this page: - First solo run: First run quickstart - CI workflow templates and branch policies: Recommended CI flow (canonical) - Artifact interpretation details: CI artifact walkthrough (canonical)

Adoption objective

Move from local confidence checks to repeatable team gates with machine-readable release evidence.

Stage 0 — install and verify in target repo

Use Install, then verify:

python -m pip install "git+https://github.com/sherif69-sa/DevS69-sdetkit.git"
python -m sdetkit --help
python -m sdetkit gate --help

For maintainers validating the external-install contract itself (from this repository):

python -m pytest -q tests/test_external_first_run_contract.py

Stage 1 — local proof in the team repo

python -m sdetkit gate fast --format json --stable-json --out build/gate-fast.json

This is a signal-producing gate, not a guaranteed-green onboarding command.

Stage 2 — baseline release confidence

python -m sdetkit gate release --format json --out build/release-preflight.json

Add security budgets once the team has agreement on thresholds:

python -m sdetkit security enforce --format json --max-error 0 --max-warn 0 --max-info 0 --out build/security-enforce.json

Stage 3 — CI rollout (handoff)

Use Recommended CI flow as the canonical CI rollout source. It defines:

  • PR fast-gate baseline
  • main/release stricter gates
  • artifact upload conventions
  • progressive tightening without all-at-once friction

Team operating model

  • PR lane: keep gate fast always on.
  • main/release lane: enforce agreed security budgets and release gates.
  • triage: use artifact-first flow via CI artifact walkthrough.

If onboarding fails

Use these in order:

  1. First-failure triage
  2. Adoption troubleshooting
  3. Remediation cookbook