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.

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

    10 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...
      • 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