release-plz
release-plz copied to clipboard
MarcoIeni
release-pr rebase looses verified status
Bug description
So currently for github PR's, release plz will create the commit through github api to have the Verified badge. However when pulling in new changes, it rebases and pushes it using the git command which results in updated commit not having the verified status.
- Would you like to work on a fix? [y]
To Reproduce
You can check eg. https://github.com/eigerco/lumina/pull/189. Currently we have to git commit --amend --S for each release-plz PR which was rebased by the action.
Additional context
I've re-checked the github API and there seems to be no way to do it via it. I can't think of any clean solution right now rather than opening an issue for github to add some new API to achieve that.
that's unfortunate :/ So you don't have any solutions in mind on how to fix this?
one way around would be to have a way to configure release-plz to always recreate PR's, however this will likely make a loooot of noise in repos PRs...
some other workaround could be to have an option like 'rebase=false' and it would create merge commits with main branch each time instead rebasing, and we could document this flag to be only used with squash-merge at the end, cleaning up the resulting message (if github happens to include those merge commits in squashed message)
one way around would be to have a way to configure release-plz to always recreate PR's, however this will likely make a loooot of noise in repos PRs...
This was the original implementation. It makes a lot of noise, yes.
some other workaround could be to have an option like 'rebase=false' and it would create merge commits with main branch each time instead rebasing, and we could document this flag to be only used with squash-merge at the end, cleaning up the resulting message (if github happens to include those merge commits in squashed message)
I think sometimes you would encounter git conflicts in this way :(
The noise could be reduced by rate-limiting the PR recreations and scheduling the postponed ones to happen at troughs of activity, at least for teams that have predictable troughs (mostly in a narrow range of time zones , or low activity on weekends).
Right, but what I mean is that implementing the always-recreate option wouldn't create unacceptable noise for teams that did so.
I documented how to close the old release pr by yourself in https://github.com/MarcoIeni/release-plz/pull/1452
If there are no release PRs, release-plz will always open a new one :) I haven't fully tested it. Can you give it a try and let me know if it works? Then I'll merge it 👍
Looks mostly good, but will fail if there isn't an open release PR, and also is missing GITHUB_TOKEN. See my PR comment.
Thanks, merged it!
Of course I'll leave this issue open because ideally we want the release-plz force-push to keep the verified status 👍
What if we do:
git reset --hard HEAD~1
git push --force
commit via github api
Do you think it should work?
EDIT: I'm looking again at that part of the codebase after sometimes and the logic is more complicated than I remembered 😅 I'll try to raise a PR to validate this so you let me know what you think.
I don't think this would work, iirc you must provide the hash of the commit that you want to be a parent manually and just send changed files. What you do with git locally doesn't matter to the API. I bet if you would provide incorrect parent, it will just fail the api call
Your idea works like a charm :) It's so simple, I can't believe I missed that
Yeah, I thought a git reset --hard HEAD~1 was necessary but it was indeed done earlier 👍