fix: sync-preview workflow always creates PR instead of direct push

[notgitika]

Summary

Branch protection on preview prevents direct pushes from the GitHub Actions bot. Changed the sync-preview workflow to always create a PR instead of pushing directly.

Changes

1. Always creates a PR — never pushes directly to preview
2. Auto-resolves preview-only files by keeping preview's version:
   • package.json (version number)
   • package-lock.json
   • CHANGELOG.md
   • schemas/agentcore.schema.v1.json
3. If those were the only conflicts, the PR is clean (auto-mergeable). If other files conflict, the PR has markers for manual resolution.

Before

• Clean merge → push directly to preview (blocked by branch protection)
• Conflict → create PR with conflict markers

After

• Clean merge → create PR (auto-mergeable, one-click)
• Conflict in preview-only files → auto-resolved, clean PR
• Conflict in other files → create PR with conflict markers for manual resolution

Both paths skip if there's already an open sync PR.

Test plan

• Workflow YAML is valid
• Push to main triggers sync-preview workflow
• Clean merge creates a PR against preview
• Conflicts in preview-only files are auto-resolved
• Existing open PR prevents duplicate

[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	42.89%	8936 / 20830
🔵	Statements	42.17%	9485 / 22491
🔵	Functions	39.66%	1537 / 3875
🔵	Branches	39.82%	5769 / 14486

Generated in workflow #2272 for commit a36a123 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