Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
#843 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

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

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.

Description

ci-cd enhancement infra-cdk v1
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.

Dominant language
TypeScript
Stars
158
Forks
49
Avg merge
3d 7h
Merged PRs (30d)
17

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

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

All issues in aws-samples/sample-autonomous-cloud-coding-agents

Similar issues

More TypeScript issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.