fix(project): deploy credentials through CloudFormation, and stop deleting stacks - #2089
Draft
notgitika wants to merge 3 commits into
Draft
fix(project): deploy credentials through CloudFormation, and stop deleting stacks#2089notgitika wants to merge 3 commits into
notgitika wants to merge 3 commits into
Conversation
notgitika
had a problem deploying
to
e2e-testing
August 24, 2026 18:35 — with
GitHub Actions
Failure
Base automatically changed from
feat/project-deploy-implementation
to
refactor
August 24, 2026 19:39
notgitika
force-pushed
the
feat/project-deploy-credentials
branch
from
August 24, 2026 19:50
a1b6cbf to
c255cdd
Compare
notgitika
marked this pull request as draft
August 24, 2026 19:50
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## refactor #2089 +/- ##
============================================
- Coverage 97.36% 97.25% -0.12%
============================================
Files 410 411 +1
Lines 24796 25026 +230
============================================
+ Hits 24142 24338 +196
- Misses 654 688 +34 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
Two review findings from #2058, both cases of deploy trusting something it had not checked. A synthesized template with no resources makes the CDK Toolkit *delete* an existing stack of that name and return as though it deployed. #2058 caught that after the fact, by which point the stack was already gone. Check the resource count before handing the assembly to the Toolkit instead. Stack selection matched on the target-name tag alone, never on the account and region the artifact was synthesized for. Those derive from the same target today and so cannot disagree, but nothing enforced it, and the Toolkit deploys where the artifact's environment points rather than where the tag says. Both fields were also being stripped on read, since the manifest schema declared neither. stackArtifactIdForTarget becomes stackArtifactForTarget, returning the template path alongside the id so the resource check needs no second read of the manifest.
Credentials declared in agentcore.json are not provisioned by `project deploy` on this branch: the synthesized app reads their provider ARNs out of .cli/deployed-state.json and tolerates the file's absence, and nothing writes it. Points at #2093 rather than working around it here. Credential providers are supported by CloudFormation, so the fix belongs in the synthesized stack, not in an imperative pre-synth step in the CLI.
notgitika
force-pushed
the
feat/project-deploy-credentials
branch
from
August 24, 2026 20:38
1a13ff1 to
dfb7780
Compare
`agentcore project deploy` created credential providers imperatively over the Identity API before synth, so the CLI owned resources CloudFormation did not know about and a rolled-back stack left them orphaned. The stack now declares them. Real secret material still never reaches the template: a credential carrying an external Secrets Manager reference deploys pointing at that secret, and one whose secret lives in `.env.local` is created with the L3's placeholder, which the CLI replaces over the Identity API once the deploy succeeds. - `assertCredentialsDeployable` runs before synth. A missing `.env.local` variable fails there, naming the variable and the file, rather than after a provider is already live holding a placeholder no later run would replace. - `createCredentialSynchronizer` runs after the deploy, because the providers do not exist until CloudFormation makes them. It updates every provider whose secret is inline on every deploy: the placeholder cannot be told apart from a real key by reading the provider back, since `ApiKey` is a write-only CloudFormation property and `GetApiKeyCredentialProvider` returns only the secret's ARN. - A `PaymentCredentialProvider` is refused up front. CloudFormation has no payment credential provider resource, and a payment provider needs vendor configuration `agentcore.json` has no fields for. - Payment connectors now carry the credential's *name*; the stack resolves it to the ARN of the provider it created. That drops the last reader of `deployed-state.json` from the vended CDK app. Both passes share one `resolveSecret`, so the preflight cannot disagree with the sync about which credentials need a secret pushed.
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
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.
Warning
This depends on changes on the
refactorbranch of the L3 CDK package.Summary
Hardens
agentcore project deployand moves credential-provider ownership into CloudFormation:.env.localuse a placeholder that the CLI replaces through the Identity API after a successful deploy.deployed-state.json.Testing
Added unit coverage for stack safety and environment validation, credential preflight and deploy ordering, inline and external secrets, API key and OAuth synchronization, and unsupported payment credentials.
Also verified against a real AWS account that secrets do not appear in
cdk.out, inline secrets are synchronized after deploy, external secrets remain untouched, and redeploying does not reset synchronized values.