Replies: 1 comment 1 reply
-
I can confirm this. Having a trigger on |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Select Topic Area
Bug
Body
I've observed that a workflow with the following configuration will result in some of its runs being absent from a PR's "merge box" intended to display all related commit statuses associated with the head of a PR's branch if it contains labels at open time.
In my case, I'm configuring a workflow that should run one set of jobs on a PR when it contains a specific label and another set of actions when a PR doesn't contain that label (mostly to communicate usage instructions via the merge box that explain that an action can be "dispatched" on a PR by adding a label) 12. To accomplish the first portion of this logic, I listen to
pull_request.labeled
andpull_request.synchronize
events. To present the usage instructions in the merge box on both the FIRST and SUBSEQUENT commits on a PR and to validate that the required actions have happened, I need to listen for both thepull_request.opened
andpull_request.synchronize
events.Unfortunately, what I actually observe is that the
pull_request.opened
event fires and is displayed in the "merge box" at the bottom of the PR.pull_request.labeled
events also fire if the PR has labels, but their statues are missing from the merge box.According to GitHub Support, this "race condition" could potentially could affect more than just the UI. For example, if the workflow is a required check, it may make the PR unmergable. Support has suggested that I break the logic into two workflows, one that listens to
pull_request.labeled
events and another that listens topull_request.opened
events.I don't see any documentation about this limitation of the
pull_request
event here, so I'm opening this discussion to share context with others in advance of possibly updating the documentation myself.Have you seen this behavior? Do you have any workarounds other than duplicating logic between two workflows? How can a loving god cause such agony? Anyway, thanks in advance!
Footnotes
The ability to "dispatch" an action from the pull request UI would significantly simplify this use case! If there's any action I could take that would help advocate for that feature please do let me know. ↩
Sorry about ChatOps, PR-Ops is the future. 😅 ↩
Beta Was this translation helpful? Give feedback.
All reactions