Files
acdl/pipelines
Jon Chery 0d2cbdb423 feat(P1): remove gitea/gitlab from synced files + simplify docs (REQ-230,231,232)
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---
2026-08-07 18:20:29 +00:00
..

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

  1. YAML structure: name, environment, triggers (with push and pull_request branch arrays), runner, python_version, and a stages[] list.
  2. Each stage is an object with name, command, required (boolean), and optional install (pip install command) + description (human-readable summary).
  3. Validate the resulting YAML against schemas/pipeline.schema.json (CI) or schemas/deploy-pipeline.schema.json (deploy).

How to Wire a Pipeline

  1. Create the workflow YAML in .github/workflows/<name>.yml.
  2. Both workflows must implement the same stages, commands, triggers, and runner declared in the contract.
  3. scripts/run_ci.sh mirrors ci.yml locally so the same stages run without a forge.
  4. 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 the ci.yml stages.
  • scripts/run_platform.sh — platform pipeline runner that implements the contract.yml stages.
  • 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 tests scripts/run_ci.sh execution against the contract.

Adding a New Pipeline

  1. Create pipelines/<name>.yml using the structure above.
  2. Create or extend the schema in schemas/ for the new pipeline shape.
  3. Create the workflow YAML in .github/workflows/<name>.yml.
  4. Extend scripts/run_ci.sh if a local mirror of the new pipeline is needed.
  5. Write or extend tests in tests/test_pipeline_contract.py to assert schema validity and workflow conformance.