Files

T

Jon Chery 41c3377b96 feat(P67b): lifecycle tests default to plan-only; ACDL_LIFECYCLE_MODE flag overrides to full (REQ-134)

---
ci---
project: acdl
phase: 67b
milestone: v1.12
status: execute
---
/ci---

The modules-lifecycle pipeline now defaults to plan-only (fast, no AWS
mutation, no credentials, no cost) so it runs on every PR. A CI variable
ACDL_LIFECYCLE_MODE (workflow_dispatch input 'lifecycle_mode', default
'plan') overrides to 'full' for the real apply->modify->destroy against
live AWS.

Scripts: run_lifecycle_test.sh / run_lifecycle_destroy.sh /
run_l2_lifecycle_test.sh / run_l2_lifecycle_destroy.sh read the flag and
dispatch to --plan-only (plan mode) or --apply/--destroy (full mode).
Destroy is a no-op exit 0 in plan mode (nothing was applied). VPC-output
injection is gated on full mode.

Workflows: both .github + .gitea (byte-identical) expose lifecycle_mode
as a workflow_dispatch input (choice: plan/full), pass it via env:
ACDL_LIFECYCLE_MODE to every lifecycle step, skip ci-vpc-apply +
ci-vpc-destroy + Read-CI-VPC-outputs in plan mode, and run the lifecycle
+ l2-lifecycle jobs with if: always() so they execute (plan-only) even
when ci-vpc-apply is skipped.

Contract + schema: pipelines/modules-lifecycle.yml gains default_mode:
plan; the schema accepts default_mode (enum plan|full) and a richer
workflow_dispatch inputs shape.

Tests: 14 new tests in test_lifecycle_mode_flag.py (script dispatch) +
10 new tests in TestModulesLifecyclePipeline (workflow flag wiring,
byte-identity, plan-mode skips). Updated test_platform_vpc_destroy to
reflect the plan-mode skip. 516 tests pass; smoke-tested plan mode on
the s3 module (--plan-only green, no AWS apply).

2026-07-29 13:16:03 +00:00

ci.yml

refactor(P57): contract surface redesign + rename + .yml repo-wide

2026-07-27 21:37:40 +00:00

contract.yml

refactor(P57): contract surface redesign + rename + .yml repo-wide

2026-07-27 21:37:40 +00:00

modules-lifecycle.yml

feat(P67b): lifecycle tests default to plan-only; ACDL_LIFECYCLE_MODE flag overrides to full (REQ-134)

2026-07-29 13:16:03 +00:00

README.md

feat(P61): L2 lifecycle pipeline — extend matrix + workflows + tests

2026-07-28 20:17:27 +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.yml`	`lint`, `test`, `check-only`	push/PR to `main`
ACDL 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`)
ACDL 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 (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.yml 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.yml stages.
scripts/run_platform.sh — platform pipeline runner that implements the contract.yml 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>.yml 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.