Replies: 39 comments 3 replies
-
Thank you for reaching out! It’s a limitation that workflow is not triggered for ‘pull_request’ event if conflicts exist. BTW, please set ‘if’ expression at step level and ‘startswith()’ doesn’t accept variables, please use code sample as below:
|
Beta Was this translation helpful? Give feedback.
-
Hello, can you tell me if this limit still exists? I am currently facing a similar problem. |
Beta Was this translation helpful? Give feedback.
-
How is this Solved? The the question is specificly asking how to trigger an action for a conflict on a pull_request and the solution does not provide any hint on how to do this. |
Beta Was this translation helpful? Give feedback.
-
What exactly is the suggested course of action when a PR has merge conflicts with the master branch of a repo? Actions don’t run at all, and using Github’s merge tool causes the master branch to be merged into the PR branch. This is, IMO, super messy and not ideal. The problem that seems to be at the root of this issue is that actions/checkout doesn’t checkout the PR’s branch, but it actually merges the branch into master. Regardless of whether it should do this or not, I would expect to see an error inside of that action’s output, instead of having the action not run at all. |
Beta Was this translation helpful? Give feedback.
-
Hi @adrianjost @sebr74 @JGJP, When conflicts exist for pull request, you can get the information as below, you need to resolve the conflict firstly then event will be triggered. Thanks |
Beta Was this translation helpful? Give feedback.
-
The problem with the approach of “resolve your conflicts first” is the fact that my actions do not really have to do anything with code at all. E.g. I have an action, which links JIRA tickets into a description of a PR, taking it from branch name. Or another example is an action, which would label PRs with a package name in a monorepo, which has nothing to do with code either, but requires PR context to exist It’s hard to understand WHY |
Beta Was this translation helpful? Give feedback.
-
Thanks for your reply. With all due respect, I don’t think you’re understanding the issue, because your reply offers no help or additional information. |
Beta Was this translation helpful? Give feedback.
-
Hi @JGJP, For pull_request event, the related ref is a fake merged branch: refs/pull/:prNumber/merge, however it’s not related to actions/checkout. If there’re any conflicts, github cannot create it automatically for the workflow. AFAIK, currently you can use web editor or command line tool (git bash) on local machine to resolve the conflicts. Much appreciate your ideas below, according to the policy, it’s recommended to raise a feedback ticket here where github product manager will take a review. Thanks |
Beta Was this translation helpful? Give feedback.
-
This is clearly a bad design. Actions aren’t necessarily related to code. Having conflicts shouldn’t be a blocker. My actions deploy the code elsewhere, and having conflicts is not an issue. Sometimes, those conflicts will never be fixed because we’re working from a v1 to v2 and use the PR as a diff tool, but don’t meant to perform an actual merge in the end. Bypassing this default behaviour seems quite necessary. And warning about WHY a workflow doesn’t run in such case would be very welcome! |
Beta Was this translation helpful? Give feedback.
-
I’ve created a new shiny bot that resolves git conflicts (on lock files) automatically and pushes fixed branch back. |
Beta Was this translation helpful? Give feedback.
-
I also think that workflow should be triggered anyway. |
Beta Was this translation helpful? Give feedback.
-
Wasted 2-3 hours on this issue. It would never occur to me that this might be the case. PLEASE, add a note that GH actions will not run and why. |
Beta Was this translation helpful? Give feedback.
-
Does anyone know a workaround for this? Maybe run actions on If a PR in fact exists, what environment variables would we need to fake? Or would GitHub need to add a new |
Beta Was this translation helpful? Give feedback.
-
The |
Beta Was this translation helpful? Give feedback.
-
That’s true, but I believe you can get a ref to the head from the pull request object and checkout to it. This at least solves the problem of pull_request events not running when there are conflicts |
Beta Was this translation helpful? Give feedback.
-
Wasted quite a bit of time on this issue, it would be ideal to at minimum have a message so that users can be aware that the root cause of this failure to run is related to the merge conflicts, as it is not an intuitive behaviour. |
Beta Was this translation helpful? Give feedback.
-
We also have trouble with this. We have actions that move cards around the Kanban board. Moving a card with a merge conflict is desired behavior that doesn't work. Or we don't know how to configure it to run even with a merge conflict. |
Beta Was this translation helpful? Give feedback.
-
really need to be able to override this behaviour |
Beta Was this translation helpful? Give feedback.
-
+1 for the comment that it's very confusing for it to show Does anyone have an example of an action that will run on |
Beta Was this translation helpful? Give feedback.
-
🤦♂️ https://stackoverflow.com/questions/67501652/github-workflow-event-trigger-synchronize-not-working Just ran into this now. What a great job you guys at github are doing with github workarounds. Love every minute working with this garbage. Thanks. P.S. when someone writes some hype blogpost about how github actions are great, send them links to these issues, its a goldmine. |
Beta Was this translation helpful? Give feedback.
-
This is a bug. An engineer at Github put an arbitrary condition If the merge conflict causes the action to fail, let it fail. Don't skip. CI should not care about merge conflicts. |
Beta Was this translation helpful? Give feedback.
-
We never had the issue before (or at least we never realized we had it 😳), but starting around July 31st 2023, we started to experience it. I can't see what we changed in our code that could have resulted in this behavior starting to manifest itself. Was there a change on GitHub side that solved the issue for a while, followed by a regression? 🤔 About my opinion on the way it should be: this should probably be an optional parameter in the GitHub workflow. The least surprising behavior for me would be to run even when there is a conflict with the default branch, but I think it would be an acceptable compromise to keep the current behavior (whatever it is) as the default for the parameter. Edit: I confirmed that this is the expected behavior:
|
Beta Was this translation helpful? Give feedback.
-
We are running into this issue and it's causing a bit of dev cycle waste in our teams. We explicitly build feature branch workflows off of the pr base and not a merge commit, so it's confusing why the workflow simply doesn't run just because main had some updates that conflict. I considered switching our workflows to I suppose a workaround to this latter problem would be to branch off of Extending what we already have, a new trigger like |
Beta Was this translation helpful? Give feedback.
-
Ran into this in sharkdp/bat#2755. Actions won't run because of changelog merge conflict (which is yet another longstanding issue that GitHub refuses to address). |
Beta Was this translation helpful? Give feedback.
-
I've also been hit by this annoyance. As someone said before, it is wrong to assume that just because there are conflicts, there should not be automation... |
Beta Was this translation helpful? Give feedback.
-
Same issue here, really annoying. |
Beta Was this translation helpful? Give feedback.
-
A gitflow model we employ is severely hindered by this limitation. All change branches in this model remain silo'd from their respective environment/release branch. Merge commits are disallowed entirely from base to target, so in instances a conflict exists, it's resolved in a temporary branch through GHA automation (where merge commits are allowed). However.. detecting a conflict exists in As many have said, not all pull requests are code related, but equally so, pull request in it's current design is based on a dummy merge ref. I don't want to prescribe the solution, but the current state is broken. |
Beta Was this translation helpful? Give feedback.
-
+1, it would help a lot. |
Beta Was this translation helpful? Give feedback.
-
+1 from me |
Beta Was this translation helpful? Give feedback.
-
By the way, this not only affects |
Beta Was this translation helpful? Give feedback.
-
We have a suite of actions which allows us to build and deploy mobile apps archives from pull requests, which we use as a part of our release process and planned to use for feature development.
Workflow has been configured like this:
...
We have recently started to encounter problems, that actions do not start at all, if PR has any conflicts with a base branch. This is a rather interesting limitation for our use case, our current gitflow assumes possible existance of merge conflict between release/ and master branches (we cherry pick hotfixes), where in the end we would occasionally override master branch with changes from release with strategy-option (this happens because of previous release hotfixes having different parent commits).
For feature branches it’s also rather an undesired behaviour, since if I want to share a test build with my colleagues (designer, pm) to test, we don’t really care whether I’m up to date with base branch.
In fact checkout action already allows to disable merging into base, which we use, but it doesn’t really work if you workflow doesn’t get trigged at all.
There have been some other related threads, which didn’t got much attention in the end:
https://github.community/t5/GitHub-Actions/Support-pull-request-events-without-merge-commit-into-the-target/m-p/36190#M2470
actions/checkout#15
Suggested approach with using on: push, doesn’t really work with labels. We know for sure that we can work it out with on: issue_comment, but it’s cumbersome and requires an extra API call to get PR context.
What would be really nice is an option in repo settings to allow run actions with merge conflicts. Or if there’s any alternative solution to configure a workflow run without looking at a conflicts and ideally with a context of a PR, would be great to know.
Thank you!
Beta Was this translation helpful? Give feedback.
All reactions