Jon Chery
90be5839ab
Phase 26 — platform-pipelines-and-release-automation: - platform-test.yml: PR pipeline (lint + unit-test + integration-test + schema-validation) replacing ci.yml for PRs; integration-test runs run_platform.sh --check-only for every contracts/*.yaml - primitives-plan.yml: PR pipeline with matrix over all 9 L1 primitives (s3, vpc, ecs-cluster, ecs-service, iam-role, alb, ecr, cloudfront, waf) - patterns-plan.yml: PR pipeline with matrix over all 2 L2 modules (static-assets, microservice) - release.yml: push-to-main pipeline computing next semver tag (PATCH for regular phases, MINOR for milestone completions), updating floating MAJOR.MINOR + MAJOR tags, and creating GitHub releases - run_primitive_plan.sh: plan-only/check-only runner for a single L1 primitive (adapter compile + structure validation offline) - run_pattern_plan.sh: plan-only/check-only runner for a single L2 pattern (environment check + contract validate + resolve + adapter + structure validation offline) - contracts/microservice.yaml: sample consumer contract for the microservice L2 module (schema-compliant scalar inputs) - instance.json for 8 L1 primitives (vpc, ecs-cluster, ecs-service, iam-role, alb, ecr, cloudfront, waf) so the primitives-plan matrix can run the adapter offline; s3 already had one - tests/test_release_logic.py: unit test for semver computation (PATCH bump, MINOR bump on milestone, floating tag format) - tests/test_pipeline_contract.py: 19 new tests validating the 4 platform workflows exist and conform (stages, matrices, triggers, permissions) DEVIATION: The microservice pattern (run_pattern_plan.sh --check-only microservice + run_platform.sh --check-only contracts/microservice.yaml) fails at the adapter stage due to a pre-existing resolver ref-id mismatch for multi-resource L1s (resolver emits ref:vpc.subnet_ids but the expanded resource id is vpc-subnet). This predates Phase 26 and is out of scope for pipeline automation; the static-assets pattern passes end-to-end. The microservice contract is schema-valid and resolves correctly (11 resources); only the adapter compilation of multi-resource L1 refs fails. VERIFICATION: - bash scripts/run_ci.sh: PASS (lint + test + check-only) - python3 -m pytest tests/ -v: 266 passed - bash scripts/run_primitive_plan.sh --check-only s3: PASS - bash scripts/run_pattern_plan.sh --check-only static-assets: PASS - All 9 primitives pass run_primitive_plan.sh --check-only - All instance.json validate against stack.schema.json ---ci--- project: acdl phase: 26 milestone: v1.7 status: execute ---/ci---
ACDL Modules
Reusable building blocks for cloud infrastructure. Each module is
self-documented with a README.md following the
template.
How the modules work
There are two kinds of module:
- Primitives — a single cloud resource or a small group of
related resources (e.g. a VPC with subnets and routing). Each primitive
has an
interface.jsondeclaring its inputs and outputs, and aREADME.mdin plain language. - Modules — a pattern that references multiple primitives to
deploy a complete stack (e.g. an ECS Fargate microservice). Each module
has a
composition.jsondeclaring its children and wires.
The substrate adapter (adapters/terraform/adapter.py) compiles a
module instance to infrastructure. Each module's README documents which
resources it creates.
Primitives
| Module | What it creates | README |
|---|---|---|
s3 |
aws_s3_bucket — a single S3 bucket |
README |
vpc |
aws_vpc + aws_subnet + aws_route_table + aws_internet_gateway — VPC with subnets and routing |
README |
ecs-cluster |
aws_ecs_cluster — ECS Fargate cluster |
README |
ecs-service |
aws_ecs_task_definition + aws_ecs_service — Fargate service with task definition |
README |
iam-role |
aws_iam_role — IAM role with assume-role policy |
README |
alb |
aws_lb + aws_lb_target_group + aws_lb_listener — Application Load Balancer |
README |
ecr |
aws_ecr_repository — ECR container image repository |
README |
cloudfront |
aws_cloudfront_distribution + aws_cloudfront_origin_access_control — CloudFront distribution with S3 origin via OAC |
README |
waf |
aws_wafv2_web_acl — WAFv2 Web ACL (CloudFront-scoped) |
README |
Modules
| Module | What it references | README |
|---|---|---|
microservice |
6 primitives (vpc, cluster, ecr, iam-role, alb, ecs-service) | README |
static-assets |
3 primitives (s3, cloudfront, waf) | README |
Registry
Module versions are tracked in registry.json. Both primitives and
modules are registered.
Template
New modules should use README-TEMPLATE.md as their starting point.
Module patterns (roadmap)
The current composition.json mechanism is a thin pattern layer. A future
redesign will let a consumer dynamically create a module directly from the
contract file (an agentic "composition" flow). That is on the roadmap, not
implemented today.