Allow choosing different types of events (other than "push") to trigger build through TeamCity CI integration

Problem to solve

The TeamCity CI plugin/integration is triggering way more builds than required for our usage scenario, since it is hooked to the "push" event as opposed to the "merge request" event.

Further details

We have a repository that includes around 100 members, each potentially working on and over multiple personal/feature branches. We rely on TeamCity's CI/CD set-up until we eventually transition to GitLab runners. The main behavior we are looking to have is merge requests that are "gated" on successful builds from TeamCity, hence our usage of GitLab's TeamCity CI integration/plugin.

In the meantime though, we are stuck with no control over the amount of builds that get triggered through the integration/plugin, since it fires-off a build on every single push to any branch within the repo. This basically floods our build grid with unnecessary and unwanted builds, which made us stop using the integration entirely. We still get the behavior we want (i.e. gated merge requests) through the use of the "commit status publisher" TeamCity-side plugin, which signals the status of a build to GitLab, but the devs now have to manually launch the builds for their merge requests. This is tedious and far from ideal, but, again, it's better than having useless builds triggered on every push, when what we want is to have them triggered on a MR creation/update.

Proposal

We propose to modify GitLab's TeamCity CI/CD integration to allow the selection of the event(s) that will trigger a build. The set of available options would of course include the current, implicit option ("push"), but could also now include the "merge request" event type. The options do not have to be mutually exclusive, and could be presented as separate combo boxes.

We have no determinate use cases for other types of event, but it would be interesting to consider them as well.