Multiple approvers for protected environments get grouped for one rule resulting in blocking deployments

Summary

With multiple approval rules configured for a protected environment, with common users in those rules, and according to the order or approvals, the approvers would end up grouped at one or two rules and leaving the rest unmet. This keeps the deployment in the state of waiting for approval forever.

The issue was reported in ticket (Internal Link)

Steps to reproduce

Assume that you’re Person A.

  1. Create two sub-groups for approvers under Approvers group

    a. Test Approvers 1, invite Person B as Reporter to the group

    b. Test Approvers 2, invite Person C as Reporter to the group

  2. Create new repository (outside the approvers group), initialize with README.md

  3. Add the .gitlab-ci.yml attached to this support ticket to the repository

  4. Invite Test Approvers 1 and Test Approvers 2 groups to the newly created repository as reporters

  5. Navigate to Settings -> CI/CD -> Protected environments

    a. Configure production as protected environment

    b. Add following rules

    i. Allowed to deploy: Person A
    
    ii. Allowed to approve:
    
        a. Rule 1: Person A
    
        b. Rule 2: Test Approvers 1, 1 approval required
    
        c. Rule 3: Test Approvers 2, 1 approval required
  6. Trigger the CI/CD pipeline

  7. Manually trigger “prep-job”

  8. Once the job is complete, deploy job is started and waits for approvals

  9. Navigate to Deployments -> Environments

    a. Approve the pending deployment

    b. Ask persons B and C to approve the deployment

  10. Observe all approvals grouped under the Rule 1

What is the current bug behavior?

Approvers get grouped at one or two rules, making the rest of rules unmet, and hence the deployment is blocked

What is the expected correct behavior?

Approvers are assigned correctly and considering when a user can satisfy more than one rule, so that it would be assigned to the unmet rule.

Relevant logs and/or screenshots

Screenshot_2023-09-08_at_1.52.35_PM

Output of checks

This was reproduced on 15.8, 15.11, and 16.0.8

Results of GitLab environment info

Expand for output related to GitLab environment info

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check

(For installations with omnibus-gitlab package run and paste the output of: sudo gitlab-rake gitlab:check SANITIZE=true)

(For installations from source run and paste the output of: sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)

(we will only investigate if the tests are passing)

Proposed fix

User should be able to approve specifically for any group they belong to.

They should be able to approve only once for each group they belong to.

First iteration, they can approve one at a time.

Initially, we need to support this in the backend and GraphQL so there's a work around, and to support frontend work.

Implementation Summary

  • Initial backend work to resolve the bug by enabling User to approve as each group they belong to that should be able to approve.
  • Related backend work needs to provide a list of groups a user can approve the relevant deployment for via graphql.
  • Frontend work is blocked by the backend work and needs to implement a checkbox where the user can choose which group to approve as.

Implementation details

Backend MRs

  • Database: Add migration to update deployment_approvals index (!145716 - merged)
  • Model: Include approval_rule_id in uniqueness scope (!145401 - merged)
  • Service: Allow user to approve for more than one group (!146673 - merged)
  • GraphQL: Add canApprove field to ApprovalRuleForSummaryType (!148033 - merged)

Frontend

After discussing with frontend team this is not currently possible and needs some backend support which has been added as a new blocking issue.

The front end will need a way to show which groups the user can approve for, scoped to this deployment's environment (or maybe it's project, need to check).

Once that is supported, the frontend can add a checkbox where the user can choose which group to approve as.

Frontend MR: Allow users to select which group to approve as (!150033 - merged)

Future improvements

The discussion for future improvements is here: #457541

Edited Apr 23, 2024 by Hunter Stewart
Assignee Loading
Time tracking Loading