Automate release → develop sync via a "Sync release PR to develop" GitHub Action

[anushasunkada]

Problem

In esignet's branching model, hotfixes and changes often land first on a release** branch and then need to be manually reflected back into one or more develop branches (e.g. develop, develop-go). Today this back-merge is a manual step:

• A maintainer has to remember which develop branch(es) a given release fix applies to.
• They must manually cherry-pick or re-apply the commit(s) after the release PR is merged.
• This is error-prone (forgotten syncs cause develop to drift from release) and slow.

Proposed solution

Introduce a GitHub Actions workflow that triggers automatically whenever a PR into a release** branch is merged, and:

1. Inspects the labels on the merged PR to determine which develop branch(es) it should be synced into.
2. Cherry-picks the merge commit onto a new branch created from the target develop branch.
3. Opens a new PR from that branch into the target develop branch automatically, carrying over the same label.
4. If the cherry-pick fails (conflict), it does not fail silently — it posts a comment on the original release PR flagging that a manual sync is needed.

This keeps a human in the loop only when there's an actual conflict, and fully automates the happy path.

---

Solution Details

Reference: https://github.com/Infosys/esignet/blob/task/auto-pr-raise/.github/workflows/auto-pr-raise.yml
Reference Sync PR: thunder-id/thunderid#5138

Trigger

on:
  pull_request:
    types: [closed]
    branches:
      - "release**"

Runs on any PR closed against a branch matching release**, but the job itself is gated on github.event.pull_request.merged == true so closed-without-merge PRs are skipped.

Permissions

permissions:
  contents: write
  pull-requests: write

Needed to push the new sync branch and open/comment on PRs using the default GITHUB_TOKEN — no extra PAT or secret required.

Step-by-step flow

Step	Purpose
Checkout	Full history checkout (fetch-depth: 0) — required for cherry-pick to work.
Determine target develop branch from label	Reads the merged PR's labels and maps them to a target branch via a bash associative array (e.g. sync-to-develop → develop, sync-to-develop-go → develop-go). If no matching label is found, the rest of the job is skipped cleanly (no-op, not a failure).
Configure git	Sets a bot identity (github-actions[bot]) for the commits/branch it creates.
Create sync branch	Branches off the latest target develop branch as sync/pr-<number>-to-<develop_branch>.
Cherry-pick merged commit	Cherry-picks the release PR's merge commit (-m 1 to pick the mainline parent) onto the new branch. On failure, aborts cleanly and records success=false rather than leaving a broken cherry-pick state.
Push branch	Pushes the sync branch, only if the cherry-pick succeeded.
Create PR into target develop branch	Opens a PR titled sync: <original title> (#<PR number>), with a body linking back to the source PR, and re-applies the matched label — only runs on success.
Notify on conflict	If the cherry-pick failed, comments on the original release PR with a clear warning that manual syncing is required — only runs on failure.

Key design choices worth highlighting

• Label-driven, not branch-name-driven: the mapping table decouples "which release branch" from "which develop branch(es) to sync into," and supports fanning a single release PR out to multiple develop lines by adding more labels/entries.
• Fails safe, not silent: a conflicting cherry-pick doesn't get force-pushed or lost — it degrades to a comment asking a human to intervene, on the exact PR where the change originated.
• No new secrets: uses the default GITHUB_TOKEN, so there's no extra secret-management burden for adopting repos.
• Opt-in per PR: nothing happens unless the merged PR is explicitly labeled, so it can be rolled out gradually without surprising existing workflows.

What would need to be adapted for esignet's develop/develop-go setup

• Confirm the release** branch glob actually matches esignet's real release-branch naming convention.
• Populate the LABEL_TO_BRANCH map with esignet's actual labels/branches (at minimum develop and develop-go; extend if there are more lines).
• Ensure sync-to-develop / sync-to-develop-go (or renamed equivalents) exist as repo labels, and decide whether they should be added manually per-PR or auto-applied based on some other signal (e.g. changed files/paths).
• Decide branch-protection implications: does the auto-created sync PR need a required review before merge, or can trusted paths auto-merge?