fix(deploy): pin vended aws-cdk-lib and enforce cloud-assembly schema compat#1759
Open
jesseturner21 wants to merge 2 commits into
Open
fix(deploy): pin vended aws-cdk-lib and enforce cloud-assembly schema compat#1759jesseturner21 wants to merge 2 commits into
jesseturner21 wants to merge 2 commits into
Conversation
… compat The vended CDK template declared aws-cdk-lib with a caret range, so fresh projects resolve whatever npm serves. When upstream aws-cdk-lib bumps its cloud-assembly schema major, new projects write manifests the CLI's bundled readers (@aws-cdk/toolkit-lib, @aws-cdk/cdk-assets-lib) cannot parse, and agentcore deploy fails with AssemblyVersionMismatch. Pin the template's aws-cdk-lib to an exact version (2.261.0, schema v54) and keep it in lockstep with the CLI's readers: - src/assets/cdk/package.json: aws-cdk-lib ^2.248.0 -> 2.261.0 (exact) - package.json: exact-pin the aws-cdk-lib devDependency as the lockstep anchor; regenerate npm-shrinkwrap.json - New unit test (cdk-schema-compat.test.ts) asserts the template pin, root devDep, and installed copy match, and that each bundled reader supports a schema major >= what the pinned aws-cdk-lib writes - New scripts/sync-template-cdk.mjs re-syncs the pins and snapshots in one command; the test's failure messages point to it - dependabot.yml comment + docs/testing/unit-tests.md section describing the workflow for aws-cdk group bumps Verified: full unit suite green; fresh agentcore create vends the exact pin and resolves cloud-assembly-schema 54.x; negative tests (drifted pin, simulated schema-55 writer) fail with actionable messages.
jesseturner21
had a problem deploying
to
e2e-testing
GitHub Actions
Error
github-actions
Bot
added
agentcore-harness-reviewing
agentcore-devx-automation
Bot
added
the
claude-security-reviewing
Contributor
Package TarballHow to installgh release download pr-1759-tarball --repo aws/agentcore-cli --pattern "*.tgz" --dir /tmp/pr-tarball
npm install -g /tmp/pr-tarball/aws-agentcore-0.24.1.tgz |
Contributor
|
Claude Security Review: no high-confidence findings. (run) |
agentcore-devx-automation
Bot
removed
the
claude-security-reviewing
jesseturner21
temporarily deployed
to
e2e-testing
GitHub Actions
Inactive
agentcore-devx-automation
Bot
added
the
claude-security-reviewing
Contributor
|
Claude Security Review: no high-confidence findings. (run) |
agentcore-devx-automation
Bot
removed
the
claude-security-reviewing
Contributor
Coverage Report
|
Hweinstock
reviewed
Jul 14, 2026
| "dependencies": { | ||
| "@aws/agentcore-cdk": "^0.1.0-alpha.19", | ||
| "aws-cdk-lib": "^2.248.0", | ||
| "aws-cdk-lib": "2.261.0", |
Contributor
There was a problem hiding this comment.
if a customer creates a project with this version, is it their responsibility for updating it going forward? What happens if aws-cdk-lib releases new features we depend on for a new feature, but the customers existing project is on an older version?
| * If any test here fails after a dependency bump, run: | ||
| * | ||
| * node scripts/sync-template-cdk.mjs | ||
| */ |
Contributor
There was a problem hiding this comment.
it looks like we have similar comments in the dependabot.yml, the script to update, the readme, and the test here. Does it make sense to establish a source of truth and link to it?
| return Number(match[1]); | ||
| } | ||
|
|
||
| describe('vended CDK template / bundled cloud-assembly reader compatibility', () => { |
Contributor
There was a problem hiding this comment.
Is there a way to test this at a higher level? This feels highly specific to the implementation rather than the behavior.
| "@aws/agentcore-cdk": "^0.1.0-alpha.19", | ||
| "aws-cdk-lib": "^2.248.0", | ||
| "aws-cdk-lib": "2.261.0", | ||
| "constructs": "^10.0.0" |
Contributor
There was a problem hiding this comment.
should we pin other dependencies as well? Even though we own the cdk package, we don't currently have backwards-compat testing gating release, and wondering if there's a risk we break existing projects.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
The vended CDK template declared
aws-cdk-libwith a caret range (^2.248.0), so freshly created projects resolve whatever version npm serves. When upstreamaws-cdk-libbumps its cloud-assembly schema major (as 2.258.0 did with schema v54), new projects write manifests that the CLI's bundled readers (@aws-cdk/toolkit-lib,@aws-cdk/cdk-assets-lib) cannot parse, andagentcore deployfails withAssemblyVersionMismatch. Readers accept older schemas but hard-fail on newer ones, so an unpinned template can always drift into this breakage between CLI releases.This PR pins the template and makes the writer/reader coupling impossible to break silently:
src/assets/cdk/package.jsonnow exact-pinsaws-cdk-libto2.261.0(writes schema v54, matching the bundled readers). The rootaws-cdk-libdevDependency is exact-pinned to the same version as a lockstep anchor;npm-shrinkwrap.jsonregenerated.src/assets/__tests__/cdk-schema-compat.test.tsasserts (1) the template pin is exact, (2) template pin === root devDep === installed copy, and (3) each bundled reader's max supported schema major >= the schema major the pinnedaws-cdk-libwrites. Any one-sided bump fails CI with an actionable message.scripts/sync-template-cdk.mjsre-syncs the root devDep, template pin, and asset snapshots in one command. On Dependabotaws-cdkgroup PRs:npm ci && node scripts/sync-template-cdk.mjs. Documented indocs/testing/unit-tests.md, with a pointer comment independabot.yml.Existing projects (already scaffolded with the caret) are unaffected by this change; newly created projects get the exact pin.
Related Issue
Closes #
Documentation PR
N/A — docs updated in-repo (
docs/testing/unit-tests.md).Type of Change
Testing
How have you tested the change?
npm run test:unitandnpm run test:integnpm run typechecknpm run lintsrc/assets/, I rannpm run test:update-snapshotsand committed the updated snapshotsAdditional verification:
agentcore create: the generated project vends"aws-cdk-lib": "2.261.0"and its install resolves@aws-cdk/cloud-assembly-schema@54.11.0(major 54, readable by both bundled readers).Checklist
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.