I suggest you ...

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.

87 votes
Vote
Sign in
Check!
(thinking…)
Reset
or sign in with
  • facebook
  • google
    Password icon
    I agree to the terms of service
    Signed in as (Sign out)
    You have left! (?) (thinking…)
    ErikErik shared this idea  ·   ·  Admin →

    16 comments

    Sign in
    Check!
    (thinking…)
    Reset
    or sign in with
    • facebook
    • google
      Password icon
      I agree to the terms of service
      Signed in as (Sign out)
      Submitting...
      • Greg SmethellsGreg 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.

      • Anonymous commented  · 

        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 GoergenYves 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 ToomLaas 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.

      • OliOli commented  · 

        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 WilloughbyJake Willoughby commented  · 

        Perhaps the Merge Request page could display something like:

        "Automatic Build suppressed for security reasons, press here to trigger it anyway."

      • ErikErik commented  · 

        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.

      • GitLab teamAdminGitLab 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.

      • ErikErik commented  · 

        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!

      • GitLab teamAdminGitLab 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.

      • ErikErik commented  · 

        +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.

      • Nigel KukardNigel Kukard commented  · 

        I really like this idea, but please make it configurable.

        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.

        I really don't want this to happen for a few projects, but most of them would be EXTREMELY useful!

      • ErikErik commented  · 

        Also look at how Travis CI integration with GitHub works. All pull requests whether between branches or between forks trigger builds if the projects are setup for CI integration with Travis.

        GitLab should do the same, especially on merge requests!

      • ErikErik commented  · 

        As it stands now, each commit triggers a GitLab CI build on master anyways so what you say does not make sense.

        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.

        GitLab triggers Gitlab CI builds on merge requests between branches in the same project, whats the difference here?

      Feedback and Knowledge Base