Merge requests should trigger a build on the main project
When you create a merge request it should trigger a build on the main project + the merge request changes and show build status on the merge request page.
Nikos Mavrogiannopoulos commented
Note that docker is not really a reliable security mechanism and triggering builds from unknown merge requests is dangerous. If done automatically please allow an opt-out for projects and possibly an option to run the builds after an initial review.
Nikolaus Demmel commented
This is really missing to make gitlab CI be a proper replacement for Jenkins + https://github.com/timols/jenkins-gitlab-merge-request-builder-plugin
Daniel Martí commented
I also need this badly. Mostly because I want our dedicated runner to also run merge requests, instead of relying on the source repo's setup of CI (which usually involves laggy public runners).
Leonardo Loch Zanivan commented
Most of the users work with GitLab internally, so I think we'll not have any security issues.
Even though, we use docker for runners, it's quite secure to run anything.
That is one big flaw in the whole CI integration.
Our team is also working on feature or hotfix branches and they get merged into the master with merge requests.
I don't need gitlab to tell me that the source branch compiles nor do I want to know if master currently compiles. I want to know if the merge result will compile. That is what I except to see on the merge request details page. This can even only be triggered if a merge is possible in general!
Travis Odom commented
We have an issue with our continuous delivery setup and forks that this would resolve. We set up our project to do a deploy to a testing environment on commits to master, which equates for us to a merge request being accepted.
However, with the change to .gitlab-ci.yml, this how ALSO happens whenever one of us updates 'master' on our fork.
Ideally, we could have CI turned off for our forks, and still be notified of any build issues in the merge result.
Mike Zupan commented
For me this is a big killer. I agree public facing its a bad idea but we have an internal server where all dev work is done off feature branches and always running jobs just creates a lot of noise per commit.
Toby Jackson commented
The new gitlab-ci yaml configuration includes 'stages' - previously 'types' - could there be a mechanism through the stages behaviour which includes an indicator that a given build request is a merger and therefore additional steps are required... this would A) help mitigate the security risk identified by Nigel - just don't include that step but B) allows those users who want automated builds indicating the status post-build.
- git merge origin master # Merge from master into current branch
Greg Smethells commented
Currently a GitLab CI runner is started for every commit which can be a bit much. I think an option to have a runner started for either Merge Requests, every commit, or both is a more flexible offering.
I completely agree Yves. I was also surprised to find that Gitlab CI worked this way for merge requests. Our pipeline is to work on dev branches, submit merge/pull requests which then get merged into master. It's completely useless to build the dev branch without merging it first, because once the merge takes place, it's quite nasty to try to resolve any errors that occur, which the build would not have caught.
In Jenkins there's a behavior which can be enabled for a project, which forces it to merge into master before building. Is there a way to simulate this in Gitlab CI? I was thinking of adding in a "git merge master" command to the build config yaml file, which should simulate this. However this will create problems if the master branch itself needs to be built, as you're merging a branch into itself.
Another workaround might be to write a shell script that takes care of all this, include it in the projects and call it from the pre-build script in the yaml file.
Ideas? As it stands, we'd probably just use Jenkins, as this merge request build is the most important feature we need in a CI tool.
Yves Goergen commented
Now this has really surprised me. On a merge request page, I believe I see information about the merge, not just its source. GitLab CI currently tells me that the build is passing. It does so on the merge request page. Hence I assume that the merge will build. After all, what for do I need a merge request tracking system? When I accept the merge and then the build will fail, the "build passing" info was misleading and useless. It should *always* say something about the merge result. (Like I hope it will tell me of conflicts, never had those yet.) I want to know whether the build will be successful after I accept the merge, before it's too late and the master branch needs immediate repair.
You said that it's not doable for most companies to have so many builds triggered. Well, there's at least one where it's fine and expected. Our builds are still quick enough (seconds to a few minutes) and commits to the merge target (master) don't happen every moment. People are working on feature branches which will be merged into master. Commits to master are rare. And then I need an updated info about the build status for the next branch to be merged. (If the merge target has changed and the new build isn't finished yet, I'd like to know that I have to wait a little. And of course, if there are merge conflicts, the build should not even start.)
I don't need GitLab CI to tell me whether master is currently building. I know that already. It's supposed to build at all times. I need it to tell me whether it will still be building after a merge. I know the present, tell me the future! :-)
Laas Toom commented
I second the idea that this should be configurable and default behaviour for Private and perhaps for Internal projects too.
Lack of this keeps us from switching to Fork-MR-flow.
Is here anything happening? It's a common pattern with GitHub & Travis CI to build cross project merge requests. It should be up to the runner/admin to ensure that the build setups are safe against malicous attacks. Even more, it would be easy to make this feature optional and leave the decision to the admin to support it on a per-project basis.
ישראל פרוכטר commented
This is exactly the the feature we are looking for, question is if this can be integrated with other CI systems ? (We are not using gitlab CI)
Jake Willoughby commented
Perhaps the Merge Request page could display something like:
"Automatic Build suppressed for security reasons, press here to trigger it anyway."
For a public facing gitlab with public repos this could be a problem, however Travis CI integrates with GitHub and does this on public repos, I'm not sure how they protect against the potential problem.
I'd suggest something like enable by default for all projects except public repos, and let it be a configurable option on public.
Aren't most people using gitlab for private purposes? I'd think the trust of a developer would already exist in those environments.
AdminGitLab team (Admin, Gitlab) commented
Hi Erik, thanks for the clarification, but what do you think about the problem Nigel raised? If someone submits a merge request and injects malicious code in say a Makefile, it could gain access to the system or container used to do the CI build.
Sorry, let me try and rephrase.
Currently if you work on a feature branch and you create a merge request to master it will trigger a build and show the build status of the merge request on the merge request overview page.
I'm suggestion the same happen when a merge request is created from a fork.
The teams Ive worked with and I would argue the defacto standard these days is to develop in forks.
Hopefully that makes more sense. I'm definitely not suggesting it trigger a build on all branches just a build based on the merge request.
Make sense? Thanks!
AdminGitLab team (Admin, Gitlab) commented
As it stands now, each commit triggers a GitLab CI build on master anyways so what you say does not make sense.
A builds is trigged on a commits to master and on a commit to a branch, but currently one commit to master does not trigger builds for all branches.
Teams of people don't work on feature branches in my experience, they work on forks, and then merge those changes from the fork to the parent. You should want a build to be run on the merge request.
People work both on feature branches and forks.
GitLab triggers Gitlab CI builds on merge requests between branches in the same project, whats the difference here?
As I understand it you propose runner a build on the main project + the merge request changes (so the result of the merge) instead of on the merge request itself.
Maybe you mean something else please elaborate.
+1 to configurable, although you should be using throw away build systems, like docker containers, or virtual machines that are jailed to be honest.
Most people I'd imagine use GitLab for internal private projects, I'd hope you'd trust the members of your team that are creating merge requests. I definitely agree from a public standpoint you'd want to make sure someone can't do something malicious.