Unsupported empty commits

[noozo]

Hi Nathan, thanks for this action.

I can't seem to create any PR's that contain empty commits:

found 2 commits to backport.
Switched to future branch: backport-master-102121-staging.
An error occurred while cherry-picking.

Traceback (most recent call last):
  File "/action/helpers.py", line 17, in git
    command_run = subprocess.run(["git", *args], stdout=subprocess.PIPE, stderr=subprocess.PIPE, check=True)
  File "/usr/local/lib/python3.8/subprocess.py", line 516, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['git', 'cherry-pick', '60aa289457b561e882faee95c3e89cd306802e85']' returned non-zero exit status 1.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/action/main.py", line 30, in backport_commits
    git("cherry-pick", commit_hash)
  File "/action/helpers.py", line 26, in git
    raise GitException(output)
helpers.GitException: The previous cherry-pick is now empty, possibly due to conflict resolution.
If you wish to commit it anyway, use:

    git commit --allow-empty

Otherwise, please use 'git cherry-pick --skip'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/action/main.py", line 69, in <module>
    entrypoint(
  File "/action/main.py", line 47, in entrypoint
    new_branch = backport_commits(commits_to_backport, base_branch, pr_branch)
  File "/action/main.py", line 33, in backport_commits
    raise RuntimeError("Could not cherry pick at least one commit automatically.")
RuntimeError: Could not cherry pick at least one commit automatically.

[noozo]

Actually i can't make it work even with normal commits:

Traceback (most recent call last):
  File "/action/helpers.py", line 17, in git
    command_run = subprocess.run(["git", *args], stdout=subprocess.PIPE, stderr=subprocess.PIPE, check=True)
  File "/usr/local/lib/python3.8/subprocess.py", line 516, in run
    raise CalledProcessError(retcode, process.args,
subprocess.CalledProcessError: Command '['git', 'cherry-pick', 'fe4658cb30c6d152ea97d8c6bacd811be830c56c']' returned non-zero exit status 1.

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/action/main.py", line 30, in backport_commits
    git("cherry-pick", commit_hash)
  File "/action/helpers.py", line 26, in git
    raise GitException(output)
helpers.GitException: error: could not apply fe4658c... Renaming workflow files for clarity
hint: after resolving the conflicts, mark the corrected paths
hint: with 'git add <paths>' or 'git rm <paths>'
hint: and commit the result with 'git commit'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/action/main.py", line 69, in <module>
    entrypoint(
  File "/action/main.py", line 47, in entrypoint
    new_branch = backport_commits(commits_to_backport, base_branch, pr_branch)
  File "/action/main.py", line 33, in backport_commits
    raise RuntimeError("Could not cherry pick at least one commit automatically.")
RuntimeError: Could not cherry pick at least one commit automatically.

[Nathanmalnoury]

Hey @noozo, sorry for the late response !

Thank you for your interest and issue. There seems to be 2 distinct issues here: (1)Backporting a branch with an empty commit and (2) Backporting a branch without one.

For the (1): The solution is probably to follow git's advice and add --allow-empty to my cherry-pick action.

For the (2) one, it seems to me like the cherry-pick resolved in a conflict.

If that's the case, the bot can't do much about it, except opening an issue in Github reporting the conflict. To check that there really is a conflict, the simplest I've found is to reproduce step-by-step the procedure locally and by hand. If during the cherry-picks you do encounter a conflict, then I'd call the second error an expected behaviour.

If you have the time and interest, could you try to use the action on more branches ? See if at least it does work sometimes (on branches without empty commits) ? And if you encounter an error like the one in (2) check that it is indeed a conflict ?