Labs · Lesson 05 of 05
Lab: Detect contract-to-CI drift
Use the GitHub projection check to detect stale generated governance and reconcile it without making workflow YAML canonical.
Learning objectives
- Introduce controlled drift in an Ota-owned generated workflow
- Detect drift with ota ci github check
- Reconcile it explicitly with ota ci github sync
Prerequisites
This lab demonstrates one-way CI authority. ota.yaml owns the governance lane, while the generated GitHub file is a provider adapter that must remain identity-bound to the current projection.
Create and detect controlled drift
Render a managed workflow, verify it, then change one contract-owned verification command or the generated file in a disposable branch. The check should identify stale projection state rather than treating the provider file as new contract truth.
ota ci github render --workflow verify --target-os linux --output .github/workflows/ota-governance.ymlota ci github check --workflow verify --target-os linux --output .github/workflows/ota-governance.yml --caller .github/workflows/ci.ymlota ci github sync --workflow verify --target-os linux --output .github/workflows/ota-governance.yml --caller .github/workflows/ci.ymlKeep provider ownership intact
Do not move triggers, permissions, secrets, deployment jobs, or runner policy into the Ota projection. The lab proves managed governance drift detection, not complete equivalence between every GitHub Actions behavior and ota.yaml.
Canonical terminology
Evidence boundary for this lesson
Establishes
- You can detect and repair contract-to-CI drift
Does not establish
- All drift scenarios are covered by this exercise
Knowledge check
Why should generated workflow YAML not become canonical execution truth?
It is a provider adapter derived from ota.yaml. Treating edits to generated YAML as authority creates a second source of setup and verification truth.