### Description I work for a large organization that requires multiple sets of people give their approval before a release is made. For a developer, this may be the developer's supervisor, the security/technical reviewer, the legal team, etc. This is similar to merge approval, and is related to #965, but with the following differences: - Release approval is for a particular commit; merges between branches are uncontrolled. - Any person in a set can give approval, but at least one person in the set must give approval before anyone in the next set sees it as a task on their list. - Releases can be given negative approval (see #761), in which case the developer has to address the issues raised by the negative approval and restart the release process. - Finally, once one person in a set approves or rejects the request, the task needs to be removed from the task list of everyone in that set. E.g., if one lawyer approves the release, then the task needs to be removed from the task list of the other lawyers. The primary use case is for large organizations that want to control what is released, or for organizations that are heavily regulated and must prove to the regulators that certain steps were taken, and in a particular order, before a release was made. By automating and controlling the release process, it will be possible for developers and their chain of command to prove to auditors and others that the necessary steps were taken before a release was made. ### Proposal Modify GitLab as follows: - Add in an 'approve for major release' and an 'approve for minor release' button that triggers the release approval process. 'Major' and 'minor' are described further in the 'Caveats/corner cases' section. - Add in chains of sets of approvers. The sets of approvers should be extracted via LDAP from an external LDAP-capable database. - All members of a set should see the approval request in their individual task lists. - Only one member of a set needs to review an approval request. - If the request is approved, it is removed as a task from the task lists of all of the members of the current set, and moved onto the task lists of all of the next set of approvers in the chain. - When the final approval is given, the release should either trigger a user-defined script, or send an email to the developer that triggered the release process to go ahead and push the release to the world. - To reject a release request, the rejector must give a reason which will be transmitted to the developer that started the release process. This gives the developer a chance to correct the problem and restart the process. If a request is rejected, then it should be removed as a task from the task lists of all approvers (current set, prior sets, next sets). - Developers should be able to track where in the chain a request is at. E.g., a developer should be able to see that the request was processed by the supervisor set and the security set, but is currently waiting on the legal set. This will give the developer a chance to talk to people in that set to see if there is anything that the developer can do to help the process along. Approvals MUST be able to be verified by external auditors. This means that the complete commit ID being approved, and the complete chain of approvers must be preserved and searchable. The commit ID prevents malicious authors from trying to substitute a different commit for the approved commit, and the complete chain prevents malicious approvers from repudiating their approval. #### Caveats/corner cases - There are cases where the same person is in multiple sets; as an example, a person might be a developer's supervisor, and a member of the legal team. In that case, it would be nice if the person could approve or reject the request once, and know that they've covered all their roles. If this is difficult to implement, then at the very least it should be possible to make the same person be a member of multiple approval sets without GitLab breaking. - We'd like to be able to time how long it takes for people to do their review tasks. This will let us know where the bottlenecks are, and add in more resources as needed to make certain areas more efficient. - My organization actually has two approval processes, 'major' and 'minor'. We need to be able to define both, and have buttons for both. Major releases require a very long approval process, and are triggered by certain business events (which are hard to encode into GitLab, and which are not a part of this proposal), and time (which is easy to encode). Basically, if there has been any work on any branch in a project, and it has been more than 1 year since the last major approval, we want to trigger the major approval process. This ensures that projects are reviewed on a regular basis, and stale projects are archived away. - A release request that isn't triggered by one of the events that cause a major release event is considered to be a minor release request, and follows a very short approval process. The underlying machinery in GitLab should be more or less the same, but use different chains of sets of approvers. Aside from that difference, everything mentioned above holds for minor releases as well. ### Links / references #761 #965 ### Feature checklist Make sure these are completed before closing the issue, with a link to the relevant commit. - [ ] [Feature assurance](https://about.gitlab.com/handbook/product/#feature-assurance) - [ ] Documentation - [ ] Added to [features.yml](https://gitlab.com/gitlab-com/www-gitlab-com/blob/master/data/features.yml)