CI: Add backporting bot (#4795)

Adds a bot that automatically opens MRs into the `stable2407` branch
when the `A4-needs-backport` label is applied to a merged MR.

TODO:
- [x] ~~Settle on label vs error message trade-off~~ (resolved)

docs:

# Backporting

This document explains how to backport a merged PR from `master` to one
of the `stable*` branches. Backports should only be used to fix bugs or
security issues - never to introduce new features.

## Steps

1. Fix a bug through a PR that targets `master`.
2. Add label `A4-needs-backport` to the PR.
4. Merge the PR into `master`.
5. Wait for the bot to open the backport PR.
6. Ensure the change is audited or does not need audit.
7. Merge the backport PR. 

The label can also be added after the PR is merged.

## Example

For example here where the dev triggered the process by adding the label
after merging:


![backport-ex2](https://github.com/user-attachments/assets/c7b686db-a0fe-41f1-9d6f-959a5a7097b1)

---------

Signed-off-by: Oliver Tale-Yazdi <[email protected]>

.github/workflows/check-semver.yml

@@ -45,7 +45,7 @@ jobs:
             as to not impact downstream teams that rely on the stability of it. Some things to consider:
             - Backports are only for 'patch' or 'minor' changes. No 'major' or other breaking change.
             - Should be a legit *fix* for some  bug, not adding tons of new features.
-            - Must either be already audited or trivial (not sure audit).
+            - Must either be already audited or not need an audit.
 
             <details><summary><i>Emergency Bypass</i></summary>
             <p>

.github/workflows/command-backport.yml

@@ -0,0 +1,62 @@
+name: Backport into stable
+
+on:
+  # This trigger can be problematic, see: https://securitylab.github.com/resources/github-actions-preventing-pwn-requests/
+  # In our case it is fine since we only run it on merged Pull Requests and do not execute any of the repo code itself.
+  pull_request_target:
+    types: [ closed, labeled ]
+
+permissions:
+  contents: write # so it can comment
+  pull-requests: write # so it can create pull requests
+
+jobs:
+  backport:
+    name: Backport pull request
+    runs-on: ubuntu-latest
+
+    # The 'github.event.pull_request.merged' ensures that it got into master:
+    if: >
+      ( !startsWith(github.event.pull_request.base.ref, 'stable') ) &&
+      (
+        github.event_name == 'pull_request_target' &&
+        github.event.pull_request.merged &&
+        github.event.pull_request.base.ref == 'master' &&
+        contains(github.event.pull_request.labels.*.name, 'A4-needs-backport')
+      )
+    steps:
+      - uses: actions/checkout@v4
+
+      - name: Create backport pull requests
+        uses: korthout/backport-action@v3
+        id: backport
+        with:
+          target_branches: stable2407
+          merge_commits: skip
+          github_token: ${{ secrets.GITHUB_TOKEN }}
+          pull_description: |
+            Backport #${pull_number} into `${target_branch}` (cc @${pull_author}).
+
+            <!--
+              # To be used by other automation, do not modify:
+              original-pr-number: #${pull_number}
+            -->
+          pull_title: |
+            [${target_branch}] Backport #${pull_number}
+
+      - name: Label Backports
+        if: ${{ steps.backport.outputs.created_pull_numbers != '' }}
+        uses: actions/github-script@v7
+        with:
+          script: |
+            const pullNumbers = '${{ steps.backport.outputs.created_pull_numbers }}'.split(' ');
+            
+            for (const pullNumber of pullNumbers) {
+              await github.rest.issues.addLabels({
+                issue_number: parseInt(pullNumber),
+                owner: context.repo.owner,
+                repo: context.repo.repo,
+                labels: ['A3-backport']
+              });
+              console.log(`Added A3-backport label to PR #${pullNumber}`);
+            }

docs/BACKPORT.md

@@ -0,0 +1,21 @@
+# Backporting
+
+This document explains how to backport a merged PR from `master` to one of the `stable*` branches.
+Backports should only be used to fix bugs or security issues - never to introduce new features.
+
+## Steps
+
+1. Fix a bug through a PR that targets `master`.
+2. Add label `A4-needs-backport` to the PR.
+3. Merge the PR into `master`.
+4. Wait for the bot to open the backport PR.
+5. Ensure the change is audited or does not need audit.
+6. Merge the backport PR.
+
+The label can also be added after the PR is merged.
+
+## Example
+
+For example here where the dev triggered the process by adding the label after merging:
+
+![backport](./images/backport-ex2.png)

docs/RELEASE.md

@@ -55,9 +55,10 @@ The Westend testnet will be updated to a new runtime every two weeks with the la
 
 **From `master` to `stable`**
 
-Backports in this direction can be anything that is audited and either a `minor` or a `patch` bump. [Security
-fixes](#bug-and-security-fix) should be prioritized over additions or improvements. Crates that are declared as internal
-API can also have `major` version bumps through backports.
+Backports in this direction can be anything that is audited and either a `minor` or a `patch` bump.
+See [BACKPORT.md](./BACKPORT.md) for more explanation. [Security fixes](#bug-and-security-fix)
+should be prioritized over additions or improvements. Crates that are declared as internal API can
+also have `major` version bumps through backports.
 
 **From `stable` to `master`**
 
@@ -164,5 +165,6 @@ Describes how developers should merge bug and security fixes.
 2. The Pull Request is marked as priority fix.
 3. Audit happens with priority.
 4. It is merged into `master`.
-5. It is automatically back-ported to `stable`.
-6. The fix will be released in the next *Stable* release. In urgent cases, a release can happen earlier.
+5. Dev adds the `A4-needs-backport` label.
+6. It is automatically back-ported to `stable`.
+7. The fix will be released in the next *Stable* release. In urgent cases, a release can happen earlier.