Refactor backmerge-release.yml to allow specifying source and target branches

[tmat]

Useful for keeping feature branches up-to-date.

Now that the workflow is more general should we rename to something like flow?

[github-actions]

🚀 Dogfood this PR with:

⚠️ WARNING: Do not do this without first carefully reviewing the code of this PR to satisfy yourself it is safe.

curl -fsSL https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.sh | bash -s -- 15233

Or

• Run remotely in PowerShell:

iex "& { $(irm https://raw.githubusercontent.com/dotnet/aspire/main/eng/scripts/get-aspire-cli-pr.ps1) } 15233"

[tmat]

@eerhardt ptal

[Copilot]

Pull request overview

This PR generalizes the existing backmerge workflow so it can be manually triggered to merge an arbitrary source branch into an arbitrary target branch, rather than being hardcoded to release/13.2 -> main.

Changes:

• Added workflow_dispatch inputs for source and target branches (with defaults).
• Parameterized git fetch/merge logic and PR creation to use the provided branches.
• Updated conflict-issue creation messaging to include the selected source/target branches.

Comments suppressed due to low confidence (1)

.github/workflows/backmerge-release.yml:152

• The issue-deduping logic now becomes incorrect: it updates the first open backmerge-conflict issue regardless of which source/target pair is failing. With multiple branch pairs, conflicts will get conflated. Consider searching/filtering by source+target (e.g., in title/body) and only updating an issue that matches the current ${sourceBranch}/${targetBranch} pair; otherwise create a new one.

            // Check if there's already an open issue for this
            const existingIssues = await github.rest.issues.listForRepo({
              owner: context.repo.owner,
              repo: context.repo.repo,
              state: 'open',
              labels: 'backmerge-conflict',
              creator: 'github-actions[bot]'
            });