Open Jellby opened 6 years ago
The tricky part would be detecting if a MR pipeline has already been triggered. In case of misconfiguration, a trigger may fail to create the desired jobs, in which case a naïve implementation (trigger if jobs do not exist, wait and repeat) would result in infinite triggers. The origin of a pipeline is passed as a CI variable (CI_PIPELINE_SOURCE
) but it does not seem to be available in the API. Maybe Marge could leave a message in the discussion saying "I triggered a pipeline for [sha]", and check existing messages before triggering a pipeline? Or maybe it's just better to use some other service to trigger pipelines for MRs until it's properly implemented in GitLab (see https://github.com/shyiko/gitlab-ci-build-on-merge-request).
This has been overtaken by the new rules for GitLab CI which includes support for MR pipelines, so maybe needs a re-think?
Triggering pipelines for MRs is no longer an issue (for me). But working with forks, or ensuring the pipeline is of the right type still is.
That's very useful, thanks. I work with forks so rarely I forget that they are quite different in GitLab.
Since GitLab does not support pipeline for merge requests yet (see https://gitlab.com/gitlab-org/gitlab-ce/issues/23902), can marge-bot take care of it?
I'd like her to:
The reason is that for expensive tests one may not want to run them for every push to every branch, but they must be run on a MR if it's going to go into
master
. The CI configuration could be set up to run these tests only for, say,triggers
andweb
, but can't enforce them to run on MRs. A possibility is running the test for some specially-named branches by setting a branch regexp for the CI, and require MRs to use these names, but that needs some discipline which is hard to find (although marge-bot could help here too).