aws-samples / aws-samples/sample-autonomous-cloud-coding-agents

feat(ci): mirror deploy-semantic mise deploy dependencies in deploy.yml

Open
#843 0 comments 0 reactions 0 assignees View on GitHub
ci-cd enhancement infra-cdk
Dominant language
TypeScript
Stars
143
Forks
46
Avg merge
3d 9h
Merged PRs (30d)
20

Description

### Component

CDK / infrastructure (`cdk/mise.toml`, `.github/workflows/deploy.yml`)

### Describe the feature

Make it explicit — and ideally enforced — which `[tasks.deploy]` dependencies in `cdk/mise.toml` apply to the CI deploy path, because today none of them do and nothing says so.

`.github/workflows/deploy.yml:262` deploys with `npx cdk deploy` directly, so it runs no `depends` entry from `cdk/mise.toml:80`. Verified on `main` (`c77f1bd0`):

```
.github/workflows/deploy.yml:262
run: npx cdk deploy --app cdk/cdk.out --all --require-approval never

cdk/mise.toml:80
depends = [":clean:disk"]
run = "npx cdk deploy"
```

CI passes no `stackName` context, so it deploys the default `backgroundagent-dev` (`cdk/src/main.ts:68`) — the same stack a local `mise //cdk:deploy` targets, via a path with different preparation.

Nothing is broken today, and the divergence is not simply an oversight: `clean:disk` begins `rm -rf cdk.out`, while the CI job deploys `--app cdk/cdk.out` against a cloud assembly downloaded as an artifact from the `build` workflow. Having CI invoke the mise task would delete the assembly it is about to deploy. So skipping `clean:disk` in CI is correct — it is a local-synth disk concern with no meaning on a runner.

### Use case

The list reads as "things that happen before a deploy" but means "before a *local* deploy", and there is no signal at the definition to say which. A dependency added for deploy-*correctness* rather than local hygiene therefore applies to laptops only, silently.

That case is about to exist. #705 adds a `:preflight:log-delivery` dependency performing a one-time migration a stack must complete before its next deploy, or that deploy fails mid-update and rolls back. On the CI path it would not run, and the failure it prevents would return with nothing pointing at the cause.

### Proposed solution

Either is cheap; the second is more durable.

1. **Classify at the definition.** Mark each `depends` entry as local-only or deploy-semantic, and port the deploy-semantic ones into `deploy.yml` as their own steps. Add a note on `[tasks.deploy]` that `deploy.yml` is a parallel path inheriting nothing, so the next person does not assume otherwise.

2. **Make the divergence loud.** A drift check asserting every deploy-semantic `depends` entry has a corresponding `deploy.yml` step converts "someone remembers" into a build failure — the same shape as the existing `check:transitive-pin-sync` guard for a pin that must be mirrored in two places.

Explicitly **not** proposing that CI call the mise task, for the `cdk.out` reason above.

### Other information

Found while verifying #705, and deliberately kept out of that PR: the divergence predates it, and #705's own reviewer asked for a migration plus a documented operator step rather than deploy-path parity.

Also unaddressed by either option: a bare `cdk deploy` on a developer machine skips the same dependencies. Closing that would mean moving deploy-semantic preparation inside the CDK app's synth path, which is a materially larger change.

Contributor guide

Open the contributing guide

Research direction

Start with [tasks.deploy] in cdk/mise.toml around line 80, .github/workflows/deploy.yml at line 262, and cdk/src/main.ts around line 68. Compare the deploy paths and the existing check:transitive-pin-sync guard before deciding how to represent deploy-semantic dependencies. Done means the distinction is documented and deploy-semantic dependencies cannot silently diverge from the CI path, while clean:disk remains local-only.

Written by the indexing model from the issue text.

Assessment

Tech stack
aws, github-actions, typescript
Domain
ci-cd, devops, infrastructure
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.