[nborges-aws]

Description

Update v0 release workflow to match v1. The changes include the following:

• split release workflow from single workflow to release-prepare and release-publish, matching v1 implementation
• Add logic to automatically run release-publish on release PR merge
• Use codebuild runners for release (where possible, final publish step requires github runner -> ubuntu-latest)
• Remove operator option for CDK version
• CDK version now targets @alpha CDK dist tag instead of @latest. This ensures v0.x CLI stays pinned to v0.x CDK
• remove unused release.yml workflow

Operator no longer needs to use two separate release workflows. Both major versions now live under one workflow. The operator points to correct major version to release via branch selection.

Type of Change

• Bug fix
• New feature
• Breaking change
• Documentation update
• Other (please describe):

Testing

How have you tested the change?

• I ran bun test
• I ran the relevant end-to-end tests with bun run test:e2e, or explained why they are not applicable
• I ran bun run typecheck
• I ran bun run lint:check
• I ran bun run format:check
• I ran bun run build
• If I modified src/assets/, I updated affected snapshots with bun test <test-file> --update-snapshots and committed them

Checklist

• I have read the CONTRIBUTING document
• I have added any necessary tests that prove my fix is effective or my feature works
• I have updated the documentation accordingly
• I have added an appropriate example to the documentation to outline the feature, or no new docs are needed
• My changes generate no new warnings
• Any dependent changes have been merged and published

---

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the
terms of your choice.

[github-actions]

Package Tarball

aws-agentcore-0.31.1.tgz

How to install

gh release download pr-2710-tarball --repo aws/agentcore-cli --pattern "*.tgz" --dir /tmp/pr-tarball
npm install -g /tmp/pr-tarball/aws-agentcore-0.31.1.tgz

[agentcore-devx-automation]

Claude Security Review: no high-confidence findings. (run)

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	41.75%	16052 / 38446
🔵	Statements	41%	17125 / 41767
🔵	Functions	35.72%	2764 / 7736
🔵	Branches	34.78%	10738 / 30871

Generated in workflow #4594 for commit bc29248 by the Vitest Coverage Report Action

[agentcore-devx-automation]

AgentCore Harness Review

Verdict: Changes requested

Nice cleanup overall — splitting prepare/publish, keeping the filename release-main-and-preview.yml and the npm-publish environment (required by the npm trusted-publisher registration), the "already on npm → skip" rerun guard, and the verify gate before publish all look right for v0 parity with the refactor branch. Three things need attention before merging.

1. @aws/agentcore-cdk@alpha does not exist — every release-prepare run will fail

.github/workflows/release-prepare.yml L55-62:

if ! CDK_VERSION=$(npm view '@aws/agentcore-cdk@alpha' version); then

The registry currently has only these dist-tags for that package:

$ curl -s https://registry.npmjs.org/-/package/@aws%2Fagentcore-cdk/dist-tags
{"latest":"1.0.0","rc":"1.0.0-rc.4"}

npm view '@aws/agentcore-cdk@alpha' version returns version not found: alpha and exits non-zero, so the step hard-fails with "Publish a v0 CDK version under @aws/agentcore-cdk@alpha before preparing this release" and no v0 release can be prepared.

The likely source of confusion: the v0 CDK versions are named 0.1.0-alpha.N (the repo currently pins 0.1.0-alpha.54), but agentcore-l3-cdk-constructs's v0 release workflow publishes them under the preview dist-tag (dist_tag=preview for non-main branches), never alpha — and preview is no longer present on the package either. A dist-tag only exists if some npm publish --tag/npm dist-tag add created it.

Options:

1. Create and maintain the tag out-of-band first (npm dist-tag add @aws/agentcore-cdk@0.1.0-alpha.54 alpha) and get the CDK repo publishing v0 under alpha; then this PR works as written. Worth stating that dependency in the PR body since it's a cross-repo prerequisite.
2. Don't depend on a dist-tag at all — resolve the newest 0.x directly, e.g.
   CDK_VERSION=$(npm view @aws/agentcore-cdk versions --json | jq -r '[.[] | select(startswith("0."))] | last').
   Note npm view '@aws/agentcore-cdk@<1.0.0' version won't work here because node-semver excludes prerelease versions like 0.1.0-alpha.54 from a range with no prerelease comparator.
3. Point at whatever tag the CDK repo actually publishes for the v0 stream (preview), once it is re-established.

2. The legacy .github/workflows/release.yml is still live and now double-triggers publish

release.yml on main is a second, fully functional v0 release workflow: it bumps the version, pushes release/v$VERSION, and opens a PR against main/v0.x using the same GitHub App token (vars.APP_ID), then has its own approval-gated publish/tag/GitHub-release jobs.

With the new push: [main, v0.x] trigger plus the check-release detector (which matches any merged release/v* PR authored by user id 282717993 whose merge_commit_sha is the pushed SHA), merging a PR created by the old workflow will now also kick off release-publish. The result is two publish paths racing on the same version: one succeeds, the other fails on "version already exists" / "tag already exists", possibly after a human approved the stale gate. The PR description says operators no longer need two workflows, so please finish the job — delete release.yml from main, or reduce it to a refusal stub like the one refactor carries. (If it's deleted, refactor's release.yml placeholder becomes dead and can be removed in a follow-up.)

3. Release notes will be generated against a v1 tag

.github/workflows/release-main-and-preview.yml L148-149:

gh release create "v$VERSION" --target "$REF" --title "v$VERSION" \
  --generate-notes --latest=false "aws-agentcore-$VERSION.tgz"

v1.0.0 is currently the repo's "latest" release and v1 preview/rc tags live in the same repo, so letting GitHub auto-pick the baseline will very likely produce notes computed against a v1 tag rather than the previous v0 release. The refactor workflow deliberately avoids this by computing a --notes-start-tag restricted to its own tag series. Please do the same here, filtering to ^v0\.[0-9]+\.[0-9]+$ (e.g. with git tag -l 'v0.*' | grep -E ... | xargs npx semver --range "<$VERSION" | tail -1), which also means the verify job's checkout (already fetch-depth: 0) can supply the tag list.

Minor (non-blocking)

• check-release (L11) runs on a CodeBuild runner for every push to main, just to make one gh api call. The refactor version uses ubuntu-latest for exactly this reason; spinning up a CodeBuild build per merge is pure overhead.
• The refactor version guards check-release with if: "!github.event.deleted". Dropping it means a future v0.x branch deletion produces a push event whose SHA is all-zeros, gh api .../commits/000.../pulls 404s, and set -euo pipefail turns it into a red run.
• The magic .user.id == 282717993 lost its explanatory comment (# Stable account ID for agentcore-devx-automation[bot].) in the port. Worth keeping — it's unreadable otherwise.
• The dispatch recovery path is stricter than v1's: it requires the selected branch's tip to be the release merge commit, so recovery becomes impossible as soon as another PR lands on main. If that's intentional, fine; if the intent was "republish a release whose merge push never ran," consider allowing a ref/version input.

[agentcore-devx-automation]

Claude Security Review: no high-confidence findings. (run)