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.

163 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 →

    26 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...
      • John JulienJohn Julien commented  · 

        I was really surprised that this didn't work for me out of the box.

        What about executing the .gitlab-ci.yml of the target branch instead of the source branch on merge requests. That should take care of the security concern.

        That said, Travis CI will actually execute the .travis.yml of the source branch. I'm guessing their infrastructure is setup so that all jobs run in an ephemeral and jailed state, so compromise isn't as much of a concern as say a ci-runner that is installed on a system that's not going to be destroyed after the build.

      • Anonymous commented  · 

        I need this feature as well. What I'm doing at the moment is thru webhook for merge requests and build. From the MR request, I run a script that manually merges the source and main and push a temp branch to repo so CI can build it normally. The other build webhook is to monitor the temp branch's build results and then remove it from the repo. Clunky, yes but it works for now. If this will be integrated to gitlab, I'd be a very happy unicorn.

      • Nikos MavrogiannopoulosNikos 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.

      • Daniel Martí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 ZanivanLeonardo 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.

      • Anonymous commented  · 

        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 OdomTravis 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 ZupanMike 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 JacksonToby 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.

        For example:

        ```
        stages:
        - merge
        - test
        - deploy

        hotfix:
        type: merge
        script:
        - git merge origin master # Merge from master into current branch
        only:
        - HOTFIX-*
        events:
        - merge
        ```

      • 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!

      ← Previous 1

      Feedback and Knowledge Base