Some time ago we migrated from self-hosted Bitbucket to hosted GitLab (gitlab.com). We’ve set up our workflows to build as soon as a PR/MR is created or updated. For Bitbucket this worked as expected, but for GitLab it triggers builds a bit too often.
The problem seems to be that GitLab’s Merge Request Hook is being triggered for any change in an MR, including changing the title or the assignee. We’d like it to only trigger when the MR is created or new commits are pushed to its source branch, just like we had with Bitbucket.
For now we’ve already stopped assigning MRs to people, but we still get a lot of useless builds for commits that have already been built before, because of MR state changes.
I’ve read some other CI systems have had similar issues, and solved them by filtering incoming GitLab webhooks on a combination of action and some other fields. The action field in the posted JSON will contain “open” for new MRs and “update” for any updates. I think the oldrev field is only available when there were new commits, so maybe that’s something you could filter on?
If there’s any other way we can work around this problem, please let me know. We’ve thought about disabling PR triggers and only relying on push triggers, but that will also give us a lot of builds I’m afraid, and we’ll lose the connection between builds and MRs.