Trigger master pipeline jobs from merge request labels



I wonder what people are using to trigger specific jobs in the master pipeline depending on what has been said / tagged in the merge request.

The ideal scenario I wan’t to achieve is to trigger a major / minor release depending if that label has been added in the merge request. i.e during the discussion of a library release we see that we break interfaces, thus we add the label: major.

This will in turn run the standard pipeline in the master branch when we merge it to master. Issue is that instead of bumping the patch version (read semver). We will bump the major version depending on what discussion was had in the merge request.

I have managed this by adding custom tagging in the title of the merge request like Change api for X [cd-major]. Then in the master branch I have a only trigger like:

    - master
    - $CI_COMMIT_MESSAGE =~ /\[cd-major\]/

Problem with this is the edit of the title and remembering this, as well as having to rely that the commit message is not overwritten for some reason. So the current solution is flaky, and being able to trigger on merge request labels would give alot of freedom. Partly to create static ones, but also to add env:prod and env:test to tell the deployment branch that I wan’t this merge request to be deployed to the test and prod environment as well as an example.

Would love to hear how other people does this as well so I can find a more stable way than using the CI_COMMIT_MESSAGE variable.


I’d love to see this, as more and more Github Projects (Like the official Helm Repository), is using this mechanism. Also you could choose, that for branches only the according E2E tests should be run, which could be set by the reviewer and finally when everything is done, you could run once with all tests.


Created an issue to see if we can get the feature implemented: