You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Running backport locally:
Merge conflict => Fix locally before it is pushed & PR created
Running backport via Github action:
Merge conflict
=> Creates a PR for the branches that have no merge conflicts.
=> Merge conflict reported in the log
=> Merge conflicts are not reported on higher level, for examply failed/warning on GH action.
What I'm asking:
Can there maybe be a config option to force cherry-pick & push and let the merge conflict be handled by Github in the pull request?
For example:
git cherry-pick commit_sha
Merge conflict (ignore)
git add .
git cherry-pick continue\
Optional: Add label "merge-conflict" to the PR
I would build a Github check on PR, to check for "<<<<<<< HEAD".
People can then checkout the PR branch, do some fixes, push and merge the PR.
Maybe mostly useful for the Github Action route, but still usefull in my opinion. Would you be open to a change like this?
The text was updated successfully, but these errors were encountered:
The fact that the github action is successful but the PR isn't created due to a merge conflict is a bug IMO, not a feature request. I was very surprised to find that this has been reported and not resolved after such a long time. Rather than a config, I believe this should be standard behavior. Right now devs in my team complain about missing backport PRs and you need to dig into the github action logs to find out what the actual issue is. This could mean that a backport could be forgotten which is very bad. @sorenlouv my suggestion would be that if you don't have the bandwidth to resolve this, we should at least at a warning message on the main README communicating this bug, or at least call it a beta feature.
For anyone reading, setting commitConflicts: true in the config won't make Github recognize that there are unresolved conflicts. The conflicts will simply be committed and so if your CI doesn't catch the failing build, it's possible that the backport's unresolved merge conflict is overlooked and merged in.
Tested with:
Merge conflict => Fix locally before it is pushed & PR created
Merge conflict
=> Creates a PR for the branches that have no merge conflicts.
=> Merge conflict reported in the log
=> Merge conflicts are not reported on higher level, for examply failed/warning on GH action.
What I'm asking:
Can there maybe be a config option to force cherry-pick & push and let the merge conflict be handled by Github in the pull request?
For example:
I would build a Github check on PR, to check for "<<<<<<< HEAD".
People can then checkout the PR branch, do some fixes, push and merge the PR.
Maybe mostly useful for the Github Action route, but still usefull in my opinion. Would you be open to a change like this?
The text was updated successfully, but these errors were encountered: