vachashah/backport

🔙 GitHub Action to backport pull requests

backport's Issues

[BUG] When a backport fails the github action should fail

When the backport doesn't work, the github action results don't reflect that the backport didn't work correctly. It would be useful to find backport failures via inspection of the backport github action job results.

....
  hint: You can instead skip this commit with "git cherry-pick --skip".
  hint: To abort and get back to the state before "git cherry-pick",
  hint: run "git cherry-pick --abort".
  /usr/bin/git cherry-pick --abort
  Error: Error: The process '/usr/bin/git' failed with exit code 1

https://github.com/opensearch-project/security/actions/runs/5177797123/jobs/9328356820

[BUG] Sometimes the workflow doesn't pull or fetch the target branch from the remote

What is the bug?

In the output of https://github.com/opensearch-project/oui/actions/runs/5407190554/jobs/9824918616#step:3:32, we can see that the workflow failed on the cherry-pick step, because there were no changes to commit. It appears the reason there was nothing to commit is that, when switching to the target branch, it never actually fetched or synced with the remote branch (1.x, in this case):

Backporting to 1.x on backport/backport-718-to-1.x.
  /usr/bin/git switch 1.x
  Switched to a new branch '1.x'
  branch '1.x' set up to track 'origin/1.x'.

full output:

Run VachaShah/[email protected]
  with:
    github_token: ***
    head_template: backport/backport-<%= number %>-to-<%= base %>
    files_to_skip: CHANGELOG.md
    body_template: Backport <%= mergeCommitSha %> from #<%= number %>.
    label_pattern: ^backport (?<base>([^ ]+))$
    labels_template: []
    title_template: [Backport <%= base %>] <%= title %>
Backporting 7a85d4c3b56d6e1a2c2792a213dcde8a52e2412d from #718.
/usr/bin/git clone ***github.com/opensearch-project/oui.git
Cloning into 'oui'...
/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 1.x on backport/backport-718-to-1.x.
  /usr/bin/git switch 1.x
  Switched to a new branch '1.x'
  branch '1.x' set up to track 'origin/1.x'.
  /usr/bin/git switch --create backport/backport-718-to-1.x
  Switched to a new branch 'backport/backport-718-to-1.x'
  /usr/bin/git cherry-pick -x -n 7a85d4c3b56d6e1a2c2792a213dcde8a52e2412d
  Auto-merging CHANGELOG.md
  /usr/bin/git checkout HEAD CHANGELOG.md
  Updated 1 path from 16e6eeb90
  /usr/bin/git commit --no-edit -s
  On branch backport/backport-718-to-1.x
  nothing to commit, working tree clean
  /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

How can one reproduce the bug?
I don't think this is consistently reproducible, otherwise we'd have more common backport failures. But the way I identified the issue was by following the instructions to manually backport. Usually such cases are because of a merge conflict that needs manual resolution. But in this case the cherry-pick step succeeded without any conflict, so I was curious to take a closer look.

What is the expected behavior?
A clear and concise description of what you expected to happen.

What is your host/environment?

• Version 2.1.0

Do you have any screenshots?
If applicable, add screenshots to help explain your problem.

Do you have any additional context?
Add any other context about the problem.

[FEATURE] Support co-authors

Is your feature request related to a problem?
It would be nice for backports to recognize the original author(s) of the pull-request. At this point in time, backports say that the commit was authored by the Github Actions bot. I think if a commit in the original PR has a co-author, the backport will get that author as well, however the main author is never recognized.

What solution would you like?
The action should extract a list of (co-)authors from the commits of the original PR and craft a list of co-authors to place in the backport commit.

What alternatives have you considered?
I haven't looked into it, but it might be possible to author the commits using the original author's name/email. I don't know how well that would fit into this action, or if it is actually possible.

Do you have any additional context?
In OUI, our release workflow generates a changelog based on the commit diff between the previous release and current release: https://github.com/opensearch-project/oui/releases/tag/1.3.0 The issue is that the original PR authors don't get recognized in the release, as (almost) all of the PRs are backported, thus the original author is lost.

https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors