opensearch-project/opensearch-plugins

Add auto backport functionality to backport PRs for releases

VachaShah opened this issue · 12 comments

VachaShah commented

In order to avoid creating backport PRs for each release and miss some of them in the process, we can add a Github action backport.yml that would create automatic backport PRs when the original PRs are labeled accordingly. This has been done for OpenSearch repo in PR opensearch-project/OpenSearch#1600.

Related documentation: https://github.com/opensearch-project/opensearch-plugins/blob/main/BACKPORT.md

Creating this meta issue to track this feature for plugins for the next release.

cliu123 commented

This is a great idea, which would save tons of pain in handling backports!
Is there a POC on this? A few pain points here:

  1. Not all PRs need to be backported. What are the criterias to let Github Actions determine what PR needs to be backported?
  2. When backporting a PR, in some cases, a PR does not need to be backported to all branches. How to let Githhub Actions to determine which branches need backport?
    If it is decide to defer this to PR review, then the unnecessary PRs would have to be closed by reviewers, which would result in lots of unnecessary closed PRs. Is there a good solution for this?
VachaShah commented

@cliu123 , we implemented this in the OpenSearch repo PR opensearch-project/OpenSearch#1600.

The action works based on the labels added on the PR. So if a PR is to be backported to lets say 1.x branch, the label backport 1.x should be added to the PR and the backport Github action should be run on the PR along with other workflows. Once that PR is merged to main, an automatic backport PR is opened by the backport workflow to the 1.x branch. So the original PR can have labels for multiple branches to which the PR is to be backported. The labels are of the format backport <branch_name>.

dlvenable commented

Is there a guide to branch conventions within OpenSearch projects? I did not see them in the DEVELOPER_GUIDE.

Data Prepper (which is not an OpenSearch plugin) doesn't use a 1.x branch, but has release branches like 1.1 and 1.2.

saratvemulapalli commented

Is there a guide to branch conventions within OpenSearch projects? I did not see them in the DEVELOPER_GUIDE.

Data Prepper (which is not an OpenSearch plugin) doesn't use a 1.x branch, but has release branches like 1.1 and 1.2.

@dlvenable thats good question. We generally follow the convention of 1.x in OpenSearch/Plugins, while rest of the repositories(clients, data prepper etc) just use main, 1.1 etc.
It is documented in https://github.com/opensearch-project/.github/blob/main/RELEASING.md#branching. I would be happy to PR this for rest of the repos which are not covered.

  • 👍1
VachaShah commented

Related issue: opensearch-project/OpenSearch#1712. I am working on fixing the permissions issue.

  • ❤️1
VachaShah commented

The permissions issue is resolved. The updated backport workflow is https://github.com/opensearch-project/OpenSearch/blob/main/.github/workflows/backport.yml. The custom branch naming helps with maintaining proper branch protection rules. Other improvements to be done are added here: opensearch-project/OpenSearch#1962.

VachaShah commented

Auto backport workflow

Why Auto-backport?
Backporting a PR/commit to a release branch is a current manual process and can lead to missed backports before a release. The auto backport Github Action allows to create automatic backport PRs just by labelling them.

When the auto backport workflow is integrated with a repo, the following features are available:

  1. Allows auto backports on PRs that are merged and labelled (can be in any order). To backport a PR to 1.x, please add a label called backport 1.x to the PR and the backport workflow will do the rest.
  2. The backport workflow is now created by a Github App called opensearch-trigger-bot instead of github-actions which allows CI to run on such PRs.
  3. The backport branches are named in the form backport/backport-<original PR number>-to-<base>. These branches will be cleaned up by an auto delete workflow once the backport PR is merged.

An example backport PR: opensearch-project/OpenSearch#2079
Backport workflow: https://github.com/opensearch-project/OpenSearch/blob/main/.github/workflows/backport.yml
Auto delete workflow: https://github.com/opensearch-project/OpenSearch/blob/main/.github/workflows/delete_backport_branch.yml

Note: Auto backport workflow can fail if it finds merge conflicts while cherry-picking a commit to 1.x. In such cases, the opensearch-trigger-bot will comment on the original PR with the steps to take.

How to integrate?
Integrating the backport workflow is easy and can be done with the following steps:

  1. Add the backport workflow in your repo.
  2. Add secrets in your repo for the Github App ID and Private key. This is used to generate a token for the Github App opensearch-trigger-bot. Using this token helps generate the automatic backport PR from the app token so that all the CI triggers work on the PR. (Reference: opensearch-project/OpenSearch#2071)
  3. Add auto delete workflow for deleting the backport branches once the backport PRs are merged. This enables the backport workflow to clean up after itself.
  4. Add appropriate branch permissions for backport related branches in your repo.
  5. Add related labels for release branches. For auto-backports, the labels should be of the form backport <release-branch-name>. (backport 1.x, backport 1.2 etc.)

Thats it! Your backport workflow is integrated and ready to use.

dblock commented

@VachaShah lets promote this doc into something in a .md in this repo?

VachaShah commented

@VachaShah lets promote this doc into something in a .md in this repo?

Sure I will add this in a .md file.

dblock commented

I've re-labelled this 2.0 so we don't lose it.

dblock commented

@VachaShah Can we close this?

VachaShah commented

@VachaShah Can we close this?

Yes closing this since all the tasks are done.