Skip to content
Snippets Groups Projects
New issue look: Off

Default Approvers for a merge request depend on what team a user is in

    • Open Issue created by username-removed-1191145 @JamesValleyT

    Currently, it's only possible to set a group of people as default approvers for a merge request.

    We have a setup where we have 1 master repo, and several teams of developers.

    TEAM A

    • Dev 1
    • Dev 2
    • Dev 3 (An Approver)

    TEAM B

    • Dev 4 (An Approver)
    • Dev 5 (An Approver)
    • Dev 6 (An Approver)

    Is there any kind of scheme where the default approvers for a merge request can be picked based on the requesters team?

    So if Dev 1 makes a merge request, Dev 3 is set as approver.

    And if Dev 4 makes a merge request, Dev 5 & 6 are set as approvers.

    I realise there would be a lot of details to work out, but this came up in our office and we were just wondering if anything like this has been discussed before?

    Our problem is we end up with people being assigned as approvers to a lot of merge requests they shouldn't be looking at (because it's the wrong team) and that is difficult for people to manage.

    Also, with our companies setup with multiple teams working in one repo, is there anything different we could be doing in how we use groups and approvers that would help with this problem?

    Thanks, James

    Designs

      Child items ...

      2. Activity

      • username-removed-419655
        username-removed-419655 @markglenfletcher1 ·
        Developer

        @JamesValleyT Thanks for your feedback and use case for the proposal. I don't think that this particular proposal has been submitted before, for approvers to be mapped to Merge Requests created by particular users.

        Do you think that it would be sufficient to set a pool of approvers within a group? So GroupA may contain members X,Y and Z, where Z is set to be the approver for all Merge Requests created by users X and Y?

      • username-removed-419655 added Discussion ~238305 ~1052112 feature proposal ~155976 labels

        added Discussion ~238305 ~1052112 feature proposal ~155976 labels

      • username-removed-1490616
        username-removed-1490616 @beveradb ·

        Hi @markglenfletcher, thanks for the labels. We only moved to GitLab a couple of weeks ago so we're still trying to figure out how we should be using it!

        Essentially we've got several teams of developers (usually 3-8 devs), and each team has a few people who are designated as code reviewers (e.g. more experienced).

        In an ideal world, we'd like to have GitLab set up such that when a developer creates a Merge Request, they don't need to (and preferably cannot) enter anything relating to approval. Instead, the MR would get the approvers added to it from every Group the submitter is a member of.

        Does this make sense and sound reasonable? I'd probably want us to have a similar setup for "Assignee" actually, so we could have all new MRs assigned to a single person for some teams (e.g. team lead).

        If there's any way for us to implement things like this ourselves, that would be absolutely fine too - I've googled a bit but haven't found any extension/plugin/customisation hooks or similar in GitLab?

        We've considered hacking away at /opt/gitlab/embedded/service/gitlab-rails/app/views/shared/issuable/_approvals.html.haml but don't want to create a maintainability nightmare!

        Is there any recommended way to make modifications to our own installation (at our own risk)?

        Thanks, Andrew

      • username-removed-419655
        username-removed-419655 @markglenfletcher1 ·
        Developer

        Your patches will be overridden by the omnibus package upgrades. Some admins do still continue to apply their own patches regardless. Some roll their own packages or install from source using their own fork of the project.

        Because you have a Support contact through your purchase of Enterprise Edition licenses, you can raise feature proposals through the official support channels too.

        @smcgivern Please could you take a look at this proposal?

      • username-removed-443319
        username-removed-443319 @smcgivern ·
        Contributor

        @JamesValleyT @beveradb thanks for the suggestion. Just to get it out of the way: we don't recommend making source changes at all :slight_smile:

        I think a lot of https://gitlab.com/gitlab-org/gitlab-ee/issues/965 is relevant to this request, in particular https://gitlab.com/gitlab-org/gitlab-ee/issues/965#note_20414031 and below. I'm interested if your workflow means that a file may be reviewed by one team or another team, depending on which team made the changes, or it's more of a 'this team is responsible for this part of the tree, and this other team is responsible for a different part of the tree'?

        @victorwu you might be interested here too.

      • username-removed-1191145
        username-removed-1191145 @JamesValleyT ·
        Author

        I'm interested if your workflow means that a file may be reviewed by one team or another team, depending on which team made the changes, or it's more of a 'this team is responsible for this part of the tree, and this other team is responsible for a different part of the tree'?

        The former. Our tree is shared across teams and different teams may touch the same file at different parts of that files life cycle.

        Thanks for looking into this!

      • username-removed-443319
        username-removed-443319 @smcgivern ·
        Contributor

        OK, I'll leave this to @victorwu then :slight_smile:

      • Victor Wu changed milestone to %Next 2-3 months

        changed milestone to %Next 2-3 months

      • Victor Wu
        Victor Wu @victorwu ·
        Contributor

        Thanks for the feedback @JamesValleyT . We aim to make approvals more fine-grained in the coming months. Your suggestion is definitely relevant here.

      Please register or sign in to reply