gaurav0 / backport Goto Github PK

Step 6 in the install guide confuses me. It is not immediately clear to me how I am supposed to obfuscate the access token. Can you offer some advice?

can you please trigger a new release?

It would be nice to include the name of the original author in the PR description :

This would trigger a notification of the original author and he can keep track of the backport PR. Maybe he is not "watching" the repository on GH so he won't be notified of the following PR.

Hi,
Was wondering if there was a reason -x wasn't in the git cherry-pick command line in

Forgive me if I'm missing something, my gitfoo is weak

Looks like we need to generate a personal access token for a bot account and then xor it with some other hex string to "obfuscate" it? Why not make use of the secrets and have devs set up a repo secret holding the personal access token?

it would be nice to enhance the commit message with: "cherry-picked from xxxx by @whoever"

having a success if the bot could not perform the backport is misleading to me.

${user}/${repo} does not exist

We had a case where the cherry-picking went wrong:

Here is the PR:
qgis/QGIS#33634
The created backport PR
qgis/QGIS#33649

Any idea what has gone wrong?

I had to do something similar for the key obfuscation in another workflow (creating issue in another repo triggered by PR on forks).
I have replicated your idea, but created a dedicated action for this: https://github.com/opengisch/clear-token
I am thinking to chaining this action with the original backport action.

The current bot implementation supports only single-commit PR merges. This works great for squash merges, and I see it now sort-of works for merge commits. But it doesn't support rebased merges (unless there's only one eventual commit merged).

The electron/trop bot seems to handle multi-commit merges: https://github.com/electron/trop/blob/f3facf6f854f24e5d8453f2b3caae9c97fbfa876/src/utils.ts#L213-L310

Specifically, it asks for the list of commits on the PR, and pulls down the patches for those commits and then applies them in series. See https://github.com/electron/trop/blob/f3facf6f854f24e5d8453f2b3caae9c97fbfa876/src/operations/backport-commits.ts

It's likely much faster for single-commit PRs to keep the current cherry-pick logic, but for multi-commit PRs this may be useful.