Steps to reproduce
- Connect a bitrise project to a gitlab instance.
- Set bitrise up so that it builds new merge requests.
- Create a merge request in gitlab.
- Observe that bitrise builds as expected.
- Change the assignee.
- Observe that bitrise builds again.
Right now bitrise cannot distinguish between a real code change to a merge request and a meta data change.
@viktorbenei already said that this might be due to gitlab’s webhook not sending any information what exactly changed in a PR thus leaving bitrise blind meaning that bitrise will build every time the webhook is triggered as it MIGHT be caused by code changes.
First step would likely be to check what information exactly the gitlab webhook exposes.
If the webhook doesn’t provide the information needed bitrise would likely have to query gitlab for changes to the git branch as soon as the webhook is triggered. If the tip of the branch has already been build no new build needs to be triggered.
Improving this could dramatically decrease the number of builds for all gitlab users.