Jon Chery
ad3cc5f129
acdl-ci / Lint (pull_request) Successful in 7s
acdl-ci / Test (pull_request) Successful in 4m3s
acdl-ci / Platform check-only (offline) (pull_request) Successful in 21s
acdl-modules-lifecycle / CI VPC apply (pull_request) Failing after 1m25s
acdl-modules-lifecycle / L1 lifecycle (alb) (pull_request) Has been skipped
acdl-modules-lifecycle / L1 lifecycle (cloudfront) (pull_request) Has been skipped
acdl-modules-lifecycle / L1 lifecycle (ecr) (pull_request) Has been skipped
acdl-modules-lifecycle / L1 lifecycle (ecs-cluster) (pull_request) Has been skipped
acdl-modules-lifecycle / L1 lifecycle (ecs-service) (pull_request) Has been skipped
acdl-modules-lifecycle / L1 lifecycle (iam-role) (pull_request) Has been skipped
acdl-modules-lifecycle / L1 lifecycle (kms-key) (pull_request) Has been skipped
acdl-modules-lifecycle / L1 lifecycle (rds) (pull_request) Has been skipped
acdl-modules-lifecycle / L1 lifecycle (s3) (pull_request) Has been skipped
acdl-modules-lifecycle / L1 lifecycle (uptime) (pull_request) Has been skipped
acdl-modules-lifecycle / L1 lifecycle (vpc) (pull_request) Has been skipped
acdl-modules-lifecycle / L1 lifecycle (waf) (pull_request) Has been skipped
acdl-modules-lifecycle / CI VPC destroy (pull_request) Successful in 44s
Two architectural changes: 1. Created terraform/ci-vpc/ — a short-lived VPC for L1 module lifecycle testing, separate from the long-lived platform VPC. Created before VPC-dependent modules (alb, ecs-service, rds, uptime) are tested, destroyed after. Outputs (vpc_id, subnet_ids, sg_id, cluster_arn) are passed to those modules via scripts/run_lifecycle_test.sh + run_lifecycle_destroy.sh wrappers that inject the CI VPC outputs into the example contracts. 2. Updated the workflow to use ci-vpc-apply → lifecycle (with artifact passing) → ci-vpc-destroy (always runs). 8 module-specific fixes: - s3: unique bucket names (acdl-ci-s3a-simple/complex) instead of globally-taken 'my-simple-bucket' - kms-key: alias name with no spaces (locals.tf → alias/acdl-ci-kms) - iam-role: example contract uses role_name (not name, which the interface doesn't declare) - ecs-service: example contract uses family (not name); VPC inputs (cluster_arn, subnets, security_group) injected by CI VPC wrapper - uptime: added subnets, security_group, cluster_arn to interface + module; network_configuration is dynamic (only when subnets provided) - rds: added subnet_ids input + db_subnet_group resource (conditional on subnet_ids being non-empty) - alb: removed hardcoded placeholder sg/subnet values from examples; vpc_id + subnets + security_group injected by CI VPC wrapper - cloudfront: removed invalid placeholder WAF ARN from complex example Regression: 479 passed, 0 skipped, 5 deselected. All 24 example contracts pass --check-only. ---ci--- project: acdl phase: P59 milestone: v1.11 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 engine 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 |
rds |
aws_db_instance — Relational database (PostgreSQL, MySQL, etc.) with multi-engine support |
README |
kms-key |
aws_kms_key — Customer-managed KMS key with rotation enabled (per-stack CMK) |
README |
uptime |
aws_ecs_service — Uptime-kuma monitoring on ECS Fargate with alert channels |
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.