0d2cbdb423
Genericize forge-detection code: gitea→forge/generic_forge, GITEA_ACTOR→FORGE_ACTOR. Drop .gitea byte-identity test assertions (keep GitHub-side + contract conformance). Add test_no_forge_mentions.py guard test (REQ-230). Delete completed migration docs (NOVA_MIGRATION.md, NOVA_AWS_MIGRATION.md). Move NO_HUMANS_THESIS.md to .ciagent/ (internal artifact). Strip ciagent-internal provenance from synced docs (REQ-/D-/P-/CAP- IDs, milestone headers, .ciagent/PROJECT.md citations). Trim README.md (reusable deploy section, local key rotation paragraph). Fix version-tag drift (@v1.13→@v1.19, acdl/→nova/). ---ci--- project: acdl phase: 1 milestone: v1.20 status: execute requirements: [REQ-230, REQ-231, REQ-232] ---/ci---
Nova Pipelines
Overview
Nova uses declarative pipeline contracts (YAML) as the single source of truth. GitHub workflows implement the same contract (byte-identical across forges). The shell runner (scripts/run_ci.sh) mirrors the CI pipeline locally so that every stage that runs in CI can be reproduced on a developer machine without a forge.
Existing Pipelines
| Pipeline | File | Stages | Triggers |
|---|---|---|---|
| Nova CI | ci.yml |
lint, test, check-only |
push/PR to main |
| Nova Deploy | contract.yml |
validate-contract, resolve-stack, terraform-plan, checkov, confidence, apply, publish-outputs, deploy-uptime, comment-outputs |
push/PR to main (consumer repos via workflow_call) |
| Nova Modules Lifecycle | modules-lifecycle.yml |
platform-vpc-apply, lifecycle-apply, lifecycle-modify, lifecycle-destroy, l2-lifecycle-apply, l2-lifecycle-modify, l2-lifecycle-destroy, platform-vpc-destroy |
PR to main + workflow_dispatch |
How to Write a Pipeline
- YAML structure:
name,environment,triggers(withpushandpull_requestbranch arrays),runner,python_version, and astages[]list. - Each stage is an object with
name,command,required(boolean), and optionalinstall(pip install command) +description(human-readable summary). - Validate the resulting YAML against
schemas/pipeline.schema.json(CI) orschemas/deploy-pipeline.schema.json(deploy).
How to Wire a Pipeline
- Create the workflow YAML in
.github/workflows/<name>.yml. - Both workflows must implement the same stages, commands, triggers, and runner declared in the contract.
scripts/run_ci.shmirrorsci.ymllocally so the same stages run without a forge.- Consumer repos reference the deploy pipeline via
uses: acdl/.github/workflows/deploy.yml@vX.Y.
Dependencies
scripts/run_ci.sh— local CI mirror that runs theci.ymlstages.scripts/run_platform.sh— platform pipeline runner that implements thecontract.ymlstages.- Workflow YAMLs in
.github/workflows/. - Schemas in
schemas/(pipeline.schema.json,deploy-pipeline.schema.json).
How to Test Pipelines
tests/test_pipeline_contract.py— validates each pipeline YAML against its schema, asserts workflow conformance (byte-identical workflows with the same stages/commands/triggers), and testsscripts/run_ci.shexecution against the contract.
Adding a New Pipeline
- Create
pipelines/<name>.ymlusing the structure above. - Create or extend the schema in
schemas/for the new pipeline shape. - Create the workflow YAML in
.github/workflows/<name>.yml. - Extend
scripts/run_ci.shif a local mirror of the new pipeline is needed. - Write or extend tests in
tests/test_pipeline_contract.pyto assert schema validity and workflow conformance.