xealth/cherry-pick-action

A Cherry Pick GitHub Action :cherries:

Fork of this action: cherry-pick-action

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.

Xealth "Manhattan" - A Cherry Pick GitHub Action 🍒

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

---

🤔 What does it do?

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

---

Differences from cherry-pick-action

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.

---

💻 Examples/Demos

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

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

---

📋 Configuration

Some examples:

User Defined Labels

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/[email protected]
        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 }}

Basic Configuration

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/[email protected]
        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/[email protected]
        with:
          branch: release-v2.0
          labels: |
            cherry-pick
          reviewers: |
            aReviewerUser
env:
  GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

---

Action inputs

Basic Configuration

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

Name	Description	Default
token	GITHUB_TOKEN or a repo scoped Personal Access Token (PAT).	GITHUB_TOKEN
committer	The committer name and email address in the format Display Name <[email protected]>. Defaults to the GitHub Actions bot user.	GitHub <[email protected]>
author	The author name and email address in the format Display Name <[email protected]>. Defaults to the user who triggered the workflow run.	${{ github.actor }} <${{ github.actor }}@users.noreply.github.com>
branch	Name of the branch to merge the cherry pick.	create-pull-request/patch
labels	A comma or newline-separated list of labels.
assignees	A comma or newline-separated list of assignees (GitHub usernames).
reviewers	A comma or newline-separated list of reviewers (GitHub usernames) to request a review from.
team-reviewers	A comma or newline-separated list of GitHub teams to request a review from. Note that a repo scoped PAT may be required.

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

User Defined Labels

Name	Description	Default
allowUserToSpecifyBranchViaLabel	Must be true (string) if enabled, Allows the user to specify which branch or branches to cherry pick to via their label
labelPatternRequirement	If the above is true, a user can specify a label pattern to look for. Ex: "CP v" will find labels like "CP v1.0.0"
userBranchPrefix	A prefix to apply to the release branches. Ex: v -> v1.0.0 or release- -> release-1.0.0

• 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:

Working with forked repositories

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.

Example

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

More information can be found in the GitHub Blog

Contributing

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

License

MIT

cherry-pick-action's Issues

How the cherrypick actually works ?

Right now i am trying to use REST API from github to cherrypick the commits from a given PR into a new branch created based on a given branch and in the end, create a PR for it.

Everything looks to be working fine, however, when i try to cherrypick using the endpoints of patch to update the branch with the commit, it includes commits from other pull requests in the changed files.

Basically i want to mimic the command from git bash:

• git checkout desired_branch
• git checkout -b new_feature_cherry-pick
• git cherry-pick commithashs //commit hash being the hash of the commits being done in the PR of another branch.

Heres how the changed file looks:

File 2 and the first line of file 1 are changes from other pull requests that were merged into another branch but not in the one from this PR.

What i need is that the PR has ONLY the changes from the given PR.

I was wondering if this can happen the same way using github actions ? Or this does not happen in this action ?

Looking up the issues on gorillio/github-action-cherry-pick#2, it looks to happen the same thing there.

Is this repo maintained?

I noticed various bumped versions that need to be merged. I'm wondering if is there a plan to merge them?