feat: add config-bundle CLI commands - #1945
Conversation
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## refactor #1945 +/- ##
============================================
+ Coverage 95.74% 95.80% +0.05%
============================================
Files 291 300 +9
Lines 16234 16547 +313
============================================
+ Hits 15544 15853 +309
- Misses 690 694 +4 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
| options: CoreOptions, | ||
| ): Promise<UpdateConfigurationBundleResponse> { | ||
| const control = this.clients.control(toClientConfig(options)); | ||
| const current = await control.send(new GetConfigurationBundleCommand({ bundleId: id })); |
There was a problem hiding this comment.
I may be missing the intended branch behavior, but can we select the branch explicitly before choosing the parent version? I live-tested a mainline v1 followed by a review-branch v2. GetConfigurationBundle without branchName returned v2, and this CLI update then created v3 on review-branch. Passing branchName: "mainline" correctly returned v1. Would it make sense to expose --branch-name, default it to mainline, and pass it to both Get and Update so an ordinary update cannot silently continue whichever branch was modified most recently?
| export type CreateConfigurationBundleInput = Pick< | ||
| CreateConfigurationBundleRequest, | ||
| "bundleName" | "components" | "kmsKeyArn" | ||
| >; |
There was a problem hiding this comment.
Are these field exclusions intentional? The live service accepted description, branchName, commitMessage, createdBy, and tags during create, and accepted description plus branchName during update when the required components, commit message, and parent were supplied. The SDK also models bundleName and explicit parentVersionIds. Would it make sense to expose the common scalar fields and typed JSON for the structured ones? Also definitely get if you have reasoning behind why these are not included.
Description
Adds imperative CRUDL and version listing commands for AgentCore evaluation configuration bundles:
eval config-bundle createeval config-bundle geteval config-bundle listeval config-bundle updateeval config-bundle deleteeval config-bundle version listSummary of changes
--componentsaccepts inline JSON,file://<path>, or stdin (-) viaSourceResolver.parseJsonFlagWithSchemautility.getcalls the latest-bundle API by default and the version API when optional--versionis provided.listreturns configuration bundles, whileversion listreturns all versions belonging to one bundle.updaterequires--id,--components, and--commit-message;--kms-key-arnremains optional. This counteracts the service API docs and smithy models, but is the confirmed validation structure in the service itselfparentVersionIdsentry, as required by service lineage validation.Type of Change
Testing
How have you tested the change?
Manually smoke tested all commands against a configuration bundle in my personal account:
bun run test(993 pass, 0 fail)I ran
npm run test:unitandnpm run test:integI ran
npm run typecheckI ran
npm run lintIf I modified
src/assets/, I rannpm run test:update-snapshotsand committed the updated snapshotsChecklist
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.