Let me start off by admitting my git-fu isn't the best. But is there no way to support backporting merge commits?

Backporting 2679a1e0f42284e7d60a59067c4a56194c696ba0 from #46773.
/usr/bin/git clone ***github.com/ceph/ceph.git
Cloning into 'ceph'...
Updating files:  94% (10781/11449)
Updating files:  95% (10877/11449)
Updating files:  96% (10992/11449)
Updating files:  97% (11106/11449)
Updating files:  98% (11221/11449)
Updating files:  99% (11335/11449)
Updating files: 100% (11449/11449)
Updating files: 100% (11449/11449), done.
/usr/bin/git config --global user.email github-actions[bot]@users.noreply.github.com
/usr/bin/git config --global user.name github-actions[bot]
Backporting to quincy on backport-46773-to-quincy.
  /usr/bin/git switch quincy
  Switched to a new branch 'quincy'
  branch 'quincy' set up to track 'origin/quincy'.
  /usr/bin/git switch --create backport-46773-to-quincy
  Switched to a new branch 'backport-46773-to-quincy'
  /usr/bin/git cherry-pick -x 2679a1e0f42284e7d60a59067c4a56194c696ba0
  error: commit 2679a1e0f42284e7d60a59067c4a56194c696ba0 is a merge but no -m option was given.
  fatal: cherry-pick failed
  /usr/bin/git cherry-pick --abort
  error: no cherry-pick or revert in progress
  fatal: cherry-pick failed
  Error: Error: The process '/usr/bin/git' failed with exit code 128

Could this tool potentially recursively cherry-pick all the commits from a merged PR?

RIght now the action comments if the backport merge failed for some reason. It would be super helpful if it could (optionally) also attach a label to a failed PR, so it's easier to filter for them and manually backport.

Right now the naming convention for the source branch is:
head = backport-${pullRequestNumber}-to-${base}

We have branch protection policies on the base branches though (they are our release branches). By putting the base branch name at the end of the PR's source branch, the branch policy picks it up and locks it down.

Example:

• Branch policy for *.latest
• Base branch: 1.0.latest
• Source branch: backport-123-to-1.0.latest

I'm looking for the ability to pass a custom source branch name to use instead of the default given so we can work around this branch policy issue.

This is a feature request that I would be happy to help with if people are interested in adding this functionality.

Hi.

First of all, thank you for this lovely github action. It seems to fit exactly the use case I'm facing at the moment.

I see that there is a MIT license specified in https://github.com/tibdex/backport/blob/master/package.json but the repo itself does not have a license.

Thanks for the awesome action! It deserves many more stars... We've just deployed over at https://github.com/PRQL/prql/blob/main/.github/workflows/pull-request-target.yaml

One thing that would be nice would be an ability to auto-merge PRs. This is possible with the gh CLI (i.e. in my git configs I have:

    pub-merge-gh   = !git publish && gh pr create --fill && gh pr merge --auto --squash --delete-branch

)

But no huge problem without it... Thanks

Hi @tibdex, thank you for this github action, it is very useful.

One thing that would help my team would be that when the pull request that is being backported belongs to a github milestone, or has some labels, they get carried over to the backport.

If you are not able to provide this feature for free (which is understandable) would you be open to reviewing a pull request? If that's the case, would you prefer that that's controlled by a config setting, or would you be ok with this being always enabled?

Thanks a lot for this action — it makes our workflows much easier over at prql

We're getting this deprecation message on every PR, e.g. https://github.com/PRQL/prql/actions/runs/5730542043:

The set-output command is deprecated and will be disabled soon. Please upgrade to using Environment Files. For more information see: https://github.blog/changelog/2022-10-11-github-actions-deprecating-save-state-and-set-output-commands/

When the automatic backport bot fails, it provides instructions for doing the backport manually. One of the steps is a cherry-pick:

# Cherry-pick the merged commit of this pull request and resolve the conflicts
git cherry-pick 06e4af4a33073b8a053a4951285eebe46332b345

Unfortunately that won't work if the PR was merged via a merge commit (rather than a squash merge):

$ git cherry-pick 06e4af4a33073b8a053a4951285eebe46332b345
error: commit 06e4af4a33073b8a053a4951285eebe46332b345 is a merge but no -m option was given.
fatal: cherry-pick failed

specifying -m 1 fixes that:

$ git cherry-pick -m 1 06e4af4a33073b8a053a4951285eebe46332b345
Auto-merging README.md

This action seems to not handle correctly the cases where:

• a pull request has multiple commits
• it is merged with "rebase and merge"

The expected output is that the backport pr would have the same commits as the original PR.

What we are seeing is that the backport only contains one of the commits from the original PR instead.

Currently, https://github.com/marketplace/actions/backporting shows 1.0.0:

I would expect 2.0.4 instead. Thanks!

We like having this auto backport functionality in https://github.com/opensearch-project/OpenSearch, but it would be great if there is an option to configure the branch name while creating backport PRs which can help in effectively managing such branches. Currently, the branch name is by default set to backport-${pullRequestNumber}-to-${base}.

Hey, first off thanks for building this - it's so well crafted and it's been a huge time saver for us ❤️

When we updated to use the github action approach I noticed that merge commits always fail to backport successfully. If this change is intentional and by design then no worries but I'd love to get that functionality back if you're open to it.

I found that all I needed to do was a slight modification to the instructions it outputs, either git cherry-pick the individual commits in the PR or git cherry-pick -m1 <merge commit> for it to work.

Thanks again for your hard work - if you're open to the change I'll work on a PR for it.

Thanks for the action!

Is there a reason why PRs with multiple commits are not supported when they've been Rebased and Merged, or just that you haven't needed it so far?

Context

I have been testing the backport action on Neudrino/magma#6 with the run https://github.com/Neudrino/magma/runs/7803925676?check_suite_focus=true.

Problem

The run fails with

Backporting to backport/v1.8 on backport-6-to-backport/v1.8.
  /usr/bin/git switch backport/v1.8
  Switched to a new branch 'backport/v1.8'
  branch 'backport/v1.8' set up to track 'origin/backport/v1.8'.
  /usr/bin/git switch --create backport-6-to-backport/v1.8
  Switched to a new branch 'backport-6-to-backport/v1.8'
  /usr/bin/git cherry-pick -x c2379e2d74ebfe72ca90610dda32aa0a68e44f48
  error: commit c2379e2d74ebfe72ca90610dda32aa0a68e44f48 is a merge but no -m option was given.
  fatal: cherry-pick failed
  /usr/bin/git cherry-pick --abort
  error: no cherry-pick or revert in progress
  fatal: cherry-pick failed
  Error: Error: The process '/usr/bin/git' failed with exit code 128

Expected behaviour

The action should work for merged commits.

Additional information

To me it seems as if
https://github.com/tibdex/backport/blob/main/src/backport.ts#L106
is missing the --mainline 1 option. Interestingly, it is given in the error description correctly:
https://github.com/tibdex/backport/blob/main/src/backport.ts#L167

Hello, I would like to ask whether you could consider making the email address used to associate commits made using this Action configurable instead of it being hard-coded.

I would do it myself, but I unfortunately don't really know a lot about TypeScript or GitHub Actions.

This would be useful for projects that wish to use their own infrastructure (or do so at a later point in time) or branding using a GitHub Actions-compatible implementation that utilizes a tool like act. Such an example would be e.g. Gitea or Forgejo, the latter of which started using this action recently: https://codeberg.org/forgejo/docs/issues/18#issuecomment-1062390

According to the usage section on the README:

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.

This means (AFAIU) that PRs merged to the master branch with the label backport production should be auto backported to a branch name production, but what seems to be happening in practice is that the PR is merged to a temporary branch, named backport-<pr_no>-to-production,

Am I missing something? is it on purpose?
It would be great if the PR auto backport directly into the production branch (or any other branch according to the backport <branch> format)

It would be nice if the pull request body could be templated, similiar to the title_template.
Possibly based on the commit message of the original commit.

If you agree, I would be happy to contribute some code to make that happen.

We've added this workflow to our repo but it seems it didn't do much

https://github.com/SumoLogic/sumologic-kubernetes-collection/pull/1342/checks?check_run_id=1708125282#step:2:1

Run tibdex/backport@v1
  with:
    github_token: ***
    title_template: [Backport {{base}}] {{originalTitle}}

config:

name: Backport
on:
  pull_request:
    types:
      - closed
      - labeled

jobs:
  backport:
    runs-on: ubuntu-20.04
    name: Backport
    steps:
      - name: Backport
        uses: tibdex/backport@v1
        with:
          github_token: ${{ secrets.BACKPORT_BOT_TOKEN }}

No logs were printed to trace back where the problem's coming from.

@tibdex In your comment #33 (comment), you wrote:

I have an idea for another GitHub Action design that would work with forks. Instead of labeling a pull request with backport old-branch, you would go to a commit on master or any other branch and comment it with /backport old-branch and that would backport just that commit on old-branch. It would thus work quite well with pull requests merged and squashed (see Autosquash). What do you think. Would you use the action if it was designed like that?

Would you be willing to implement this feature? We would use that feature in one of our repositories (https://github.com/JuliaCI/julia-buildkite) if that feature were implemented.

Is the new action based approach ready and working now? We've previously used this backport bot, but since ce3759c things have broken. I've followed the readme and added backport.yml to the repo (https://github.com/qgis/QGIS/blob/master/.github/workflows/backport.yml), but on merging a labeled PR the backport PR is never opened.

Here's an example PR -- qgis/QGIS#32978, which triggered https://github.com/qgis/QGIS/runs/312351335, but that errors out with:

  git push --set-upstream origin backport-32978-to-release-3_10
  remote: Permission to qgis/QGIS.git denied to github-actions[bot].
  fatal: unable to access 'https://github.com/qgis/QGIS.git/': The requested URL returned error: 403
  ##[error]Backport failed: The process 'git' failed with exit code 128
##[error]Resource not accessible by integration
##[error]Node run failed with exit code 1

When the backport operation fails, it currently gives a short feedback with a minimal error description.

It would be nice to have a copy-paste command to directly execute on the command line available to speed up the manual backporting process.

git cherry-pick [sha1]..[sha2]

It would be nice if the labels on the original PR get propagated to the backport PR (outside of the backport-<BRANCH> label).

Hey,

I was super impressed by your project that could backport a commit via Github's API without ever cloning the repo in question. For huge git repos that can take minutes to clone, this is pretty amazing.
I'm curious why you didn't use this approach for this Github Action. Did you run into problems with that approach or was it just not worth it?

Although not perfect an issue seemed like the best format for this kind of question. But feel free to close as "off-topic" if you want. No hard feelings ;)

When a pull request has multiple backport labels to be backported to multiple branches, today if one of these backports fails, the following ones will be aborted. They should be attempted instead.

Hi, first thanks for this amazing Github action, it makes things much easier :-)

Today i first tried out the backport action and i encountered a strange issue: i merged a pull request into the master which was labeled with backport stable20. After the merge was done the action created a backport pull request as expected which points to stable20. Unfortunately the Github actions for running CI tests aren't triggered by this pull request even if they have a pull_request trigger set.

I created a minimal sample to demonstrate this:

• The original pull request (where the CI action was triggered)
• The created pull request by the backport action (where the CI action was not triggered)

name: Backport
on:
  pull_request:
    types:
      - closed
      - labeled

jobs:
  backport:
    runs-on: ubuntu-18.04
    name: Backport
    steps:
      - name: Backport
        uses: tibdex/backport@v1
        with:
          github_token: ${{ secrets.GITHUB_TOKEN }}

name: Unittest

on:
  pull_request:
  push:
    branches:
      - master
      - stable*


jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: test
        shell: bash
        run: |
          echo "This is a testrun"

Did you encounter any similar issues or am i configuring anything wrong here?

Thanks for your feedback !

I just discovered this app and already love it.

It seems that currently it's only possible to do a single backport. We maintain multiple stable branches but specifying multiple labels only opens one backport. Would it be possible to have several backports ( like backport release-3_4 and backport release-3_6)?

OSGeo/PROJ#1334 has been generated from a Backport label. One weird thing is that this pull request generates 2 Travis-CI and 2 AppVeyor builds. One of them is correct "Travis CI - Pull Request"), but there's a bogus one "Travis CI - Branch" (https://github.com/OSGeo/proj.4/pull/1334/checks?check_run_id=80744998) which operates on a branch cherry-pick-backport-1333-on-6.0-16bdb30b-547c-4c9a-8115-d0a00515f983 that Travis-CI can't find. The same for continuous-integration/appveyor/branch

Problem statement

We have a CI that is configured to run on pull_request events on all branches: https://github.com/Kong/kubernetes-ingress-controller/blob/beac200706f81b9420d21b00653fd59a4040f8bb/.github/workflows/pr_checks.yaml#L12-L14.

Given an exemplar PR Kong/kubernetes-ingress-controller#4128 that got a label to be backported to release/2.10.x branch we received this PR Kong/kubernetes-ingress-controller#4131 which triggered only pull request labelled event not pull_request as it should. Hence we didn't get a full CI run as we'd like to: https://github.com/Kong/kubernetes-ingress-controller/actions?query=branch%3Abackport-4128-to-release%2F2.10.x

Expected behavior

PRs created by this action trigger pull_request event so that a full CI run can be triggered.

Apologies for my newbie question, but I am really unfamiliar with the node.js ecosystem. How do you build and run the bot during development and in production?

I have tried probot run and the likes, but it seems that the backport.js is not picked up. The probot framwork comes up, but the hooks are not registered.

I guess that I am doing something wrong between the typescript compile and launching the app in development.

Any tips would be greatly appreciated.

It would be nice to have a label added to any PR that the backport failed on. Makes it easier to see PRs that need to be handled by hand.

The label example given in the README is rendered with a linebreak on Github which makes the correct format at least harder to understand at a first glimpse:

A simple improvement would be moving this to a separate line.

Hi - It would be really helpful if the labels from the original PR (minus the backport label) were copied to the new PR. We use labels to build our changelogs and have to remember to manually re-label anything backported before merging.

I'm getting the following error notification from the bot once I merged my PR that was labeled with backport <branchname>:

The backport to <branchname> failed:
The process 'git' failed with exit code 128

Is there some way to see the actual output of the git command? I'm assuming that it didn't just return an error code, but actually printed and error message.

Two possible issues I can think of:

• The repository is private (but I would assume that secrets.GITHUB_TOKEN takes care of that)
• The destination branch has branch protections enabled - specifically direct merges and commits without a PR review are disallowed.

We're using this action in our pipeline https://github.com/SumoLogic/sumologic-kubernetes-collection/blob/main/.github/workflows/backport_bot.yaml and it is saving us a ton of work but one minor thing that we're struggling with is that the backport PRs need to be closed and reopened to trigger other Github Actions pipelines.

Is this a problem with our usage or this action?

Before reopening:

After