New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GitLab: Merge request "action" not taken into account when determining skippability #81
Comments
For anyone who wants this prioritized, feel free to vote for it on Discuss (or, of course, open a PR). |
usmonster
added a commit
to usmonster/bitrise-webhooks
that referenced
this issue
Feb 1, 2019
Adds the following updates to hook logic for merge requests: * Checks `action` and skips irrelevant updates * Adds a `merge_status` check to skip non-mergeable branches Also: * Updates links to official GitLab webhook docs * Some other very minor cosmetic/pedantic changes Closes bitrise-iogh-81.
4 tasks
usmonster
added a commit
to usmonster/bitrise-webhooks
that referenced
this issue
Feb 1, 2019
Adds the following updates to hook logic for merge requests: * Checks `action` and skips irrelevant updates * Adds a `merge_status` check to skip non-mergeable branches Also: * Updates links to official GitLab webhook docs * Some other very minor cosmetic/pedantic changes Closes bitrise-iogh-81.
slapec93
pushed a commit
that referenced
this issue
Feb 14, 2019
* adds more intuitive merge request event filtering Adds the following updates to hook logic for merge requests: * Checks `action` and skips irrelevant updates * Adds a `merge_status` check to skip non-mergeable branches Also: * Updates links to official GitLab webhook docs * Some other very minor cosmetic/pedantic changes Closes gh-81. * go fmt (on the gitlab hook)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello!
It appears that the GitLab webhook doesn't take into account the "
action
" type on merge request events.The side effect is that every merge request event received with the "
state
" of"opened"
or"reopened"
is passed along to the pull request triggers, regardless of which actual"action"
appears in the payload. For example, on every approval that a merge request gets ("action": "approved"
), a new build can be triggered. This in turn can clog build queues and waste time and money for all Bitrise users. 💸To fix this, there should be additional logic that checks the merge request "action" (along with the "state"), and skips event propagation accordingly.
Thanks!
The text was updated successfully, but these errors were encountered: