- [ ] [Add additional acceptance criteria as necessary.]
-->
## Technical Requirements
<!-- [List any technical requirements for this maintenance issue.] -->
## Impact Assessment
<!-- [Describe the impact of this maintenance issue on the user experience and/or the product as a whole.] -->
## Steps to Reproduce
<!-- [Provide detailed steps on how to reproduce the maintenance issue.] -->
## Expected Results
<!-- [Describe the expected outcome when the maintenance issue is resolved.] -->
## Actual Results
<!-- [Describe the current outcome of the maintenance issue.] -->
/label ~type::maintenance
/label ~"Category:Consumables Cost Management"
/label ~"group::utilization"
/label ~"section::fulfillment"
<details>
<summary>Illustrative Description: (This is not an actual maintenance issue, but rather a sample report that demonstrates how a maintenance issue could be presented) </summary>
## Description
The login page is taking longer than expected to load, which is impacting the user experience.
## Acceptance Criteria
- [ ] The login page should load in less than 3 seconds on both desktop and mobile devices.
- [ ] The login page should be tested on different browsers to ensure compatibility.
- [ ] The login page should not display any errors or warnings in the console.
## Technical Requirements
- [ ] The login page should be optimized for performance.
- [ ] The login page should be tested on different browsers.
- [ ] The login page should be updated to use the latest version of the authentication library.
## Impact Assessment
This maintenance issue is impacting the user experience by causing delays in the login process. By resolving this issue, users will be able to log in faster and have a better overall experience.
## Steps to Reproduce
1. Open the login page.
1. Wait for the page to load.
1. Measure the time it takes for the page to fully load.
## Expected Results
The login page should load in less than 3 seconds on both desktop and mobile devices.
## Actual Results
The login page is currently taking more than 5 seconds to load on desktop devices and more than 7 seconds on mobile devices. This is causing frustration and delays for users.
As a [user or stakeholder], I want [goal or objective] so that [reason or benefit].
[Provide any additional description here.]
## Acceptance Criteria
TODO: Fill out (required)
- [ ] [Describe what must be achieved to complete this issue.]
- [ ] [Describe another requirement needed to complete this issue.]
- [ ] [Add additional acceptance criteria as needed.]
## Technical Requirements
TODO: Fill out or delete (optional)
[If applicable, please list out any technical requirements for this feature/enhancement.]
## Design Requirements
TODO: Fill out or delete (optional)
[If applicable, please provide a link to the design specifications for this feature/enhancement.]
## Impact Assessment
TODO: Fill out or delete (optional)
[Please describe the impact this feature/enhancement will have on the user experience and/or the product as a whole.]
## User Story
TODO: Fill out or delete (optional)
[Provide a user story to illustrate the use case for this feature/enhancement. Include examples to help communicate the intended functionality.]
/label ~"Category:Web IDE"
/label ~"section::dev"
/label ~"devops::create"
/label ~"group::ide"
<!-- Replace with other type, e.g. bug or maintenance, if appropriate -->
/label ~"type::feature"
<!-- Replace with other subtype if appropriate -->
/label ~"feature::addition"
<!-- By default, all issues start in the unprioritized status. See https://about.gitlab.com/handbook/engineering/development/dev/create/ide/#-remote-development-planning-process -->
/label ~"rd-workflow::unprioritized"
<!-- For simplicity and to avoid triage bot warnings about missing workflow labels, we will default to issues starting at the refinement phase -->
**Please note:** if the incident relates to sensitive data or is security-related, consider
labeling this issue with ~security and mark it confidential, or create it in a private repository.
There is now a separate internal-only RCA template for SIRT issues referenced https://about.gitlab.com/handbook/security/root-cause-analysis.html
***
## Summary
A brief summary of what happened. Try to make it as executive-friendly as possible.
- Service(s) affected:
- Team attribution:
- Minutes downtime or degradation:
## Impact & Metrics
Start with the following:
| Question | Answer |
| ----- | ----- |
| What was the impact? | (i.e. service outage, sub-service brown-out, exposure of sensitive data, ...) |
| Who was impacted? | (i.e. external customers, internal customers, specific teams, ...) |
| How did this impact customers? | (i.e. preventing them from doing X, incorrect display of Y, ...) |
| How many attempts made to access? | |
| How many customers affected? | |
| How many customers tried to access? | |
Include any additional metrics that are of relevance.
Provide any relevant graphs that could help understand the impact of the incident and its dynamics.
## Detection & Response
Start with the following:
| Question | Answer |
| ----- | ----- |
| When was the incident detected? | YYYY-MM-DD UTC |
| How was the incident detected? | (i.e. DELKE, H1 Report, ...) |
| Did alarming work as expected? | |
| How long did it take from the start of the incident to its detection? | |
| How long did it take from detection to remediation? | |
| What steps were taken to remediate? | |
| Were there any issues with the response? | (i.e. bastion host used to access the service was not available, relevant team member wasn't page-able, ...) |
## MR Checklist
Consider these questions if a code change introduced the issue.
| Question | Answer |
| ----- | ----- |
| Was the [MR acceptance checklist](https://docs.gitlab.com/ee/development/code_review.html#acceptance-checklist) marked as reviewed in the MR? | |
| Should the checklist be updated to help reduce chances of future recurrences? If so, who is the DRI to do so? | |
## Timeline
YYYY-MM-DD
- 00:00 UTC - something happened
- 00:01 UTC - something else happened
- ...
YYYY-MM-DD+1
- 00:00 UTC - and then this happened
- 00:01 UTC - and more happened
- ...
## Root Cause Analysis
The purpose of this document is to understand the reasons that caused an incident, and to create mechanisms to prevent it from recurring in the future. A root cause can **never be a person**, the way of writing has to refer to the system and the context rather than the specific actors.
Follow the "**5 whys**" in a **blameless** manner as the core of the root cause analysis.
For this, it is necessary to start with the incident and question why it happened. Keep iterating asking "why?" 5 times. While it's not a hard rule that it has to be 5 times, it helps to keep questions get deeper in finding the actual root cause.
Keep in mind that from one "why?" there may come more than one answer, consider following the different branches.
### Example of the usage of "5 whys"
The vehicle will not start. (the problem)
1. Why? - The battery is dead.
2. Why? - The alternator is not functioning.
3. Why? - The alternator belt has broken.
4. Why? - The alternator belt was well beyond its useful service life and not replaced.
5. Why? - The vehicle was not maintained according to the recommended service schedule. (Fifth why, a root cause)
## What went well
Start with the following:
- Identify the things that worked well or as expected.
- Any additional call-outs for what went particularly well.
## What can be improved
Start with the following:
- Using the root cause analysis, explain what can be improved to prevent this from happening again.
- Is there anything that could have been done to improve the detection or time to detection?
- Is there anything that could have been done to improve the response or time to response?
- Is there an existing issue that would have either prevented this incident or reduced the impact?
- Did we have any indication or beforehand knowledge that this incident might take place?
- Was the [MR acceptance checklist](https://docs.gitlab.com/ee/development/code_review.html#acceptance-checklist) marked as reviewed in the MR?
- Should the checklist be updated to help reduce chances of future recurrences?
## Corrective actions
- List issues that have been created as corrective actions from this incident.
- For each issue, include the following:
-`<Bare issue link>` - Issue labeled as ~"corrective action".
- An estimated date of completion of the corrective action.
- The named individual who owns the delivery of the corrective action.
| Who was impacted? | (i.e. customers with specific environment configurations or data ...) |
| How many customers affected? | |
Include any additional metrics that are of relevance.
## Detection & Response
Start with the following:
| Question | Answer |
| ----- | ----- |
| When was the issue detected? | YYYY-MM-DD |
| How was the issue detected? | (i.e. Support request, Bug raised, ...) |
| How long did it take from the start of the issue to its detection? | |
| How long did it take from detection to remediation? | |
| What steps were taken to remediate? | |
| Was patch release created? | |
| Was patch backported to older versions? | |
## Timeline
YYYY-MM-DD
- something happened
- something else happened
- ...
YYYY-MM-DD+1
- and then this happened
- and more happened
- ...
## Root Cause Analysis
The purpose of this document is to understand the reasons that caused an issue, and to create mechanisms to prevent it from recurring in the future. A root cause can **never be a person**, the way of writing has to refer to the system and the context rather than the specific actors.
### What is causing upgrade error
Start with the following:
- What is the cause of the upgrade error?
- What steps could be done to reproduce the upgrade error?
### What can be improved
DRI: Corresponding Engineering team
- Using the root cause analysis, explain what can be improved to prevent this from happening again.
- What changes to our tooling or review process would have prevented this issue?
- Is there an existing issue that would have either prevented this issue or reduced the impact?
- Did we have any indication or beforehand knowledge that this issue might take place?
DRI: Test Platform
- What is the cause of the test gap on integration and system level testing?
- What can be done to increase test coverage?
- Did relevant tests pass for this upgrade path?
## Corrective actions
- Link issues that have been created as corrective actions from this issue.
- For each issue, include the following:
-`<Issue link>` - Issue labeled as ~"corrective action" ~upgrades.
- An estimated date of completion of the corrective action. Priority of the issue should correspond with RCA severity.
<!-- Set the correct label and milestone using autocomplete for guidance. Please @mention only the DRI(s) for each stage or group rather than an entire department. -->
**Be sure to link this MR to the relevant deprecation issue(s).**
- Deprecation Issue:
If there is no relevant deprecation issue, hit pause and:
- Review the [process for deprecating and removing features](https://handbook.gitlab.com/handbook/product/gitlab-the-product/#process-for-deprecating-and-removing-a-feature).
- Connect with the Product Manager DRI.
Deprecation announcements can and should be created and merged into Docs at any time, to optimize user awareness and planning. We encourage confirmed deprecations to be merged as soon as the required reviews are complete, even if weeks ahead of the target milestone's release post. For the announcement to be included in a specific release post and that release's documentation packages, this MR must be reviewed/merged per the due dates below:
**10 days (Monday) before the Release Date**: Assign this MR to these team members as Reviewer and for Approval (optional unless noted as required):
- Product Marketing: `@PMM`
- Product Designer(s): `@ProductDesigners`
- Product Group Manager or Director: `@PM` - Required
- Engineering Manager: `@EM` - Required
- Technical writer: `@TW` - Required
**By 11:59 AM PDT 8 days (Wednesday) before the Release Date**: EM/PM assigns this MR to the TW reviewer for final review and merge: `@EM/PM`
**By 11:59 PM PDT 6 days (Friday) before the Release Date**: TW Reviewer updates Docs by merging this MR to `master`: `@TW`
---
Please review:
- The definitions of ["Deprecation", "End of Support", and "Removal"](https://docs.gitlab.com/ee/development/deprecation_guidelines/).
- The [guidelines for deprecations](https://handbook.gitlab.com/handbook/marketing/blog/release-posts/#deprecations-removals-and-breaking-changes).
- The process for [creating a deprecation announcement](https://handbook.gitlab.com/handbook/marketing/blog/release-posts/#creating-the-announcement).
They are frequently updated, and everyone should make sure they are aware of the current standards (PM, PMM, EM, and TW).
## EM/PM release post item checklist
- [ ] Set yourself as the Assignee, meaning you are the DRI.
-[ ] If the deprecation is a [breaking change](https://handbook.gitlab.com/handbook/product/gitlab-the-product/#breaking-changes), add label `breaking change`.
- [ ] Confirm this MR is labeled ~"release post item::deprecation"
-[ ] Follow the process to [create a deprecation YAML file](https://handbook.gitlab.com/handbook/marketing/blog/release-posts/#creating-the-announcement).
- [ ] Add reviewers by the 10th.
- [ ] Add scoped `devops::` and `group::` labels as necessary.
- [ ] Add the appropriate milestone to this MR.
- [ ] If the changes modify log format(addition/deletion/modification) of product feature, tag `@gitlab-com/gl-security/engineering-and-research/security-logging` team over the GitLab issue/MR.
- [ ] When ready to be merged (and no later than the 15th) `@mention` the TW for final review and merge.
## Reviewers
When the content is ready for review, it must be reviewed by a Technical Writer and Engineering Manager, but can also be reviewed by
Product Marketing, Product Design, and the Product Leaders for this area. Please use the
feature for all reviews. Reviewers will then approve the MR and remove themselves from Reviewers when their review is complete.
- [ ] (Recommended) PMM
- [ ] (Optional) Product Designer
- [ ] (Optional) Group Manager or Director
-[ ] Required review and approval: [Technical Writer designated to the corresponding DevOps stage/group](https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments).
### Tech writer review
After being added as a Reviewer to this merge request, the TW performs their review
according to the criteria described below.
Review deprecation MRs with a similar process as regular docs MRs. Add suggestions
as needed, @ message the PM to inform them the first review is complete, and remove
yourself as a reviewer if it's not ready for merge yet.
<details>
<summary>Expand for Details</summary>
- [ ] Title:
- Length limit: 7 words (not including articles or prepositions).
- Capitalization: ensure the title is [sentence cased](https://design.gitlab.com/content/punctuation#case).
- [ ] Consistency:
- Ensure that all resources (docs, deprecation, etc.) refer to the feature with the same term / feature name.
- [ ] Content:
- Make sure the deprecation is accurate based on your understanding. Look for typos or grammar mistakes. Work with PM and PMM to ensure a consistent GitLab style and tone for messaging, based on other features and deprecations.
- Review use of whitespace and bullet lists. Will the deprecation item be easily scannable when published? Consider adding line breaks or breaking content into bullets if you have more than a few sentences.
- Make sure there aren't acronyms readers may not understand per [our Writing style guidelines](https://handbook.gitlab.com/handbook/communication/#writing-style-guidelines).
- [ ] Links:
- All links must be full URLs, as the deprecation YAML files are used in two different projects. Do not use relative links. The generated doc is an exception to the relative link rule and currently uses absolute links only.
- Make sure all links and anchors are correct. Do not link to the H1 (top) anchor on a docs page.
- [ ] Code. Make sure any included code is wrapped in code blocks.
-[ ] Capitalization. Make sure to capitalize feature names. Stay consistent with the Documentation Style Guidance on [Capitalization](https://docs.gitlab.com/ee/development/documentation/styleguide/index.html#capitalization).
- [ ] Blank spaces. Remove unnecessary spaces (end of line spaces, double spaces, extra blank lines, and lines with only spaces).
</details>
When the PM indicates it is ready for merge and all issues have been addressed, start the merge process.
#### Technical writer merge process
The [deprecations doc's `.md` file](https://gitlab.com/gitlab-org/gitlab/blob/master/doc/update/deprecations.md)
must be updated before this MR is merged:
1. Check out the MR's branch (in the [`gitlab-org/gitlab`](https://gitlab.com/gitlab-org/gitlab) project).
1. From the command line (in the branch), run `bin/rake gitlab:docs:compile_deprecations`.
If you want to double check that it worked, you can run `bin/rake gitlab:docs:check_deprecations`
to verify that the doc is up to date.
1. Commit the updated file and push the changes.
1. Set the merge request to auto-merge, or if the pipeline is already complete, merge.
If you have trouble running the Rake task, check the [troubleshooting steps](https://handbook.gitlab.com/handbook/marketing/blog/release-posts/#deprecation-rake-task-troubleshooting).
/label ~"release post" ~"release post item" ~"Technical Writing" ~"release post item::deprecation"
<!-- Use this template for documentation updates in the /doc/solutions directory. -->
This MR Template ensures that Solutions Docs published here: https://docs.gitlab.com/ee/solutions/, follow the optimized review and approval workflow for that area rather than the normal tech writing workflow by applying appropriate labels and reviewers.
## What does this MR do?
<!-- Briefly describe what this MR is about. -->
## Related issues
<!-- Link related issues below. -->
## Review
-[ ] I have read the [Solutions Docs Contributors Guide in the GitLab Handbook](https://handbook.gitlab.com/handbook/customer-success/solutions-architects/sa-documentation/) and believe that this contribution complies with the scope and requirements outlined there.
- [ ] Assign yourself as the **Assignee** of this MR.
-[ ] Assign the latest release for the **Milestone**. If you're not sure, [view the list of releases](https://about.gitlab.com/releases/).
- [ ] Mention the reviewers in a comment, so they're aware that the MR is ready.
## Merging
- [ ] Obtain approval from a member of the Solutions Documentation Approvers Group (CODEOWNERS for the Solutions directory)
When a code owner approves, they can merge.
## Troubleshooting
The pipeline will test for style and link issues. If you have issues you're unable to resolve,
view the documentation [Style Guide](https://docs.gitlab.com/ee/development/documentation/styleguide/)
-[ ] If you're adding a new page, add the [product availability details](https://docs.gitlab.com/ee/development/documentation/styleguide/availability_details.html) under the H1 topic title.
-[ ] If you are a GitLab team member, [request a review](https://docs.gitlab.com/ee/development/code_review.html#dogfooding-the-reviewers-feature) based on:
- The documentation page's [metadata](https://docs.gitlab.com/ee/development/documentation/metadata.html).
- The [associated Technical Writer](https://handbook.gitlab.com/handbook/product/ux/technical-writing/#assignments).
If you are a GitLab team member and only adding documentation, do not add any of the following labels:
-`~"frontend"`
-`~"backend"`
-`~"type::bug"`
-`~"database"`
These labels cause the MR to be added to code verification QA issues.
## Reviewer's checklist
Documentation-related MRs should be reviewed by a Technical Writer for a non-blocking review, based on [Documentation Guidelines](https://docs.gitlab.com/ee/development/documentation/) and the [Style Guide](https://docs.gitlab.com/ee/development/documentation/styleguide/).
If you aren't sure which tech writer to ask, use [roulette](https://gitlab-org.gitlab.io/gitlab-roulette/?sortKey=stats.avg30&order=-1&hourFormat24=true&visible=maintainer%7Cdocs) or ask in the [#docs](https://gitlab.slack.com/archives/C16HYA2P5) Slack channel.
- [ ] If the content requires it, ensure the information is reviewed by a subject matter expert.
- Technical writer review items:
- [ ] Ensure docs metadata is present and up-to-date.
-[ ] Ensure the appropriate [labels](https://handbook.gitlab.com/handbook/product/ux/technical-writing/workflow/#labels) are added to this MR.
- [ ] Ensure a release milestone is set.
- If relevant to this MR, ensure [content topic type](https://docs.gitlab.com/ee/development/documentation/topic_types/) principles are in use, including:
- [ ] The headings should be something you'd do a Google search for. Instead of `Default behavior`, say something like `Default behavior when you close an issue`.
- [ ] The headings (other than the page title) should be active. Instead of `Configuring GDK`, say something like `Configure GDK`.
- [ ] Any task steps should be written as a numbered list.
- If the content still needs to be edited for topic types, you can create a follow-up issue with the ~"docs-technical-debt" label.
- [ ] Review by assigned maintainer, who can always request/require the reviews above. Maintainer's review can occur before or after a technical writer review.
-[ ] Confirm the test has a [`testcase:` tag linking to an existing test case](https://docs.gitlab.com/ee/development/testing_guide/end_to_end/best_practices.html#link-a-test-to-its-test-case-issue) in the test case project.
- [ ] Note if the test is intended to run in specific scenarios. If a scenario is new, add a link to the MR that adds the new scenario.
-[ ] Follow the end-to-end tests [style guide](https://docs.gitlab.com/ee/development/testing_guide/end_to_end/style_guide.html) and [best practices](https://docs.gitlab.com/ee/development/testing_guide/end_to_end/best_practices.html).
-[ ] Use the appropriate [RSpec metadata tag(s)](https://docs.gitlab.com/ee/development/testing_guide/end_to_end/rspec_metadata_tests.html#rspec-metadata-for-end-to-end-tests).
- Most resources will be cleaned up via the general [cleanup task](https://gitlab.com/gitlab-org/gitlab/-/blob/44345381e89d6bbd440f7b4c680d03e8b75b86de/qa/qa/tools/test_resources_handler.rb#L44). Check that is successful, or ensure resources are cleaned up in the test:
- [ ] New resources have `api_get_path` and `api_delete_path` implemented if possible.
-[ ] If any resource cannot be deleted in the general delete task, make sure it is [ignored](https://gitlab.com/gitlab-org/gitlab/-/blob/44345381e89d6bbd440f7b4c680d03e8b75b86de/qa/qa/tools/test_resources_handler.rb#L29).
- [ ] If any resource cannot be deleted in the general delete task, remove it in the test (e.g., in an `after` block).
-[ ] Ensure that no [transient bugs](https://handbook.gitlab.com/handbook/engineering/infrastructure/engineering-productivity/issue-triage/#transient-bugs) are hidden accidentally due to the usage of `waits` and `reloads`.
- [ ] Verify the tags to ensure it runs on the desired test environments.
- [ ] If this MR has a dependency on another MR, such as a GitLab QA MR, specify the order in which the MRs should be merged.
-[ ] (If applicable) Create a follow-up issue to document [the special setup](https://docs.gitlab.com/ee/development/testing_guide/end_to_end/running_tests_that_require_special_setup.html) necessary to run the test: ISSUE_LINK
- [ ] If the test requires an admin's personal access token, ensure that the test passes on your local environment with and without the `GITLAB_QA_ADMIN_ACCESS_TOKEN` provided.
<!-- Base labels. -->
/label ~"Quality" ~"QA" ~test
<!-- If the test is addressing a test gap, select a label according to the feature under test, please use just one. -->
/label ~"Quality:test-gap" ~"Quality:EE test gaps"
<!-- Select the appropriate feature label, ~"feature::addition" for tests added for new features, ~"type::maintenance" for tests added for existing features -->
When creating a new cop that could be applied to multiple applications,
we encourage you to add it to https://gitlab.com/gitlab-org/ruby/gems/gitlab-styles gem.
-->
## Description of the proposal
<!--
Please describe the proposal and add a link to the source (for example, http://www.betterspecs.org/).
-->
### Check-list
- [ ] Make sure this MR enables a static analysis check rule for new usage but
ignores current offenses.
- [ ] Mention this proposal in the relevant Slack channels (e.g. `#development`, `#backend`, `#frontend`).
- [ ] If there is a choice to make between two potential styles, set up an emoji vote in the MR:
- CHOICE_A: :a:
- CHOICE_B: :b:
- Vote for both choices, so they are visible to others.
-[ ] The MR doesn't have significant objections, and is getting a majority of :+1: vs :-1: (remember that [we don't need to reach a consensus](https://handbook.gitlab.com/handbook/values/#collaboration-is-not-consensus)).
- [ ] (If applicable) One style is getting a majority of vote (compared to the other choice).
- [ ] (If applicable) Update the MR with the chosen style.
- [ ] Create a follow-up issue to fix the current offenses as a separate iteration: ISSUE_LINK
-[ ] Follow the [review process](https://docs.gitlab.com/ee/development/code_review.html) as usual.
- [ ] Once approved and merged by a maintainer, mention it again:
- [ ] In the relevant Slack channels (e.g. `#development`, `#backend`, `#frontend`).
- [ ] (Optional depending on the impact of the change) In the Engineering Week in Review.
-[ ] (Optional) [Generate TODOs](https://docs.gitlab.com/ee/development/rubocop_development_guide.html#resolving-rubocop-exceptions) for pending offenses
-[ ] Put :new: cop rules (or if configuration is changed) in "grace period". See [docs](https://docs.gitlab.com/ee/development/rubocop_development_guide.html#enabling-a-new-cop).
- [ ] (Optional) Remove any offenses for disabled cops
- Use `grep --perl-regexp -o ":\d+\d+: \w: \[\S+\] ([\w/]+)" raw_job_output.log | awk '{print $4}' | sort | uniq -c` to get a list of cop rules with offenses. Where `raw_job_output.log` is the raw output of the `rubocop` job
- [ ] Ignore offenses related to temporary changes in `Gemfile`
- [ ] (Optional) Autocorrect offenses
- [ ] Compare the total runtime of `rubocop --parallel` scan with previous runs
- [ ] Make sure CI passes :green_heart:
- [ ] Don't merge this MR yet!
- [ ] Wait for `gitlab-styles` to be released
- [ ] Upgrade released version of `gitlab-styles`
- [ ] Make sure release is complete
- [ ] Rephrase the title and MR description to match final upgrade
- [ ] Frequency they are running (MRs, main branch, nightly, bi-hourly): _____
- [ ] Add a duration chart to https://app.periscopedata.com/app/gitlab/652085/Engineering-Productivity---Pipeline-Build-Durations if there are new jobs added to merge request pipelines
This will help keep track of expected pipeline time and cost increases.
### Post-merge
-[ ] Consider communicating these changes to the broader team following the [communication guideline for pipeline changes](https://handbook.gitlab.com/handbook/engineering/infrastructure/engineering-productivity/#pipeline-changes)
-[ ] Follow the [Quarantining Tests guide](https://handbook.gitlab.com/handbook/engineering/infrastructure/test-platform/debugging-qa-test-failures/#quarantining-tests).
-[ ] Confirm the test has a [`quarantine:` tag with the specified quarantine type](https://handbook.gitlab.com/handbook/engineering/infrastructure/test-platform/debugging-qa-test-failures/#quarantined-test-types).
-[ ] Note if the test should be [quarantined for a specific environment](https://docs.gitlab.com/ee/development/testing_guide/end_to_end/execution_context_selection.html#quarantine-a-test-for-a-specific-environment).
- [ ] (Optionally) In case of an emergency (e.g. blocked deployments), consider adding labels to pick into auto-deploy (~"Pick into auto-deploy" ~"priority::1" ~"severity::1").
- [ ] Dequarantine test check-list
-[ ] Follow the [Dequarantining Tests guide](https://handbook.gitlab.com/handbook/engineering/infrastructure/test-platform/debugging-qa-test-failures/#dequarantining-tests).
- [ ] Confirm the test consistently passes on the target GitLab environment(s).
- [ ] To ensure a faster turnaround, ask in the `#quality_maintainers` Slack channel for someone to review and merge the merge request, rather than assigning it directly.
[Reverting a security merge request] is not encouraged because it rollbacks a security fix
compromising the integrity of GitLab.com, self-managed and in-house instances. If a security merge request
introduced a bug, the next steps will depend on the severity of the security issue, the impact of
the bug introduced and the timeline of the patch release. Consult the [other ways of mitigating the bug]
before continuing with the revert.
## Purpose of the revert
<!-- Please write down the reason why the revert is required, the severity of the security issue
and the severity the bug fix and due date of the patch release -->
* Severity of the security issue: {+ severity +}
* Severity of the bug: {+ severity +}
* Due date of the [ongoing patch release]: {+ yyyy/mm/dd +}
## Checklist:
- [ ] Stage team has contacted AppSec and [release managers] and explained why the revert is necessary.
- [ ] The security issue has been removed from the [patch release].
- [ ] **AppSec Approval: AppSec agrees and understands the vulnerability will be disclosed without being fixed when the patch release is published**
[Reverting a security merge request]:https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/security/bugs_introduced_by_security_merge_request.md?ref_type=heads
[other ways of mitigating the bug]:https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/security/bugs_introduced_by_security_merge_request.md?ref_type=heads
IMPORTANT: Add appropriate labels BEFORE you save the merge request. CI/CD jobs
can be skipped only if the labels are applied BEFORE the CI/CD pipeline is created.
See https://docs.gitlab.com/ee/development/pipelines#revert-mrs for more info.
-->
## Purpose of revert
<!-- Please link to the relevant incident -->
### Checklist
- [ ] Create an issue to reinstate the merge request and assign it to the author of the reverted merge request.
-[ ] If the revert is to resolve a [broken 'master' incident](https://handbook.gitlab.com/handbook/engineering/workflow/#broken-master), please read through the [Responsibilities of the Broken `master` resolution DRI](https://handbook.gitlab.com/handbook/engineering/workflow/#responsibilities-of-the-resolution-dri).
-[ ] If the revert involves a database migration, please read through [Deleting existing migrations](https://docs.gitlab.com/ee/development/database/deleting_migrations.html).
- [ ] Add the appropriate labels **before** the MR is created. We can skip CI/CD jobs only if the labels are added **before** the CI/CD pipeline is created.
### Milestone info
- [ ] I am reverting something in the **current** milestone. No changelog is needed, and I've added a `~"regression:*"` label.
- [ ] I am reverting something in a **different** milestone. A changelog is needed, and I've removed the `~"regression:*"` label.
### Related issues and merge requests
/label ~"pipeline::expedited" ~"master:broken" ~"Pick into auto-deploy" ~"severity::1" ~"priority::1"
<!--
Regression label: if applicable, specify the milestone-specific regression label
(such as ~regression:15.8) to skip additional CI/CD jobs, like Danger changelog checks. -->
This MR should be created on `gitlab.com/gitlab-org/security/gitlab`.
See [the general developer security guidelines](https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/engineer.md).
-->
## Related issues
<!-- Mention the GitLab Security issue this MR is related to -->
## Developer checklist
- [ ] **On "Related issues" section, write down the [GitLab Security] issue it belongs to (i.e. `Related to <issue_id>`).**
- [ ] Familiarize yourself with the latest process to create Security merge requests: https://gitlab.com/gitlab-org/release/docs/blob/master/general/security/engineer.md#process
- [ ] Merge request targets `master`, or a versioned stable branch (`X-Y-stable-ee`).
- [ ] Title of this merge request is the same as for all backports.
- [ ] A [CHANGELOG entry] has been included, with `Changelog` trailer set to `security`.
- [ ] For the MR targeting `master`:
- [ ] Assign to a reviewer and maintainer, per our [Code Review process].
- [ ] Ensure it's approved according to our [Approval Guidelines].
- [ ] Ensure it's approved by an AppSec engineer.
- Please see the security [Code reviews and Approvals] documentation for details on which AppSec team member to ping for approval.
- Trigger the [`e2e:package-and-test` job]. The docker image generated will be used by the AppSec engineer to validate the security vulnerability has been remediated.
- [ ] For a backport MR targeting a versioned stable branch (`X-Y-stable-ee`).
- [ ] Ensure it's approved by the same maintainer that reviewed and approved the merge request targeting the default branch.
- [ ] Ensure this merge request and the related security issue have a `~severity::x` label
**Note:** Reviewer/maintainer should not be a [Release Manager].
## Maintainer checklist
- [ ] Assigned (_not_ as reviewer) to `@gitlab-release-tools-bot` with passing CI pipelines.
- [ ] Correct `~severity::x` label is applied to this merge request and the related security issue.
Security backport merge requests should not be opened on the GitLab canonical project.
-->
## What does this MR do and why?
_Describe in detail what merge request is being backported and why_
## MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
* [ ] This MR is backporting a bug fix, documentation update, or spec fix, previously merged in the default branch.
* [ ] The MR that fixed the bug on the default branch has been deployed to GitLab.com (not applicable for documentation or spec changes).
* [ ] This MR has a [severity label] assigned (if applicable).
* [ ] Set the milestone of the merge request to match the target backport branch version.
* [ ] This MR has been approved by a maintainer (only one approval is required).
* [ ] Ensure the `e2e:package-and-test-ee` job has either succeeded or been approved by a Software Engineer in Test.
#### Note to the merge request author and maintainer
If you have questions about the patch release process, please:
* Refer to the [patch release runbook for engineers and maintainers] for guidance.
* Ask questions on the [`#releases`] Slack channel (internal only).
