continuous-intelligence/acdl

Fork 0

Files

T

History

Jon Chery ca99241843

acdl-ci / Lint (push) Successful in 7s

Details

acdl-ci / Test (push) Successful in 27s

Details

acdl-ci / Platform check-only (offline) (push) Successful in 9s

Details

verify(P28-38): code review — 1 P0 auto-fixed, 3 P1 fixes, 2 P1 flagged

---ci---
project: acdl
phase: 28-38
milestone: v1.8
status: verify
lessons:
  - P0 fix: pipelines/deploy.yaml stale terraform/spike paths updated to run_platform.sh
  - P1 fix: removed import sys from inside _emit_resource function body
  - P1 fix: removed unused cpu/memory vars in uptime emission
  - P1 fix: decommission consumerRepo now uses GITHUB_REPOSITORY env
---/ci---

P0: deploy.yaml 3 stage commands referenced removed terraform/spike dir.
P1 fixes: import sys, unused vars, consumerRepo env.
P1 flagged: uptime hardcoded subnet/sg, uses ref not bumped to v1.8.
P2 flagged: deploy-uptime flag standalone, pre-v1.8 READMEs missing NFRs.

Tests: 350 passed.

2026-07-22 22:30:49 +00:00

ci.yaml

feat(P24): platform Lambda + DynamoDB contract ingestion + cross-account IAM

2026-07-22 20:04:10 +00:00

deploy.yaml

verify(P28-38): code review — 1 P0 auto-fixed, 3 P1 fixes, 2 P1 flagged

2026-07-22 22:30:49 +00:00

README.md

docs(P36): schemas/adapters/pipelines READMEs (REQ-97, REQ-98, REQ-99)

2026-07-22 22:22:18 +00:00

README.md

ACDL Pipelines

Overview

ACDL uses declarative pipeline contracts (YAML) as the single source of truth. Both Gitea and GitHub workflows implement the same contract (byte-identical). 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
ACDL CI	`ci.yaml`	`lint`, `test`, `check-only`	push/PR to `main`
ACDL Deploy	`deploy.yaml`	`validate-contract`, `resolve-stack`, `terraform-plan`, `checkov`, `confidence`, `apply`, `publish-outputs`, `deploy-uptime`, `comment-outputs`	push/PR to `main` (consumer repos via `workflow_call`)

How to Write a Pipeline

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

How to Wire a Pipeline

Create byte-identical workflow YAMLs in .gitea/workflows/<name>.yml and .github/workflows/<name>.yml.
Both workflows must implement the same stages, commands, triggers, and runner declared in the contract.
scripts/run_ci.sh mirrors ci.yaml locally 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 the ci.yaml stages.
scripts/run_platform.sh — platform pipeline runner that implements the deploy.yaml stages.
Workflow YAMLs in .gitea/workflows/ and .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 Gitea/GitHub workflows with the same stages/commands/triggers), and tests scripts/run_ci.sh execution against the contract.

Adding a New Pipeline

Create pipelines/<name>.yaml using the structure above.
Create or extend the schema in schemas/ for the new pipeline shape.
Create byte-identical workflow YAMLs in .gitea/workflows/<name>.yml and .github/workflows/<name>.yml.
Extend scripts/run_ci.sh if a local mirror of the new pipeline is needed.
Write or extend tests in tests/test_pipeline_contract.py to assert schema validity and workflow conformance.