[rismehta]

Description

Add release-triggered synchronization from master to release/650:

• Run for published, non-prerelease releases whose target is master; verify the release tag belongs to master. Also support manual dispatch from master.
• Capture the latest master tip at run time, including post-tag commits, and create the sync branch from release/650. Merge using git merge --no-ff -X ours: release/650 wins conflicting hunks, while non-conflicting master changes remain.
• Stop and abort without pushing for unresolved conflict types, including modify/delete conflicts. No automatic PR merge.
• Serialize sync runs, avoid duplicate PRs for the same master SHA, and recover an already-pushed branch if PR creation fails without force-pushing or overwriting unrelated changes.
• Preserve the repository PR template and require CI/reviewer validation. Regression test cases and the PR-only validation job were removed at the requester's direction; only the sync workflow and its helper script remain.

Authentication: repository secret RELEASE_SYNC_TOKEN is now present (confirmed through secret metadata). It requires Contents, Pull requests, and Workflows write access (or classic PAT public_repo and workflow scopes for this public repository). The secret's value and permissions cannot be read back; they still require live workflow validation. No credential is included in this PR. Checkout and gh both use this token so workflow-file changes can be pushed and downstream PR checks can trigger. Missing credentials fail explicitly before checkout.

The release/manual triggers become available only after this workflow is merged into master. No live release or dispatch has been triggered as part of this change.

Related Issue

Companion to manual release synchronization #2019, requested after release core-forms-components-reactor-3.0.176. No separate tracking issue supplied.

Motivation and Context

Remove the recurring manual effort of preparing a master-to-release/650 PR after master releases, while protecting release/650-specific conflicting content and retaining human review. Using release/650 as the checked-out merge base is essential: ours must refer to release/650, not master.

How Has This Been Tested?

Validated the current revision on macOS:

• bash -n .github/scripts/sync-master-to-release-650.sh: passed.
• /Users/rismehta/.copilot/session-state/08b75ca8-f1e2-4e83-ad66-c74c4f59e58d/files/bin/shellcheck-v0.11.0/shellcheck .github/scripts/sync-master-to-release-650.sh: passed (ShellCheck 0.11.0, installed only in the session directory).
• /Users/rismehta/.copilot/session-state/08b75ca8-f1e2-4e83-ad66-c74c4f59e58d/files/bin/actionlint -shellcheck=/Users/rismehta/.copilot/session-state/08b75ca8-f1e2-4e83-ad66-c74c4f59e58d/files/bin/shellcheck-v0.11.0/shellcheck .github/workflows/sync-master-to-release-650.yml: passed (actionlint 1.7.7).
• git diff --cached --check: passed before committing.

No application code was changed. Maven/AEM/Cypress tests were not run locally for this automation-only change. The earlier seven-case test suite and its PR job were removed as explicitly requested, so their previous passing result is not presented as current-revision CI evidence. The no-mistakes gate could not run because its CLI is not installed; direct shell and workflow checks above passed. End-to-end GitHub release/dispatch execution is not yet verified: the secret exists, but this workflow is not yet on master.

Manual acceptance check after review:

1. Merge Sync master to release/650 after 3.0.176 (release/650 wins conflicts) #2019 into release/650 using Create a merge commit to preserve master ancestry and the approved conflict resolution. Otherwise the known modify/delete conflict on the obsolete sync-pr.yml can stop the first run, as designed.
2. Merge this PR into master. GitHub requires the workflow on the default branch before manual dispatch; this workflow also permits dispatch only from master.
3. Open Actions, select Sync master to release/650 after a release, choose Run workflow, select master, and run it. This is a real write-enabled run: it can push a branch and create a PR, but never merges release/650.
4. Verify the credential check and merge steps pass, the resulting PR targets release/650, and its merge commit has release/650 as first parent and the captured master SHA as second parent. Review that conflicting hunks retain release/650 and non-conflicting master changes remain.
5. Run it again without changing master. It should report the existing PR instead of creating another. Merge synchronization PRs with a merge commit, not squash/rebase, to preserve the ancestry used for subsequent syncs.

Screenshots (if appropriate):

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

• I have signed the Adobe Open Source CLA.
• My change requires a change to the documentation.
• I have updated the documentation accordingly.
• I have read the CONTRIBUTING document.
• I have added tests to cover my changes and the overall coverage did not decrease.
• All unit tests pass on CircleCi.
• I ran all tests locally and they pass.

[adobe-bot]

Accessibility Violations Found

Id	Impact
aria-required-attr	critical
empty-heading	minor
label-title-only	serious
target-size	serious

[adobe-bot]

Accessibility Violations Found

Id	Impact
aria-required-attr	critical
empty-heading	minor
label-title-only	serious
target-size	serious

[adobe-bot]

Accessibility Violations Found

Id	Impact
aria-required-attr	critical
empty-heading	minor
label-title-only	serious
target-size	serious

[adobe-bot]

Accessibility Violations Found

Id	Impact
aria-required-attr	critical
empty-heading	minor
label-title-only	serious
target-size	serious