feat: add automated backport workflow #14738
Conversation
Add GitHub Actions workflow for automatic PR backporting with intelligent branch detection, conflict handling, and comprehensive error reporting. Supports multiple branch naming patterns and provides detailed feedback via comments.
github-project-automation
bot
moved this to Open
in OpenSearch Lucene & Core Performance Tracking
|
This PR does not have an entry in lucene/CHANGES.txt. Consider adding one. If the PR doesn't need a changelog entry, then add the skip-changelog-check label to it and you will stop receiving this reminder on future updates to the PR. |
There was a problem hiding this comment.
Thank you for this contribution @ayagmar, this will be great to have!
What do you think of merging this first with the actual operations disabled, i.e. logging only, to see that ie behaves as expected? I've had a lot of issues previously with workflows I'd tested on my fork that behaved differently in the main repo. Plus, it will be good for us to observe it "in the wild" for a bit to make sure it's configured in a way that is most helpful.
Secondly, I'm wondering how we make it so people use it. Can we pick up the version to backport to from the CHANGES file or from the milestone? We recently added a bot that reads that file and determines the right release, which usually corresponds to the branch we'd want to backport to. Not saying that we have to do this right away, but otherwise I'm worried people who would like to use this workflow will simply forget to add a label. Maybe we could add a comment to the PR when it's opened? This would be after out initial logging-only testing phase.
Just to make sure - this is not related to the OpenSearch workflow mentioned on the issue, is it?
Once again - thank you for putting this together!
| MERGE_COMMIT_SHA: ${{ github.event.pull_request.merge_commit_sha }} | ||
| DEFAULT_BRANCH: ${{ github.event.repository.default_branch }} | ||
| run: | | ||
| set -e |
There was a problem hiding this comment.
this is a very large bash script: instead of being inline, could it be factored out to a separate .sh file?
practically this can make the file easier to manage, e.g. syntax highlighting, run shellcheck on it if we need, etc.
|
Did you evaluate any existing actions? The first that comes to mind is https://github.com/carloscastrojumo/github-cherry-pick-action which is on the apache infrastructure approved list: https://github.com/apache/infrastructure-actions/blob/main/actions.yml (I haven't even looked or tried to do any comparison myself) |
There was a problem hiding this comment.
This is great! It'll make merging and back-porting PRs a lot easier for committers.
I don't know much about github actions, so my comments are mostly from my observations while merging and back-porting changes in Lucene. I'm intrigued by rmuir@'s comment about the cherry-pick action, wonder if that makes things simpler.
Thank you, for tackling this @ayagmar ! Looking forward to a state where I won't have to manually cherry-pick and run gradle check on my machine for back-porting!
| # Get individual commits from the PR instead of merge commit | ||
| echo "🔍 Getting PR commits..." | ||
| PR_COMMITS=$(echo "$PR_DATA" | jq -r '.commits[].oid' | tr '\n' ' ') | ||
| echo "📝 PR commits: $PR_COMMITS" | ||
|
|
||
| if [ -z "$PR_COMMITS" ]; then | ||
| echo "❌ No commits found in PR" | ||
| create_comment "❌ **Backport to \`$target\` failed** | ||
|
|
||
| Could not find individual commits in PR #${PR_NUMBER}." | ||
| add_label "backport-failed" | ||
| failure_count=$((failure_count + 1)) | ||
| continue | ||
| fi | ||
|
|
||
| # Cherry-pick each commit individually | ||
| cherry_pick_success=true | ||
| for commit in $PR_COMMITS; do | ||
| echo "🍒 Cherry-picking commit: $commit" | ||
| if ! git cherry-pick -x "$commit" 2>&1; then | ||
| echo "❌ Failed to cherry-pick $commit" | ||
| cherry_pick_success=false | ||
| break | ||
| fi | ||
| done |
There was a problem hiding this comment.
Any reason to cherry-pick each commit individually instead of the merged commit. How PRs are merged in Lucene depends on what committers think make sense. For some of them, the full git history is retained, for others changes are squash merged.
|
|
||
| # Define templates in order of preference | ||
| declare -a target_branch_templates=( | ||
| "branch_{{version_us}}" |
There was a problem hiding this comment.
I like Stefan's suggestion of using the milestone label to find backport branch. We already have a bot to put that label based on CHANGES entry!
In Lucene, a change meant for 10.3.0 will be back-ported into branch_10x. Generally, our back-port branches follow the naming scheme branch_{MAJOR_VERSION}x. Would that match any of the branch templates defined here?
stefanvodita
added
the
skip-changelog
|
Hello everyone, thanks for all feedback, I will try to address them one by one over the weekend |
Add GitHub Actions workflow for automatic PR backporting with intelligent branch detection, conflict handling, and comprehensive error reporting. Supports multiple branch naming patterns and provides detailed feedback via comments.
Fixes : #14496
🔧 Requirements
Enable "Allow GitHub Actions to create and approve pull requests" in repository settings is enabled
🚀 Usage
backport/v1.0,backport/13.1)🏷️ Supported Label Format
backport/1.0→ looks forbranch_1_0,release/1.0,v1.0, etc.backport/13.1→ looks forbranch_13_1,release/13.1,v13.1, etc.Backport/also works🧪 Testing :
Tested with multiple scenarios:
Created A pull request to main, with two labels. backport/existing_branch and backport/branch_does_not_exist
PR is created to the existing branch
Comment is added on main PR to specify one branch was not found
Logs