Plugin should respond to change in MR assignment

[smithrs]

I have the following use case:

My manager wants to stop all developers for pushing to master, period, All work should be done on branches and use Merge Requests.

Gitlab does not support this use case. If you can't push to master, you also can't accept a MR that would push to master on acceptance (https://gitlab.com/gitlab-org/gitlab-ce/issues/967 and https://gitlab.com/gitlab-org/gitlab-ce/issues/1374).

I have a novel solution to this. If a developer could assign the MR to the Jenkins user, that would fire a web hook that Jenkins could respond to. A Jenkins job could validate the MR using whatever criteria we choose (upvotes, tests passing, etc).

The problem is that the plugin doesn't catch this. There have been prior issues that have raised this question in other ways (#144 for example). It comes down to this: I want to be able to catch all MR webhook events, including updates.

I'm not really a Java guy, but I can certainly look at the code and see what's going on. I see several pull requests that seem to address this issue, and hacking into the code for GitLabWebHook.java as it currently stands seems counterproductive, it's being refactored, right?

I'm open to suggestions and happy to help out. Thanks.

[demaniak]

I have the following setup:

• "jenkins" user on GitLab
• gitlab "jenkins" user API token utilized in jenkins gitlab config
• use webhooks in gitlab to trigger builds in jenkins (MR events)
• gitlab plugin setup in jenkins with additional behaviours to merge before build
• when/if build passes (automated tests, quality checks etc), I enabled the Accept merge request on success function of the GitLab plugin

No dev directly pushes to master.
All code that comes into master passed the automated tests.

[omehegan]

@smithrs I think @demaniak's answer should work for you. Let me know if not. Also, the major refactor work of the plugin is done now, so if you wanted to look at making changes, forking the master branch would be a fine place to start.

[demaniak]

@smithrs just to add to that - a MR does not HAVE to go to master directly. If your workflow requires, then you could (for example) have MR's going into a "release branch" or something like that.

Everything should still work fine as explained above.

[smithrs]

The core issue is that an MR update event sends one webhook (expressed as a json object), and a branch push sends another webhook (a different object). Sometimes I want to respond to one, sometimes to the other, and other times I want to handle both in the same job. My question is in regard to how this granularity is addressed. 1.1.32 has a certain way of doing this, 1.2 seems different, but the whole thing appears to be in flux.

I'm fine with letting this issue be closed and then revisiting it after the refactoring is done.

Thanks for all the help.