Issues with new action based approach
nyalldawson opened this issue · 15 comments
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
Hi Nyall, thanks for reporting the issue.
Yes the action is ready, you can see it working successfully here.
Your issue happened because qgis/QGIS#32978 comes from a fork. It prevents the GITHUB_TOKEN to push back to the original repo like mentioned in this answer and this doc section. An unsatisfying workaround would be to use a personal access token instead of GITHUB_TOKEN, a bit like explained here. However, this could be a security concern since forks could get access to it and do things on your behalf.
If you want the old behavior back, you can create your own GitHub App and deploy it. It's pretty easy to do like shown in the previous CI config. See also my similar answer in another repo: tibdex/autorebase#55 (comment).
Almost all PRs in our project come from forks.. if I read correctly, to get (some of?) the functionality back we'll have to roll a custom build for it?
Sorry for breaking your workflow with forks, I didn't think about them. As I said, the code of the previous implementation is still available: https://github.com/tibdex/backport/tree/668468c3b4254292d717d098b8f2a2c96795ebd5. You can deploy that very easily on Zeit's Now if you want the old behavior.
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?
In our open source project a large amount of PRs come from external people that we have no control over, the labels had the advantage that we could add them quickly without asking for external interventions.
Adding a comment in the commits adds friction, especially when the work is large-ish and thus split into multiple commits (we ask people to use a single commit, but sometimes a PR holds legit work assigned to different tickets, all working together to achieve a given final functionality).
That said, it would still be better than not having a backport bot at all :-D
thanks for the idea, but I don't think either that commenting in the commits is very practical.
can you explain what is the key difference between action and what was used before (workflows?)?
Cheers
@nyalldawson @3nids @aaime Problem solved on my fork, provided your repo is public. You can get it from Github Marketplace under "Backport Bot". Instructions here: https://github.com/gaurav0/backport/README.md
is there a way to trigger this once the PR has already been merged?
@Gaurav0 thanks, but apparently it fails, see qgis/QGIS#33223
could it be that the PR was merged before the addition of the yaml file?
@3nids Not only that, the commit needs to be from a branch that already had the yml file in it before he branched from it.
ah I see! thanks a lot for putting this online and for the explanations.
@tibdex sorry at being a bit rude at your nice proposal. It would work well, I just think it's better for us to be able to create the backport before it's actually being merged and we still allow rebase merges.
I have taken @Gaurav0 's approach and created an action to give the token while working from forks (https://github.com/opengisch/clear-token). I have been trying to chain this with your action but this result in an error: opengisch/clear-token#23 (comment)
I believe your code is missing the part to handle upstream that have done @Gaurav0: master...Gaurav0:master#diff-0f75962726e2242efcec5e17e3fdc09cR102-R127
Would you be willing to integrate this?
(I am just wondering if it makes sense to keep the 2 actions around)
Instead of using GITHUB_TOKEN you could try using GitHub App token.