fix: sync-preview pushes directly on clean merge, PRs only on conflict

[notgitika]

Summary

Reworks the sync-preview workflow to push directly to preview when the merge is clean (using the agentcore-devx-automation GitHub App to bypass branch protection), and only creates a PR when there are real conflicts.

How it works

1. Clean merge → merges main, restores preview's package version, pushes directly to preview. No PR.
2. Only version conflicts (package.json/package-lock.json) → accepts main's content, restores preview's version field, pushes directly. No PR.
3. Real conflicts in other files → opens a PR with conflict markers for manual resolution.

Key changes

• Uses actions/create-github-app-token with the agentcore-devx-automation app to get a token that bypasses branch protection
• Instead of ignoring package.json/lock entirely (which discards new deps, scripts, etc. from main), accepts main's full content and surgically restores only the version field
• CHANGELOG.md and schema merge normally from main — no special handling
• Dedup check prevents multiple conflict PRs

Test plan

• Workflow YAML is valid (verified locally)
• Push to main triggers sync-preview workflow
• Clean merge pushes directly to preview with version restored
• Version-only conflicts auto-resolve and push directly
• Real conflicts in other files produce a PR with conflict markers
• Existing open PR prevents duplicate creation
• App token has push access to preview branch

[agentcore-cli-automation]

Reviewed the workflow — a few things worth considering before merge:

1. PRs created by GITHUB_TOKEN won't trigger pull_request workflows

This is a documented GitHub limitation to prevent recursive workflow runs: "When you use the repository's GITHUB_TOKEN to perform tasks, events triggered by the GITHUB_TOKEN will not create a new workflow run."

That means the sync PRs created here will not run build-and-test.yml or lint.yml (both of which trigger on pull_request without branch filters). Looking at the current preview branch ruleset, no status checks are required for merge, so this won't strictly block merging — but reviewers approving these PRs won't see CI signal, which somewhat defeats the purpose of going through a PR.

Options:

• Use a PAT (or a GitHub App token via actions/create-github-app-token) stored as a secret in place of ${{ github.token }} for the gh pr create calls, so workflows fire.
• Accept the trade-off and document that sync PRs intentionally bypass CI (in which case the PR body should probably call that out).
• Add a workflow_dispatch/manual re-run step or trigger checks explicitly.

2. Rapid pushes to main while a sync PR is open will pile up silently

With the new logic, if commit A is pushed → sync PR opened → commit B is pushed before the sync PR is merged, the second run sees count != 0 and skips entirely. B only gets synced whenever the next push to main happens after the existing PR merges. In the old flow, clean merges pushed directly, so every main push was reflected immediately.

This is probably acceptable (it eventually catches up), but if sync PRs sit open for a while it could surprise people. Options:

• Leave as-is and rely on "the next push will catch up" (worth a comment in the workflow).
• Force-push the new merge onto the existing sync branch so the open PR stays current.

3. Orphan sync-preview/merge-main-* branches

Each run creates a fresh timestamped branch and nothing deletes them after the PR merges/closes. Over time these will accumulate. GitHub's "Automatically delete head branches" repo setting handles this cleanly if it's on; otherwise consider adding gh pr merge --delete-branch guidance or a cleanup step.

Issue #1 is the one I'd most want resolved (or at least explicitly decided on) before merging.

[github-actions]

Coverage Report

Status	Category	Percentage	Covered / Total
🔵	Lines	43.33%	9083 / 20958
🔵	Statements	42.61%	9646 / 22636
🔵	Functions	40.11%	1569 / 3911
🔵	Branches	40.14%	5862 / 14601

Generated in workflow #2840 for commit 7e9f6a1 by the Vitest Coverage Report Action

[notgitika]

1/ is a real issue. unfortunately we need a PAT token or github app token to resolve that
2/ acceptable trade-off imo
3/ Automatically delete head branches is enabled in settings so this is not an issue

[github-actions]

Package Tarball

aws-agentcore-0.13.1.tgz

How to install

npm install https://github.com/aws/agentcore-cli/releases/download/pr-1078-tarball/aws-agentcore-0.13.1.tgz

[Hweinstock]

sorry if I forgot the answer here, but why we do need to special case package.json/package-lock.json? Does preview have new dependencies we want to manage separately?

[notgitika]

the reason is that the package version itself is different in main and preview
example:
main: 0.13.1
preview: 1.0.0-preview.5

Everything else should ideally be identical

[notgitika]

added inline comment

[agentcore-cli-automation]

Nice iteration — the GitHub App token addresses the main concern from the prior review and the version-restore logic is much cleaner than just ignoring package.json wholesale. One blocking issue with the dedup search, plus a couple of smaller robustness nits. See inline comments.

[Hweinstock]

LGTM once CI passes.