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.
-
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
-
Create new repository (outside the approvers group), initialize with README.md
-
Add the .gitlab-ci.yml attached to this support ticket to the repository
-
Invite Test Approvers 1 and Test Approvers 2 groups to the newly created repository as reporters
-
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 -
Trigger the CI/CD pipeline
-
Manually trigger “prep-job”
-
Once the job is complete, deploy job is started and waits for approvals
-
Navigate to Deployments -> Environments
a. Approve the pending deployment
b. Ask persons B and C to approve the deployment
-
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
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
