<!--This issue template can be used as a great starting point for feature requests. The section "Release notes" can be used as a summary of the feature and is also required if you want to have your release post blog MR auto generated using the release post item generator: https://about.gitlab.com/handbook/marketing/blog/release-posts/#release-post-item-generator. The remaining sections are the backbone for every feature in GitLab. The goal of this template is brevity for quick/smaller iterations. For a more thorough list of considerations for larger features or feature sets, you can leverage the detailed [feature proposal](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/issue_templates/Feature%20proposal%20-%20detailed.md).--> ### Release notes <!--What is the problem and solution you're proposing? This content sets the overall vision for the feature and serves as the release notes that will populate in various places, including the [release post blog](https://about.gitlab.com/releases/categories/releases/) and [Gitlab project releases](https://gitlab.com/gitlab-org/gitlab/-/releases). "--> ### Problem to solve As a Release Manager, I want to make sure that no job can access the systems I control without the necessary approvals. The `environment.action` CI attribute has 5 valid values: - start (default) - stop - prepare - access - verify We learned that `prepare/access/verify` are identical in terms of behaviour. At the same time, there are various requests asking for different behaviour in different use cases. We want to provide the following setup: | require approval \\ reset timer | :x: reset timer | :white_check_mark: reset timer | |---------------------------------|-----------------|--------------------------------| | :x: approval | `verify` | `access` | | :white_check_mark: approval | :question: | `prepare` | ### Proposal <!--Use this section to explain the feature and how it will work. It can be helpful to add technical details, design proposals, and links to related epics or issues.--> Change the logic of `prepare` so that it will require the same approvals as `start`. There should be no need to approve both `start` and `prepare` separately. Approving either one should allow both. As approvals are a ~"GitLab Premium" feature, `prepare` would be available in ~"GitLab Premium" only. This does not mean that we are changing its tier, as the same functionality will remain in ~"GitLab Free" with `environment.action: access`. ### Design proposal  #### Implementation plan ~backend 1. Modify `ProtectedEnvironments::ApprovalRule` database table. Remove `NOT NULL` on `deployment_id` and add a new column to link the job (with relevant indexes/constraints). And update `Deployments::Approval` model. (See https://gitlab.com/gitlab-org/gitlab/-/issues/437132#note_2389658760) 2. Update `prepare` jobs to require approvals, same as `start` jobs. 3. Fill in the deployment ID once it is created. 4. Mark the job to be approved once either `start` or `prepare` job was approved. 5. Return a list of jobs that need an approval through GraphQL for frontend use. We would need to add a new GraphQL query for this, and it could be tricky. (See https://gitlab.com/gitlab-org/gitlab/-/issues/437132#note_2391683450) ~frontend 1. Create a new tab - "Pending approvals" on the environment show page 2. Use the new resolver to get data 3. Render the data similarly to how it's done on the "Deployment history" tab ### Intended users * [Rachel (Release Manager)](https://about.gitlab.com/handbook/product/personas/#rachel-release-manager) ### Feature Usage Metrics - MAU of `environment.action: prepare` jobs ### Does this feature require an audit event? <!--- Checkout these docs to know more https://docs.gitlab.com/ee/development/audit_event_guide/#what-are-audit-events https://docs.gitlab.com/ee/administration/audit_events.html ---> <!--Label reminders Use the following resources to find the appropriate labels: - Use only one tier label choosing the lowest tier this is intended for - https://gitlab.com/gitlab-org/gitlab/-/labels - https://about.gitlab.com/handbook/product/categories/features/--> <!--triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION--> _This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc._ <!--triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION--> <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->