We'd like to acknowledge cherry-pick-action for giving a great foundation for us to build additional functionality. Please check out that action if you think it better suits your needs.

Automatically create a cherry pick pull-request to user defined labels and/or static release branches!

• What does it do?
• Differences
• Examples/Demos
• Usage
• Configuration
• Inputs

This action will:

• Checkout the triggered action.
• Create the new branch name cherry-pick-${GITHUB_SHA} from branch input.
• Cherry-pick the ${GITHUB_SHA} into the created branch
• Push a new branch to remote
• Open a pull request to branch

In the other action, a user must specify the release branch in the workflow; This action allows for users to input their own branches via labels. This action also supports specifying multiple release branches in one PR.

Head over to this repo to see this in "action"! (pun intended)

Take this pull request for example:

• Before or after merging the pull request main, the user specified the release branch they'd like to cherry pick that commit to.
• By adding the CP v2.0.0 label, the action opened this pull request on behalf of the user, according to the action's Configuration.

Usage depends on your needs. Please see the following options:

Do you want users to be able to specify the release branches dynamically via labels?

• Please see User Defined Labels and its inputs.

Want to statically define a release branch or trigger it based on other logic?

• Please see Basic Configuration and its inputs

Some examples:

on:
  pull_request:
    branches:
      - main
    types: ["closed", "labeled"]

jobs:
  cherry_pick_release_v1_0:
    runs-on: ubuntu-latest
    name: Xealth Auto Cherry Picker
    steps:
      - name: Checkout
        uses: actions/checkout@v2
        with:
          fetch-depth: 0
      - name: Xealth Auto Cherry Pick
        uses: xealth/cherry-pick-action@v1.0.0
        with:
          allowUserToSpecifyBranchViaLabel: 'true'
          labelPatternRequirement: 'CP v' <--- Every label that starts with "CP v" will be cherry picked
          userBranchPrefix: 'v' <--- This add a prefix to the branch (if the branch starts with a prefix)
          labels: |
            cherry-pick
          reviewers: |
            aReviewerUser
env:
  GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Cherry-picking pull requests merged on main to branch release-v1.0 in pull requests labeled with release-v1.0 and to branch release-v2.0 in pull requests labeled with release-v2.0.

on:
  pull_request:
    branches:
      - main
    types: ["closed"]

jobs:
  cherry_pick_release_v1_0:
    runs-on: ubuntu-latest
    name: Cherry pick into release-v1.0
    if: contains(github.event.pull_request.labels.*.name, 'release-v1.0')
    steps:
      - name: Checkout
        uses: actions/checkout@v2
        with:
          fetch-depth: 0
      - name: Cherry pick into release-v1.0
        uses: xealth/cherry-pick-action@v1.0.0
        with:
          branch: release-v1.0
          labels: |
            cherry-pick
          reviewers: |
            aReviewerUser
  cherry_pick_release_v2_0:
    runs-on: ubuntu-latest
    name: Cherry pick into release-v2.0
    if: contains(github.event.pull_request.labels.*.name, 'release-v2.0')
    steps:
      - name: Checkout
        uses: actions/checkout@v2
        with:
          fetch-depth: 0
      - name: Cherry pick into release-v2.0
        uses: xealth/cherry-pick-action@v1.0.0
        with:
          branch: release-v2.0
          labels: |
            cherry-pick
          reviewers: |
            aReviewerUser
env:
  GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

If your release branches do not change often, setting up user defined labels might not be necessary.

If you'd like users to cherry pick based on label input, see below:

• Keep in mind, branch will be overriden if allowUserToSpecifyBranchViaLabel is set true!
• Also, labelPatternRequirement searches for an exact match using .includes(labelPatternRequirement): We plan to support regex eventually

Note from the original author:

If you are using this action while working with forked repositories (e.g. when you get pull requests from external contributors), you will have to adapt the trigger to avoid permission problems.

In such a case you should use the pull_request_target trigger, which was introduced by github for this usecase.

on:
  pull_request_target:
    branches:
      - main
    types: ["closed"]
 ...

More information can be found in the GitHub Blog

Please contribute by opening a pull-request! We recommend also opening a pull request to the original creator's repository as well.

MIT