From 0b203a6dcd48b6a49bb80c51bcb5774473da1eaa Mon Sep 17 00:00:00 2001
From: Runchao Han <me@runchao.rocks>
Date: Thu, 10 Oct 2024 10:10:18 +1100
Subject: [PATCH] chore: backport github action (#149)

Part of https://github.com/babylonlabs-io/babylon/issues/110

This PR introduces the backport Github action. One can label a hotfix PR
to `main` with `backport release/0.Y.x`, and this GH action will open a
backport PR automatically.
---
 .github/workflows/backport.yml | 38 ++++++++++++++++++++++++++++++++++
 RELEASE_PROCESS.md             | 24 +++++++++++----------
 2 files changed, 51 insertions(+), 11 deletions(-)
 create mode 100644 .github/workflows/backport.yml

diff --git a/.github/workflows/backport.yml b/.github/workflows/backport.yml
new file mode 100644
index 000000000..47c9985f6
--- /dev/null
+++ b/.github/workflows/backport.yml
@@ -0,0 +1,38 @@
+# Adapted from https://github.com/marketplace/actions/backporting
+#
+# Usage: 
+#   - Let's say you want to backport a pull request on a branch named `production`.
+#   - Then label it with `backport production`.
+#   - That's it! When the pull request gets merged, it will be backported to 
+#     the `production` branch. If the pull request cannot be backported, a comment 
+#     explaining why will automatically be posted.
+#
+# Note: multiple backport labels can be added. For example, if a pull request 
+#       has the labels `backport staging` and `backport production` it will be 
+#       backported to both branches: `staging` and `production`.
+name: Backport
+on:
+  pull_request_target:
+    types:
+      - closed
+      - labeled
+
+jobs:
+  backport:
+    name: Backport
+    runs-on: ubuntu-latest
+    # Only react to merged PRs for security reasons.
+    # See https://docs.github.com/en/actions/using-workflows/events-that-trigger-workflows#pull_request_target.
+    if: >
+      github.event.pull_request.merged
+      && (
+        github.event.action == 'closed'
+        || (
+          github.event.action == 'labeled'
+          && contains(github.event.label.name, 'backport')
+        )
+      )
+    steps:
+      - uses: tibdex/backport@v2
+        with:
+          github_token: ${{ secrets.GITHUB_TOKEN }}
\ No newline at end of file
diff --git a/RELEASE_PROCESS.md b/RELEASE_PROCESS.md
index eb58482c5..a1a846d09 100644
--- a/RELEASE_PROCESS.md
+++ b/RELEASE_PROCESS.md
@@ -1,12 +1,11 @@
 # Release Process
 
-- [Release Process](#release-process)
-  - [Breaking Changes](#breaking-changes)
-  - [Release Procedure](#release-procedure)
-    - [Creating a new release branch](#creating-a-new-release-branch)
-    - [Cutting a new release](#cutting-a-new-release)
-    - [Tagging Procedure](#tagging-procedure)
-  - [Patch release Procedure](#patch-release-procedure)
+- [Breaking Changes](#breaking-changes)
+- [Release Procedure](#release-procedure)
+  - [Creating a new release branch](#creating-a-new-release-branch)
+  - [Cutting a new release](#cutting-a-new-release)
+  - [Tagging Procedure](#tagging-procedure)
+- [Patch Release Procedure](#patch-release-procedure)
 
 This document outlines the release process for the Babylon node (babylond)
 
@@ -119,10 +118,13 @@ A _patch release_ is an increment of the patch number (eg: `v10.0.0` → `v10.0.
 circumstances .**_
 
 Updates to the release branch should come from `main` by backporting PRs
-(usually done by automatic cherry pick followed by a PRs to the release branch).
-The backports must be marked using `backport/Y` label in PR for main.
-It is the PR author's responsibility to fix merge conflicts and
-ensure CI passes.
+(usually done by automatic cherry pick followed by a PR to the release branch).
+The backports must be marked using `backport release/v0.Y.x` label in PR for
+`main`, where `release/v0.Y.x` is the name of the release branch. It is the PR
+author's responsibility to fix merge conflicts, update changelog entries, and
+ensure CI passes. If a PR originates from an external contributor, a member of
+the stewarding team assumes responsibility to perform this process instead of
+the original author.
 
 After the release branch has all commits required for the next patch release:
 * Create a new annotated git tag in the release