As far as I understand, we currently have to add a lable auto-backport and another label auto-backport-to-xyz in order to have a given PR backported.
This seems like seemingly unneeded duplication information. At least from the user's perspective, it should be enough to have the auto-backport-to-xyz label as this already indicates the desire to have this PR automatically backported.

However, I suspect this is a limitation/complication of being able to search for prefixes (substrings) in the label texts? Aka: with this line in the example config:

contains(github.event.pull_request.labels.*.name, 'auto-backport')

However, it would be a neat feature if we would not require this duplication :)

In a project we have two active branches:

• master
• release-<previsous-version>

I simply want that EVERY PR merged to master is automatically tried to be backported to the previous release.

It would therefore be great if one can simply specify the branch for the backport as an option instead of using a label at all.

This should be configurable

Hi,

We use this tool a lot in my company, thanks for it!
However, sometimes, the backport fails for the following reason:

Error: There are no branches to backport to. Aborting

We didn't manage to understand the context of this failure (we even tried to keep branches after merge but we still have the issue).

Do you know why it happens? Is there any fix/workaround to make it fully reliable?
Thank you for any help.

please backport or backport to 7.9

Hi @sqren,

thanks for making such a useful action!

Could you bump backport to the latest version, as it contains a fix for my problem exec error 'git remote rm domenkozar'?

Hi,

I followed the setup described in the README .

When the backport fails because of merge conflicts the action logs the following JSON object:

{
  "status": "success",
  "commits": [
    {
      "author": {
        "name": "Sebastien Arod",
        "email": "[email protected]"
      },
      "sourceCommit": {          
        "committedDate": "2022-05-20T15:08:34Z",
        "message": "xxx.",
        "sha": "dbdcace0fde6e50c46c4b929b3500e8b2aae8cc4"
      },
      "sourcePullRequest": {
        "number": 784,
        "url": "https://github.com/xxx/xxx/pull/784",
        "mergeCommit": {
          "message": "xxx.",
          "sha": "dbdcace0fde6e50c46c4b929b3500e8b2aae8cc4"
        }
      },
      "sourceBranch": "master",
      "expectedTargetPullRequests": [
        {
          "branch": "V5_3",
          "state": "NOT_CREATED"
        }
      ]
    }
  ],
  "results": [
    {
      "targetBranch": "V5_3",
      "status": "handled-error",
      "error": {
        "name": "BackportError",
        "errorContext": {
          "code": "merge-conflict-exception",
          "commitsWithoutBackports": [],
          "conflictingFiles": [
            "xxx.xxx"
          ]
        }
      }
    }
  ]
}

The results property part clearly indicate that there was some merge-conflict-exception but the global status is success and the step is considered successful.

Is this the expected behavior? I would have expected a failed backport to fail the step.

According to this: https://github.com/sorenlouv/backport/blob/main/docs/config-file-options.md#fork
The backport action should create the PRs in its own fork, we use it here with a PAT: eclipse-tycho/tycho#3547

but the branches are created in the main repository while I would expect it to be placed in a forked one of the bot.

This currently leads to branches piling up what is not nice: https://github.com/eclipse-tycho/tycho/branches

When the backport action creates the backport PR, I see GH action workflows not triggering on the PR commit (neither push nor pull_request trigger).

I'm guessing this has something to do with the PR being create from a GH action.
If that's the case, this isn't really a feature of this project, but of GH actions itself.

I just thought I'd create an issue here to check if my assumption is correct, or if this can be worked around somehow.

This backport run fails due to merge conflicts, however, the action does not report the error.

https://github.com/saltstack/salt/actions/runs/6289260964/job/17075576644#step:3:460

Right now, we don't know how many backport runs actually failed when they reported success.

Hi @sqren, 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, its backports also belong to the same milestone.

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?

Using the example workflow in the readme, the action will fail when a PR is merged that does not have a backport label.
This is functionally correct, but causes confusion because the PR is now displayed with a ❌ (red x) next to it.

Do you have any suggestion how this could be avoided?
To me it feels like the Action should succeed because the PR does not have any relevant labels attached. But I am open to other suggestions.

Here is the error:

  "error": {
    "name": "BackportError",
    "errorContext": {
      "code": "no-branches-exception"
    }
  },
  "errorMessage": "There are no branches to backport to. Aborting."

Example Workflow run: https://github.com/aws/jsii-rosetta/actions/runs/9088130104/job/24977165701
Example PR: aws/jsii-rosetta#1359

Hi,

I followed the README instructions but when I run the action it fails with the following result:

{
   "targetBranch": "xx",
   "status": "unhandled-error",
   "error": {
     "name": "SpawnError",
     "context": {
       "cmdArgs": [
         "commit",
         "--no-edit",
         "--no-verify"
       ],
       "code": 128,
       "stderr": "Author identity unknown\n\n*** Please tell me who you are.\n\nRun\n\n  git config --global user.email \"[email protected]\"\n  git config --global user.name \"Your Name\"\n\nto set your account's default identity.\nOmit --global to set the identity only in this repository.\n\nfatal: empty ident name (for <runner@fv-az135-893.uqcy5m2vj4pengxy1oencsd1xf.phxx.internal.cloudapp.net>) not allowed\n",
       "stdout": ""
     }
   }
 }

It looks like the action does not set the git identity when it creates the commits. Is there some additional configuration needed?

Create a commit status for every new commit, and for whenever a new label is added/remove from a PR:
https://octokit.github.io/rest.js/v18#repos-create-commit-status
https://docs.github.com/en/rest/reference/repos#create-a-commit-status

on:
  pull_request:
    types: [labeled, unlabeled, synchronize]

synchronize: commits to the pull request

The title of this issue is self explanatory, but in recent versions of this action the backport:skip label no longer applies, and causes this to always fail the workflow, at least if it isn't being backported. Can this functionality please be readded?

For reference:

{
  "status": "failure",
  "commits": [],
  "error": {
    "name": "HandledError"
  },
  "errorMessage": "Please specify a target branch: \"--branch 6.1\".\n\nRead more: https://github.com/sqren/backport/blob/main/docs/configuration.md#project-config-backportrcjson"
}