GitLab.org/GitLab: Release v13.4.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 13.4
Released: 2020-09-22
License: MIT
Release Assets:
#### [Ultimate](https://about.gitlab.com/pricing/ultimate/)
[Show alerts in the environment index page](https://docs.gitlab.com/ee/ci/environments/#view-the-latest-alerts-for-environments):
> The environments page shows the general status of your environments. In this release, we improved the environment page by adding alerts. Seeing triggered alerts alongside the status of your environments enables you to take immediate action to remedy situations.
Continuous Delivery[Revoke PATs for self-managed credential inventory](https://docs.gitlab.com/ee/administration/credentials_inventory.html) (self-managed only):
> The [Credentials inventory](https://docs.gitlab.com/ee/administration/credentials_inventory.html#credentials-inventory-ultimate-only) provides the insight administrators need to manage user access credentials for their GitLab instance. As compliance-minded organizations vary in the strictness of their credential management policies, we've added a button that allows administrators to optionally revoke a user's Personal Access Token (PAT). Administrators can now easily revoke PATs that may be compromised. This feature supports organizations that want more flexible enforcement options, to minimize disruptions to their users.
Compliance Management[Export a list of all merge commits](https://docs.gitlab.com/ee/user/compliance/compliance_dashboard/index.html#chain-of-custody-report):
> Compliance-minded organizations need a way to show auditors a holistic view of the components involved with any particular change to production. Within GitLab, this means connecting all of the dots: MRs, issues, pipelines, security scans, and other data about a commit. Until now, you had to either dig through the GitLab application and/or build custom tooling to aggregate the information - which was not very efficient.
>
> Now, you can programmatically collect and export this data to satisfy auditing requirements or perform other analyses by navigating to the [Compliance Dashboard](https://docs.gitlab.com/ee/user/compliance/compliance_dashboard/index.html#compliance-dashboard-ultimate) and clicking the button to export a list of all merge commits for the group. The resulting file will contain all merge commits and their author, related merge request ID, group, project, approvers, and more.
Audit Reports[List and Revoke Personal Access Tokens via API](https://docs.gitlab.com/ee/api/personal_access_tokens.html):
> Managing access to your GitLab namespace is an important part of your compliance program. From the principles of least privilege to timely termination of access, there are several compliance requirements related to Personal Access Tokens within GitLab. To support easier, better and bulk management of these user credentials within your namespace we've introduced the ability to list all user PATs and optionally [revoke](https://gitlab.com/gitlab-org/gitlab/-/issues/216004) them via API.
>
> These improvements to GitLab's API capabilities enable users to list and revoke their own PATs and enables administrators to list and revoke the PATs of their users. Administrators now have better visibility into who has access to their namespace, can make data-informed decisions about their users' credentials, and are empowered to revoke PATs that may be compromised or which may exceed corporate policy for credential rotation.
Compliance Management[Security Center](https://docs.gitlab.com/ee/user/application_security/security_dashboard/#instance-security-center):
> Today, the Vulnerability Management experience at the Instance level
> is limited in both functionality and flexibility. The current
> experience is a single page that combines vulnerability details,
> metrics visualizations, and configuration. There's not much room to expand
> these functions or leverage other security features.
>
> We've made a foundational change to security visibility and management
> in GitLab. The Instance Security Dashboard has been transformed into a
> Security Center. The biggest change is introducing a new menu structure.
> Rather than a single page, you can now find a Security Dashboard,
> Vulnerability Report, and Settings area. While the functionality hasn't changed,
> breaking things apart enables future enhancements that would have been difficult
> otherwise. This also creates a top-level framework for including other
> security-related functionality in the future.
>
> The dedicated Vulnerability Report now has more room to display important
> details and inherits those currently found on the Project vulnerability
> list. Separating the vulnerability metrics widgets into their own area
> creates a true Security Dashboard. This is now a dedicated canvas for
> future visualizations—-not just for managing vulnerabilities but for any
> of our security-related metrics. Finally, splitting Settings out into its
> own area creates a new shared space for instance-level security
> configuration beyond Vulnerability Management.
Vulnerability Management[API Fuzz Testing with OpenAPI specs or HAR files](https://docs.gitlab.com/ee/user/application_security/api_fuzzing/index.html):
> API Fuzz Testing is a great way to find bugs and vulnerabilities
> in your web apps and APIs that other scanners and testing techniques miss.
>
> GitLab's API fuzz testing lets you provide an [OpenAPI v2 specification](https://swagger.io/specification/v2/)
> or a [HAR file](https://en.wikipedia.org/wiki/HAR_(file_format))
> of your application, and then automatically generates random inputs
> designed to exercise edge cases and find bugs. Results are then
> immediately shown as part of the pipeline.
>
> This is our first release of API fuzz testing and we'd love to hear
> from you and know what you think. We have [a lot more in store](https://about.gitlab.com/direction/secure/dynamic-analysis/fuzz-testing/) for fuzz
> testing that we're excited to build on top of this release!
Fuzz Testing[New language support for coverage-guided fuzz testing](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/#supported-fuzzing-engines-and-languages):
> This release introduces support for multiple new languages to
> coverage-guided fuzz testing.
>
> You can now leverage all the power of fuzz testing for your apps
> written in Java, Rust, and Swift to find bugs and security
> vulnerabilities that other processes miss!
Fuzz Testing[On-demand DAST Scanner Profiles](https://docs.gitlab.com/ee/user/application_security/dast/#scanner-profile):
> Adding onto the DAST On-demand scans that were [introduced in the last release](https://about.gitlab.com/releases/2020/08/22/gitlab-13-3-released/#on-demand-dast-scans), DAST Scanner Profiles extend the configuration options of these scans by allowing for the quick creation of multiple profiles, to cover multiple scan types. In 13.4, the Scanner Profile initially includes a spider timeout option, which sets how long the DAST spider should run when it tries to discover all the pages of a site to be scanned. It also includes a target timeout option, to set how long the scanner should wait for a site to become available before it aborts the scan, if the site does not respond with a 200 or 300 status code. As we continue to iterate on this feature in upcoming releases, more configuration options will be added to the Scanner Profile.
DAST[Expand package managers and languages supported by Dependency Scanning](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#supported-languages-and-package-managers):
> We are pleased to add Dependency Scans for C, C++, C#, and .Net projects that use NuGet 4.9+ or Conan package managers to our [supported languages and frameworks](https://docs.gitlab.com/ee/user/application_security/dependency_scanning/#supported-languages-and-package-managers). As part of our Secure stage, you can enable Dependency Scanning to check the dependencies included via package managers for known vulnerabilities. These vulnerabilities will be shown in your merge request, along with their severity level, so you can know before merging what risks that new dependency may introduce. You can also configure your project to require a [merge request approval](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/) for any vulnerabilities with severity Critical, High, or Unknown.
Dependency Scanning[Create, Edit, and Delete for Container Network Policies](https://docs.gitlab.com/ee/user/application_security/threat_monitoring/#container-network-policy-editor):
> This improvement to the Container Network Policy editor allows users to easily create, edit, and delete their policies from directly within the GitLab UI. The editor's capabilities include a `.yaml` mode for experienced users and an intuitive rules editor UI for users new to Network Policies. You can find the new policy management capabilities at **Security & Compliance > Threat Management > Policies**.
Container Network Security[Use HashiCorp Vault secrets in CI jobs](https://docs.gitlab.com/ee/ci/secrets):
> In GitLab 12.10, GitLab introduced functionality for GitLab Runner to fetch and inject secrets into CI jobs. GitLab is now expanding the [JWT Vault Authentication method](https://docs.gitlab.com/ee/ci/examples/authenticating-with-hashicorp-vault/) by building a new `secrets` syntax in the `.gitlab-ci.yml` file. This makes it easier for you to configure and use HashiCorp Vault with GitLab.
Secrets Management[Introducing the GitLab Agent for Kubernetes](https://docs.gitlab.com/ee/user/clusters/agent) (self-managed only):
> GitLab's Kubernetes integration has long enabled deployment to Kubernetes clusters without manual setup. Many users have enjoyed the ease-of-use, while others have run into some challenges. The current integration requires your cluster to be open to the Internet for GitLab to access it. For many organizations, this isn't possible, because they must lock down their cluster access for security, compliance, or regulatory purposes. To work around these restrictions, users needed to create custom tooling on top of GitLab, or they couldn't use the feature.
>
> Today, we're announcing the GitLab Agent for Kubernetes: a new way to deploy to Kubernetes clusters. The Agent runs inside of your cluster, so you don't need to open it to the internet. The Agent orchestrates deployments by pulling new changes from GitLab, rather than GitLab pushing updates to the cluster. No matter what method of GitOps you use, GitLab has you covered.
>
> Note this is the first release of the Agent. Currently, the GitLab Agent has a configuration-driven setup and enables deployment management by code. Some existing Kubernetes integration features, such as Deploy Boards and GitLab Managed Apps, are not yet supported. [Our vision](https://about.gitlab.com/direction/configure/kubernetes_management/) is to eventually implement these capabilities, and provide new security- and compliance-focused integrations with the Agent.
Kubernetes Management[Grant users deployment permissions without code access](https://docs.gitlab.com/ee/ci/environments/protected_environments.html#environment-access-by-group-membership):
> If your team needs to maintain separation of duties between team members who own development, and team members who own deployments, the permissions paradigm in GitLab has made this challenging. In GitLab 13.4, you can give non-code contributors permission to approve merge requests for deployment, and actually deploy code, without also granting them maintainer access.
Release Orchestration[Feature Flags made available in GitLab Starter](https://docs.gitlab.com/ee/operations/feature_flags.html):
> In GitLab 11.4 Feature Flags were [introduced](https://about.gitlab.com/releases/2018/10/22/gitlab-11-4-released/#create-and-toggle-feature-flags-for-your-applications-alpha). In 12.2 we introduced [percent rollout](https://about.gitlab.com/releases/2019/08/22/gitlab-12-2-released/#percent-rollout-strategy-for-feature-flags) and [user ID](https://about.gitlab.com/releases/2019/08/22/gitlab-12-2-released/#user-id-rollout-strategy-for-feature-flags) feature flag strategies. In 13.1 we introduced feature flag [user lists](https://about.gitlab.com/releases/2020/06/22/gitlab-13-1-released/#control-feature-flags-with-user-lists) and support for [multiple feature flag strategies](https://about.gitlab.com/releases/2020/06/22/gitlab-13-1-released/#set-feature-flag-strategy-across-environments) per environment.
>
> Earlier this year, GitLab committed to [moving 18 features](/blog/2020/03/30/new-features-to-core/) to our open source core product. With this release of GitLab we've finished moving Feature Flags to Starter, and we are continuing to migrate our Feature Flag service to Core in [GitLab 13.5](https://gitlab.com/gitlab-org/gitlab/-/issues/212318). We're excited about bringing these features to more users and seeing what use cases and workflows you use them for.
Feature Flags[Track environments at scale with the Environments Dashboard](https://docs.gitlab.com/ee/ci/environments/environments_dashboard.html):
> Since GitLab 12.5, you could only see 7 environments across 3 projects with the [Environment Dashboard](https://gitlab.com/gitlab-org/gitlab/-/issues/3713). We've improved the Environment Dashboard in GitLab 13.4 by paginating the dashboard to help you support and manage your environments at scale. You can now see more environments across many projects.
Release Orchestration[75% faster search results in Advanced Search](https://docs.gitlab.com/ee/user/search/advanced_search.html#faster-searches):
> As a single application, GitLab has a unique opportunity to make locating content across the entire DevOps workflow delightful. In GitLab 13.4, Advanced Search now outputs results 75% faster when it is [limited to specific namespaces and projects](https://docs.gitlab.com/ee/integration/elasticsearch.html#limiting-namespaces-and-projects), like on GitLab.com.
Global Search[Group Push Rules Support Added to API](https://docs.gitlab.com/ee/api/groups.html#push-rules):
> Previously, group push rules could only be configured by visiting each group individually via GitLab UI and applying these rules. Now you can manage these rules via API to support your custom GitLab tooling and automation.
Compliance Management[Smartcard authentication support for GitLab Helm chart](https://docs.gitlab.com/charts/charts/globals.html#smartcard-authentication-settings) (self-managed only):
> Smartcards, such as Common Access Cards (CAC), can now be used to authenticate against a Helm chart-deployed GitLab instance. Smartcards are authenticated against a local database using X.509 certificates. This brings the Helm chart in parity with the smartcard support available in Omnibus deployments.
Cloud Native Installation[Support custom JSON schema validation in the Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/#custom-schemas):
> Projects that rely on people writing configurations in JSON or YAML format can cause problems because it's easy to make a typo and break things. It's possible to write validation tools that catch this in the CI pipeline but using a JSON schema file can be helpful for offering documentation and hints.
>
> Project contributors can define a custom schema path in the `.gitlab/.gitlab-webide.yml` file in their repository which specifies the schema and path of files to validate. When loading the defined file in the Web IDE additional feedback and validation will be visible to help create the file.
Web IDE[Code Coverage Data for all projects in a group](https://docs.gitlab.com/ee/user/group/#repositories-analytics):
> When you or your team manages multiple GitLab projects, you should be able to easily see a single data point showing how code coverage is trending over time across all projects. Previously, visualizing this trend involved tedious, manual, work to download the coverage data from each project and insert it into a spreadsheet.
>
> Now, as team lead, you can quickly and easily gather all the code coverage data available in each of your group's projects or a selection of projects as a `.csv` file. This is an MVC feature that will be followed by the ability to [graph the average coverage over time](https://gitlab.com/gitlab-org/gitlab/-/issues/215140).
Code Testing and Coverage[Merge requests not accidentally dropped from merge train](https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/):
> Previously, merge requests could be dropped from the Merge Train accidentally by late comments. If a merge request was already on the merge train, and someone added a comment that created a new unresolved thread, the merge request was then considered unmergeable and dropped from the train. Now, after the merge request is added to the train, new comments can be made without any worries about disrupting the merge process.
Continuous Integration (CI)[Quick navigation using the Search bar](https://docs.gitlab.com/ee/user/search/#autocomplete-suggestions):
> When navigating through GitLab, sometimes you just want to go to
> a specific project and not a search result page.
>
> Using the Global search bar, you can now quickly jump to recent issues, groups,
> projects, settings, and help topics. You can even use the `/` keyboard shortcut
> to move the cursor to the search bar, to navigate GitLab even more efficiently!
Global Search[Taking ownership of the GitLab Terraform provider](https://www.terraform.io/docs/providers/gitlab/index.html):
> We've recently [received maintainer rights to the GitLab Terraform provider](https://github.com/gitlabhq/terraform-provider-gitlab/issues/376) and plan to [enhance it in upcoming releases](https://gitlab.com/groups/gitlab-org/-/epics/3525). In the past month we've merged 21 pull requests and closed 31 issues, including some long outstanding bugs and missing features, like [supporting instance clusters](https://github.com/gitlabhq/terraform-provider-gitlab/pull/367). You can [read more about the GitLab Terraform provider](https://www.terraform.io/docs/providers/gitlab/index.html) in the Terraform documentation.
Kubernetes Management, Infrastructure as Code[Simple redirect configuration file for GitLab Pages](https://docs.gitlab.com/ee/user/project/pages/redirects.html):
> If you are a user of GitLab Pages wanting to better manage URL changes, you've encountered the pain point of being unable to manage redirects in your GitLab Pages site. GitLab now allows you to configure rules to forward one URL to another for your Pages site by adding a configuration file to your repository. This feature was made possible by contributions from Kevin Barnett ([@PopeDrFreud](https://gitlab.com/PopeDrFreud)), our very own Eric Eastwood ([@MadLittleMods](https://gitlab.com/MadLittleMods)), and the GitLab team. Thank you all for your contributions.
Pages[Omnibus ARM64 packages for Ubuntu and OpenSUSE](https://docs.gitlab.com/omnibus/package-information/deprecated_os.html#packages-for-arm64) (self-managed only):
> In response to increasing demand for support running GitLab on the 64-bit ARM architecture, we are excited to announce the availability of an official ARM64 Ubuntu 20.04 Omnibus package. A huge thanks to Zitai Chen and Guillaume Gardet for the enormous contribution they have made - their merge requests have been a key enabler to making this happen!
>
> To download and install the Ubuntu 20.04 package, go to our [Install page](https://about.gitlab.com/install/) and select `Ubuntu`.
Omnibus Package[Azure Blob storage support](https://docs.gitlab.com/ee/administration/object_storage.html#azure-blob-storage):
> Both GitLab and GitLab Runner now support [Azure Blob storage](https://docs.gitlab.com/ee/administration/object_storage.html#azure-blob-storage),
> making it easier to run GitLab services on Azure.
>
> GitLab instances support Azure for all object storage types, including: LFS files, CI artifacts, [backups](https://docs.gitlab.com/ee/raketasks/backup_restore.html#using-azure-blob-storage),
> and more. To configure Azure Blob storage, follow the instructions for [Omnibus](https://docs.gitlab.com/ee/administration/object_storage.html#azure-blob-storage) or [Helm chart](https://docs.gitlab.com/charts/advanced/external-object-storage/#azure-blob-storage) installations.
>
> GitLab Runners also support Azure for storing the [distributed cache](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runnerscache-section). Azure storage can be configured
> using the [`[runners.cache.azure]`](https://docs.gitlab.com/runner/configuration/advanced-configuration.html#the-runnerscache-section) section.
Omnibus Package, Cloud Native Installation, GitLab RunnerBug fixes
> Some of the notable bug fixes in 13.4 are:
>
> - [500 error when uploading a PyPI package](https://gitlab.com/gitlab-org/gitlab/-/issues/241492)
> - [500 error when uploading a Conan package](https://gitlab.com/gitlab-org/gitlab/-/issues/246741)
> - [Conan returns incorrect package version](https://gitlab.com/gitlab-org/gitlab/-/issues/235653)
> - [Composer returns 404 on API request](https://gitlab.com/gitlab-org/gitlab/-/issues/232636)
> - [Conan package names are not clear in the Package Registry UI](https://gitlab.com/gitlab-org/gitlab/-/issues/233993)
> - [Don't send `SameSite=None` to incompatible browsers](https://gitlab.com/gitlab-org/gitlab/-/issues/241785)
> - [Iteration reports should include Issues from deeply nested Projects](https://gitlab.com/gitlab-org/gitlab/-/issues/229433)
> - [Reactions should not be allowed on locked Issues](https://gitlab.com/gitlab-org/gitlab/-/issues/29957)
> - [Group Boards can't be scoped to Group Milestones](https://gitlab.com/gitlab-org/gitlab/-/issues/240989)
> - [Jira Importer user mapping only shows a maximum of 50 users](https://gitlab.com/gitlab-org/gitlab/-/issues/235889)
> - [Fix Windows runner helper Docker container](https://gitlab.com/gitlab-org/gitlab/-/issues/239013)
> - [Ensure Powershell file variables contain no BOM](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4818)
> - [Security Approvals required even when no new vulnerabilities have been found](https://gitlab.com/gitlab-org/gitlab/-/issues/222643)
> - [Unable to fetch vulnerable projects](https://gitlab.com/gitlab-org/gitlab/-/issues/228749)
> - [Cilium cluster application state is not updated upon installation](https://gitlab.com/gitlab-org/gitlab/-/issues/232919)
> - [Geo: Skip container repo update events based on selective sync](https://gitlab.com/gitlab-org/gitlab/-/issues/233514)
> - [Geo: Skip design repo update events based on selective sync](https://gitlab.com/gitlab-org/gitlab/-/issues/233505)
> - [Geo: Fix blob delete events](https://gitlab.com/gitlab-org/gitlab/-/issues/233040)
> - [Geo: Disabled secondary causes issues in failover](https://gitlab.com/gitlab-org/gitlab/-/issues/237896)
> - [Geo: Container repository update events race condition](https://gitlab.com/gitlab-org/gitlab/-/issues/238137)
> - [Restore from backup fails due to `ActiveRecord::IrreversibleOrderError`](https://gitlab.com/gitlab-org/gitlab/-/issues/36405)
> - [User search times out when filtering to group](https://gitlab.com/gitlab-org/gitlab/-/issues/31092)
> - [Service Desk adds support for `X-Envelope-To` header](https://gitlab.com/gitlab-org/gitlab/-/issues/232935)
> - [Sub-epics inherit dates from parent when issue is moved](https://gitlab.com/gitlab-org/gitlab/-/issues/231332)
> - [Fix creation of epics from within epic tree of confidential epic](https://gitlab.com/gitlab-org/gitlab/-/issues/229839)
> - [Fix assigning of epics through quick actions](https://gitlab.com/gitlab-org/gitlab/-/issues/245026)
> - [Cast GIDs when updating issue epics through GraphQL](https://gitlab.com/gitlab-org/gitlab/-/issues/247059)
> - [Scrolling through tests tab is buggy when tests have failed](https://gitlab.com/gitlab-org/gitlab/-/issues/212274)
> - [All environment variables are not propagated to Code Quality job](https://gitlab.com/gitlab-org/gitlab/-/issues/11100)
> - [Unit test times below 1 second are reported as 00:00:00](https://gitlab.com/gitlab-org/gitlab/-/issues/213101)
> - [Inconsistent behavior when using needs with skipped jobs](https://gitlab.com/gitlab-org/gitlab/-/issues/213080)
> - [Child pipeline execution is skipped when previous job in parent pipeline is retried](https://gitlab.com/gitlab-org/gitlab/-/issues/213456)
> - ["Closes #issue" text is duplicated when opening an MR from source branch that starts with issue number](https://gitlab.com/gitlab-org/gitlab/-/issues/244876)
> - [500 error / timeout when creating new issues](https://gitlab.com/gitlab-org/gitlab/-/issues/244820)
> - [Iterations should not auto-close on the due date, but rather the day after](https://gitlab.com/gitlab-org/gitlab/-/issues/243575)
> - [`ArgumentError` in Todos API](https://gitlab.com/gitlab-org/gitlab/-/issues/227174)
> - [Fix `projectMembers` GraphQL endpoint](https://gitlab.com/gitlab-org/gitlab/-/issues/220527)
> - [The names of the columns in a board are missing when the column is collapsed](https://gitlab.com/gitlab-org/gitlab/-/issues/246796)
> - [Issue Comments no longer displaying for users of Edge 17/42 after upgrade from 13.0.3 to 13.3.1](https://gitlab.com/gitlab-org/gitlab/-/issues/246546)
> - [Fix "mark all todos as done" on mobile](https://gitlab.com/gitlab-org/gitlab/-/issues/244844)
> - [Search query is added without query parameter name in the service desk issues list](https://gitlab.com/gitlab-org/gitlab/-/issues/235440)
> - [Issue weight in issues board needs alignment and update to color](https://gitlab.com/gitlab-org/gitlab/-/issues/33097)
> - [Triggering multiple dynamically generated child pipelines in a single phase causes all but one to fail](https://gitlab.com/gitlab-org/gitlab/-/issues/212373)
[GitLab chart improvements](https://docs.gitlab.com/charts) (self-managed only):
> - A RedHat Universal Base Image (UBI) version of the alpine-certificates image is now available. Previously, deployments using UBI-based images needed to use a non-UBI image for the certificate container. To deploy GitLab with this new image, specify `global.certificates.image.tag=master-ubi8` in your `values.yaml` file. For more information on deploying GitLab using UBI images, see [GitLab with UBI-based images](https://docs.gitlab.com/charts/advanced/ubi/).
> - Helm installs now support smartcard authentication. See [the smartcard announcement](#smartcard-access-for-gitLab-installations-deployed-using-helm) for more details.
> - A sub chart has been added for [deploying and configuring the Praefect service](https://docs.gitlab.com/charts/charts/gitlab/praefect/index.html). Praefect allows you to manage storage of Git repositories across a cluster of Gitaly nodes for a fault tolerant configuration. To learn more about Gitaly clusters, see the [Gitaly documentation](https://docs.gitlab.com/ee/administration/gitaly/praefect.html).
> - Caches of archive files downloaded to Workhorse have been disabled for Helm chart installations. Storing archive caches on local disk was carried over from the Omnibus installation method. With Kubernetes deployments, the disk is not shared across pods. Archives build up over time because there is no way to clean up the archive files. This can cause excessive disk usage issues on nodes.
> - It is now possible to enable a Content Security Policy (CSP) in the chart to help prevent JavaScript cross-site scripting (XSS) attacks. For details, see [the Global Settings documentation](https://docs.gitlab.com/charts/charts/globals.html#content-security-policy).
> - A [bug has been resolved](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/2288) that prevented Helm-based installs on VMWare clusters when a job name contained a dot.
> - [Instructions for migrating from Helm 2 to Helm 3](https://docs.gitlab.com/charts/installation/migration/helm.html) are now available.
Cloud Native Installation[Create EKS clusters with user-specified Kubernetes version](https://docs.gitlab.com/ee/user/project/clusters/add_eks_clusters.html):
> GitLab users can now choose their preferred Kubernetes version to be provisioned on EKS. In line with the supported Kubernetes versions available on EKS, users can choose between versions 1.14 - 1.17.
Kubernetes Management[GitLab Managed Terraform State](https://docs.gitlab.com/ee/user/infrastructure/#gitlab-managed-terraform-state):
> Having access to previous versions of a Terraform state is necessary both for compliance and occasional debugging needs. Support for versioning of GitLab Managed Terraform state is provided starting with GitLab 13.4. Versioning is turned on automatically for new Terraform state files. Existing GitLab Managed Terraform state files will be [migrated automatically to versioned storage](https://gitlab.com/gitlab-org/gitlab/-/issues/235108) in a later release.
Infrastructure as Code[Deleted projects view for administrators](https://docs.gitlab.com/ee/user/project/working_with_projects.html#delete-a-project) (self-managed only):
> Thank you to [Ashesh Vidyut (@asheshvidyut7)](https://gitlab.com/asheshvidyut7) for this community contribution!
>
> The ability to delay project deletion was [introduced in 12.6](https://gitlab.com/gitlab-org/gitlab/-/issues/32935). However, previously there was no way to see all projects pending deletion in one place. Now self-managed administrators can view all projects pending deletion in a single view, along with buttons to easily restore these projects.
>
> This capability allows self-managed administrators to have better control of project deletion by aggregating this information in a single place and providing the opportunity to undo undesirable deletion activity.
Compliance Management[Notifications when 'Merge When Pipeline Succeeds' is set on a merge request](https://docs.gitlab.com/ee/user/profile/notifications#notifications-on-issues-merge-requests-and-epics):
> When a reviewer sets a merge request (MR) to **Merge When Pipeline Succeeds (MWPS)**, no email notification is sent. You must manually check to see the status or wait for the notification when the MR is merged. In this release we are excited to include a community contribution by [@ravishankar2kool](https://gitlab.com/ravishankar2kool) which solves this problem by automatically notifying all the subscribers in the merge request thread when a reviewer sets the MR to MWPS.
Continuous Delivery[Omnibus improvements](https://docs.gitlab.com/omnibus) (self-managed only):
> - Support for deploying GitLab on ARM64 is now available. See the [announcement](#omnibus-arm64-packages-for-ubuntu-and-opensuse) for more details.
> - This release includes minor version updates for PostgreSQL from 11.7 to 11.9, and 12.3 to 12.4. For details of the changes made in these releases, see [the PosgreSQL release announcement](https://www.postgresql.org/about/news/2060/).
> - GitLab 13.4 includes [Mattermost 5.26](https://mattermost.com/blog/mattermost-release-v5-26/), an [open source Slack-alternative](https://mattermost.com/). This release includes the ability to categorize and reorder channels with experimental channel sidebar enhancements, the ability to get help from the Mattermost community via ‘Ask the community’ link, and much more. It also includes [security updates](https://mattermost.com/security-updates/). We recommend you upgrade from earlier versions.
Omnibus PackagePerformance Improvements
> In every release, we continue to make great strides improving GitLab's performance. We're committed to making every GitLab instance faster. This includes GitLab.com, an instance with over 1 million registered users!
>
> In GitLab 13.4, we're shipping performance improvements for issues, projects, milestones, and much more! Some improvements in GitLab 13.4 are:
>
> - [Fix Package versions rendering results with N^2 queries](https://gitlab.com/gitlab-org/gitlab/-/issues/219171)
> - [Reduced loading of **Settings > Notifications** in some situations from over 60s to ~2s](https://gitlab.com/gitlab-org/gitlab/-/issues/207991)
> - [Merge Requests no longer time out when they are created with a large description](https://gitlab.com/gitlab-org/gitlab/-/issues/217483)
> - [Improve Snowplow product analytics performance](https://gitlab.com/gitlab-org/gitlab/-/issues/223855)
> - [Fix some N+1 GraphQL queries](https://gitlab.com/gitlab-org/gitlab/-/issues/11496)
> - [Geo: Improve performance of package files queries](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/42294)
[Connect an Atlassian Account](https://docs.gitlab.com/ee/administration/auth/atlassian.html) (self-managed only):
> GitLab users will now be able to connect their GitLab account to their Atlassian Cloud account. Connecting accounts allows users to sign in to GitLab with their Atlassian credentials. This change also lays the foundation for future enhancements to the [Gitlab Jira integration](https://docs.gitlab.com/ee/integration/jira/) and integrating with other products in the Atlassian suite.
Authentication and Authorization[Related Issues and more are now available in Core](https://docs.gitlab.com/ee/user/project/issues/related_issues.html#related-issues):
> A few months ago, we announced a plan to [open source 18 features](https://about.gitlab.com/blog/2020/03/30/new-features-to-core/). In working towards honoring that commitment, [Related Issues](https://docs.gitlab.com/ee/user/project/issues/related_issues.html#related-issues)[1], [Issues CSV Export](https://docs.gitlab.com/ee/user/project/issues/csv_export.html), and [Issue Board Focus Mode](https://docs.gitlab.com/ee/user/project/issue_board.html#focus-mode) are now available in Core. This only applies to the "relates to" relationship. "Blocks" and "is blocked by" remain in paid tiers.
Issue Tracking[Inline code coverage remarks inside MR diffs](https://docs.gitlab.com/ee/user/project/merge_requests/test_coverage_visualization.html):
> When Reviewing a Merge Request it is difficult to determine if the modified code is covered by a unit test or not. Reviewers may instead rely on the overall coverage value and require an increase in the value before they approve the Merge Request. This can lead to a scattershot approach of test writing by developers that may not actually improve code quality or coverage.
>
> Now a developer will see a visual representation of code coverage in the Merge Request diff when doing a review. This visual indicator makes it easy to see if the modified code is covered by a unit test or not, helping speed up code reviews and the time for a feature to be merged and deployed.
>
> Thank you to [Fabio Huser](https://gitlab.com/fh1ch) and Siemens for the contribution!
Code Review[Mark a to do as Done in the Design View](https://docs.gitlab.com/ee/user/project/issues/design_management.html#add-to-dos-for-designs):
> Effective communication in GitLab relies on the To-Do List. If you are mentioned in a comment, it's critical to be able to follow the to do and either take action or mark it as done. It's also important to be able to give yourself to dos when you need to remember to work on something or come back later.
>
> Until now, it was super frustrating that you could not add a to do or mark it as done on Designs. This really impaired the effectiveness of communication between product teams as to dos are essential to managing the flow of work in GitLab.
>
> As of 13.4, Designs achieve parity with Issue comments and their use of to dos for a more consistent and useful experience!
Design Management[Gitaly Cluster majority-wins reference transactions (beta)](https://docs.gitlab.com/ee/administration/gitaly/praefect.html#strong-consistency) (self-managed only):
> Gitaly Cluster allows Git repositories to be replicated on multiple warm Gitaly nodes. This improves fault tolerance by removing single points of failure. [Reference transactions](#gitaly-cluster-reference-transactions), introduced in GitLab 13.3, causes changes to be broadcast to all the Gitaly nodes in the cluster, but only the Gitaly nodes that vote in agreement with the primary node persist the changes to disk. If all the replica nodes dissented, only one copy of the change would be persisted to disk, creating a single point of failure until asynchronous replication completed.
>
> Majority-wins voting improves fault tolerance by requiring a majority of nodes to agree before persisting changes to disk. When the feature flag is enabled, writes must succeed on multiple nodes. Dissenting nodes are automatically brought in sync by asynchronous replication from the nodes that formed the quorum.
Gitaly[Display source branch name in merge request sidebar](https://docs.gitlab.com/ee/user/project/merge_requests/reviewing_and_managing_merge_requests.html#copy-the-branch-name-for-local-checkout):
> When reviewing code changes, discussions, and commits in a merge request, it is often desirable
> to checkout the branch locally for a more in-depth review. However, finding the branch name
> becomes harder as more content is added to the merge request description as more scrolling is
> necessary.
>
> The branch name has now been added to the merge request sidebar, making it easily accessible at
> all times and removing the need for scrolling. Just as the merge request reference, the source
> branch section provides a convenient "copy" button for easy local checkout.
>
> Many thanks to [Ethan Reesor](https://gitlab.com/firelizzard) for this great contribution.
Code Review[Emphasize collapsed diffs in merge request diffs](https://docs.gitlab.com/ee/user/project/merge_requests/reviewing_and_managing_merge_requests.html#collapsed-files-in-the-changes-view):
> Merge requests which apply changes to multiple files will sometimes collapse large file diffs in order to improve performance. When this happens, it's easy to overlook a file and not review it, especially in merge requests with many files.
> Starting with GitLab 13.4, the merge request will emphasize diffs containing collapsed files which will ensure those files are not missed by reviewers during the code review process. For added clarity, we are planning to highlight these files in a future release. Follow [gitlab#16047](https://gitlab.com/gitlab-org/gitlab/-/issues/16047) for updates.
Code Review[Warning on merge request diff when files are collapsed](https://docs.gitlab.com/ee/user/project/merge_requests/reviewing_and_managing_merge_requests.html#collapsed-files-in-the-changes-view):
> Collapsing large files on a merge request diff is done to enhance the performance
> and responsiveness of the diff section in a merge request. However, during code review,
> some files may be missed by the reviewer when scrolling through the list of files, because
> large files are collapsed.
>
> We have introduced a visible warning at the top of the merge request diff page, clearly
> informing the user that a file in the section is collapsed. This ensures all
> related changes in the merge request are reviewed.
Code Review[Edit front matter using the Static Site Editor](https://docs.gitlab.com/ee/user/project/static_site_editor/index.html):
> Front matter is a flexible and convenient way to define page-specific variables in data files intended to be parsed by a static site generator. It is commonly used for setting a page's title, layout template, or author, but can be used to pass any kind of metadata to the generator as the page renders out to HTML. Included at the very top of each data file, the front matter is often formatted as YAML or JSON and requires consistent and accurate syntax. Collaborators unfamiliar with the specific syntax rules can inadvertently introduce invalid markup that can in turn cause formatting issues or even build failures.
>
> The Static Site Editor's WYSIWYG editing mode already removes the front matter from the editor to prevent these formatting errors. However, that leaves you with no way to modify the values stored in the front matter without reverting to editing the raw source of the file. In GitLab 13.4, you can access and edit the values for each front matter field in a familiar form-based interface. Clicking the **Settings** button will reveal a panel that displays a form field for each key defined in the front matter. The fields are populated with the current value and editing any of them is as simple as typing into a web form. Editing front matter in this way allows you to avoid syntax complexities and gives you complete control over the content while ensuring the final output is formatted consistently.
Static Site Editor[Gitaly Cluster automatic repository repair](https://docs.gitlab.com/ee/administration/gitaly/praefect.html#data-recovery):
> When a primary Gitaly Cluster node went offline, repositories on the node were marked as read only to prevent data loss when there were changes that hadn't been replicated. If the node came back online, GitLab did not automatically recover and administrators had to manually trigger reconciliation, otherwise, you had to accept data loss. Other situations could also result in outdated or read only repositories, such as a replication job failing to be processed on a secondary node. In this case, the repository would stay out of date until another write came in and triggered a replication job.
>
> To address these situations, [Praefect](https://docs.gitlab.com/ee/administration/gitaly/praefect.html) now schedules a replication job when it detects an outdated repository on one node, but the latest version of the repository on a different node. This replication job brings the outdated repository up to date automatically, mitigating concerns about manual data recovery. Automatic repair also ensures that secondary nodes are brought back up to date quickly if a replication job has failed, rather than needing to wait for the next write to occur. Since many Gitaly clusters store a large number of repositories, this significantly reduces the time that administrators and site reliability engineers need to spend recovering data after a failover.
>
> In addition, automatic repair initiates replication of repositories to any new Gitaly node that is added to the cluster, removing the need for manual intervention when adding new nodes.
Gitaly[GitLab for Jira and DVCS Connector now in Core](https://docs.gitlab.com/ee/integration/jira/):
> For users of Jira GitLab, the [GitLab for Jira app](https://marketplace.atlassian.com/apps/1221011/gitlab-for-jira?hosting=cloud&tab=overview) and the [DVCS Connector](https://docs.gitlab.com/ee/integration/jira/dvcs.html)
> allow you to display information about GitLab
> commits and merge requests directly in Jira. Combined with our native
> integration with Jira, you can easily move back and forth between the
> two applications as you work.
>
> These features were previously available only in our Premium plan, but
> are now available to all users! 🎉
Integrations[Configuration file for the Static Site Editor](https://docs.gitlab.com/ee/user/project/static_site_editor/#set-up-your-project):
> In GitLab 13.4, we're introducing a new way to configure the Static Site Editor. While the configuration file doesn't store or retrieve any values in this release, we're laying the foundation for customization of the editor's behavior. In upcoming releases, we'll add values to `.gitlab/static-site-editor.yml` for setting the [site's base URL](https://gitlab.com/gitlab-org/gitlab/-/issues/241166), where [images uploaded from the editor are stored](https://gitlab.com/gitlab-org/gitlab/-/issues/216641), overriding Markdown syntax preferences, and other editor-specific settings.
Static Site Editor[Child pipelines can now trigger their own child pipelines](https://docs.gitlab.com/ee/ci/parent_child_pipelines.html):
> When using parent/child pipelines, it is now possible for child pipelines to trigger
> their own child pipelines. This added depth can be useful when you want the flexibility
> to generate a variable number of child pipelines.
>
> Before, with a parent/child configuration, every child pipeline needed a trigger
> job manually defined in the parent. Now you can generate child pipelines that dynamically
> trigger any number of new child pipelines. If you have a monorepo, for example, you
> can dynamically generate a first child pipeline that itself generates a variable
> number of new child pipelines, based on the changes in a branch.
Continuous Integration (CI)[Improved navigation between parent and child pipelines](https://docs.gitlab.com/ee/ci/parent_child_pipelines.html):
> Navigating between parent and child pipelines was a bit cumbersome, requiring multiple
> clicks. It also wasn't easy to tell which job triggered which child pipeline.
> It's now easier and faster to see how parent
> pipelines connect with their children.
Continuous Integration (CI)[Parallel matrix jobs show relevant variables in job name](https://docs.gitlab.com/ee/ci/yaml/#parallel-matrix-jobs):
> If you used [matrix jobs](https://docs.gitlab.com/ee/ci/yaml/#parallel-matrix-jobs), you probably noticed it was difficult to determine which matrix variables were used for each job, because the job names were formatted like `matrix 1/4`. In 13.4, you will now see the relevant variable values that were used in that job, instead of seeing a generic job name. For example, if you are building a debug target for x86 architecture, the job will now be named `matrix: debug x86`.
Continuous Integration (CI)[Show job data for Code Coverage value in MR](https://docs.gitlab.com/ee/ci/pipelines/settings.html#test-coverage-parsing):
> As a developer, you should be able to easily see code coverage after a pipeline finishes running, even in complex scenarios that make this more difficult, like when your pipeline has multiple jobs that are parsed to calculate the coverage value. Until now, the Merge Request widget only showed the average of those values, which meant you had to navigate to the jobs page and then back to the Merge Request itself to get more granular details for the coverage value. To save you time and eliminate those extra steps, you're now presented with the average coverage value, how it has changed from the target and source branch, and a tooltip that shows the coverage for each job used to calculate the average.
Code Testing and Coverage[Lock the latest job artifact to prevent deletion](https://docs.gitlab.com/ee/ci/yaml/#artifactsexpire_in):
> GitLab will now automatically lock the latest artifact of a successful job and pipeline on any active branch, MR, or tag to prevent it from being deleted based on expiration. This makes it easier to set a more aggressive expiration policy to clean up older artifacts, helps reduce disk space consumption, and ensures you've always got a copy of the latest artifact from your pipeline.
Continuous Integration (CI)[GitLab Runner 13.4](https://docs.gitlab.com/runner):
> We’re also releasing GitLab Runner 13.4 today! GitLab Runner is the lightweight, highly-scalable agent that runs your build jobs and sends the results back to a GitLab instance. GitLab Runner works in conjunction with GitLab CI/CD, the open-source continuous integration service included with GitLab.
>
> #### What's new:
>
> - [Use secrets stored in a Hashicorp Vault server for CI/CD job variables](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26565)
> - [Use Azure Blob Storage for runner cache](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/6612)
> - [Add `userns_mode` support for Gitlab CI services](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/6221)
> - [Allow overwriting Service container resources for Kubernetes executor](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/25317)
> - [Allow overwriting Helper container resources for Kubernetes executor](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/25318)
> - [Add Kubernetes node affinities settings](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/2324)
>
> #### Bug fixes:
>
> - Fix: [File-type variable has byte order mark when using PowerShell](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4818)
> - Fix: [Docker authentication random behavior](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26778)
> - Fix: [Docker windows Git cloning](https://gitlab.com/gitlab-org/gitlab/-/issues/239013)
>
> The list of all changes is in the GitLab Runner [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/13-4-stable/CHANGELOG.md).
GitLab Runner[Test Report Sorted by Test Status](https://docs.gitlab.com/ee/ci/unit_test_reports.html):
> The [Unit Test Report](https://docs.gitlab.com/ee/ci/unit_test_reports.html) is an easy way to see results from all tests in a pipeline. However, if there are a large number of tests, it can be time consuming to find the failing tests. Other problems that made the report hard to use include difficulty scrolling long trace output, and data often rounding down to 0 for tests running in less than 1 second.
> Now, by default the Test Report sorts the failed tests to the top of the report first, then by duration. This makes finding failures and long running tests easier. Also, the duration of tests now displays in milliseconds or seconds so it is much quicker to read and the previous issues with scrolling have also been resolved.
Code Testing and Coverage[Directed Acyclic Graph (DAG) relationship limit increased to 50](https://docs.gitlab.com/ee/ci/yaml/#needs):
> If you're using [Directed Acyclic Graph (DAG) pipelines](https://docs.gitlab.com/ee/ci/directed_acyclic_graph/), you might have found that the limit of 10 jobs that a job can list in `needs:` is insufficient. In 13.4, the default limit was raised from 10 to 50 to allow for more complicated networks of relationships between jobs in your pipelines.
>
> If you are an administrator for a self-managed instance, you can make this even higher by adjusting a feature flag setting, though we don't offer official support for this.
Continuous Integration (CI)[Pipeline efficiency guide for CI/CD](https://docs.gitlab.com/ee/ci/pipelines/pipeline_efficiency.html):
> Optimizing your CI/CD pipeline runs can result in improved speed and cost-savings.
> We've improved our documentation with a short guide on how to
> get the most out of optimizing your pipelines.
Continuous Integration (CI)[Improved troubleshooting guide for CI/CD](https://docs.gitlab.com/ee/ci/troubleshooting.html):
> We have improved the GitLab CI/CD troubleshooting guide with additional information on common
> issues you might run into. We hope the improved documentation is a valuable resource to help you get up and running quickly and easily with GitLab CI/CD.
Continuous Integration (CI)[Improved the behavior of `needs` with skipped jobs](https://docs.gitlab.com/ee/ci/yaml/#needs):
> In certain edge cases, it was possible for a skipped job in your pipeline to be considered successful for `needs` dependencies, which allowed later jobs to run that shouldn't have. This is fixed in 13.4, and the behavior of skipped jobs is now handled properly by `needs`.
Continuous Integration (CI)[Scope Conan packages to a project](https://docs.gitlab.com/ee/user/packages/conan_repository/#project-level-remote):
> You can use the GitLab Conan Repository to publish and share C/C++ dependencies. However, packages could previously only be scoped to the instance. This was problematic because Conan package names must be 51 characters or fewer. For anyone trying to publish a package that lived within a sub-group, like `gitlab-org/ci-cd/package-stage/feature-testing/conan`, it was nearly impossible to use this feature.
>
> Now you can scope your Conan packages to a project, making it easy to publish and share your project's dependencies.
Package Registry[Delete Package Registry packages while viewing a group](https://docs.gitlab.com/ee/user/packages/package_registry/#delete-a-package):
> The GitLab Package Registry is where you store and share a variety of package formats. When your project or group has a large number of packages, you want to quickly identify unused packages and delete them, to prevent people from installing the wrong package. You can delete packages from your registry by using the [Packages API](https://docs.gitlab.com/ee/api/packages.html) or from the Package Registry user interface. However, until recently, you could not delete packages when viewing a group in the UI. As a result, you were forced to delete packages for each project, which was inefficient.
>
> Now you can delete packages while you're viewing the Package Registry for a group. Simply navigate to your group's Package Registry, filter by package name, and delete any unwanted packages.
Package Registry[Limits for file size uploads to the Package Registry](https://docs.gitlab.com/ee/administration/instance_limits.html#file-size-limits):
> There are now limits that restrict the size of package files that can be uploaded to the GitLab Package Registry. The limits were added to prevent abuse and optimize the performance of the Package Registry. The limits vary by package format. For GitLab.com, the maximum file sizes are:
>
> - Conan: 250MB
> - Maven: 3GB
> - NPM: 300MB
> - NuGet: 250MB
> - PyPI: 3GB
>
> For self-managed instances, the defaults are the same. However, an administrator can update the limits by using the [Rails console](https://docs.gitlab.com/ee/administration/instance_limits.html#file-size-limits).
Package Registry[Use CI_JOB_TOKEN to publish PyPI packages](https://docs.gitlab.com/ee/user/packages/pypi_repository/#using-gitlab-ci-with-pypi-packages):
> You can use the GitLab PyPI Repository to build, publish, and share python packages, right alongside your source code and CI/CD Pipelines. However, previously you couldn't authenticate with the repository by using the pre-defined environment variable `CI_JOB_TOKEN`. As a result, you were forced to use your personal credentials for making updates to the PyPI Repository, or you may have decided not to use the repository at all.
>
> Now it is easier than ever to use GitLab CI/CD to publish and install PyPI packages by using the predefined `CI_JOB_TOKEN` environment variable.
Package Registry[Preview new metrics charts in the user interface](https://docs.gitlab.com/ee/operations/metrics/dashboards/#add-a-new-metrics-panel-to-a-dashboard):
> Previously, creating a chart in your GitLab metrics dashboard was challenging. After you defined a chart in the dashboard YAML file, you committed the changes to `master` without knowing the newly-created chart was what you wanted. Since GitLab 13.3, you can preview a panel's YAML as the chart is created, getting you early feedback before committing the changes to your dashboard's YAML file.
Metrics[Highlight critical alert details on incidents](https://docs.gitlab.com/ee/operations/incident_management/incidents.html#incident-details):
> When triaging incidents, it should be easy for you to identify how long an alert has been open and how many times the event has fired. These details are often critical when determining customer impact and what your team needs to respond to right now. In the new incident highlight bar, we surface the alert start time, events count, and a link to the originating alert front and center. This information is available on incidents that are promoted from alerts.
Incident Management[Reference GitLab alerts in Markdown](https://docs.gitlab.com/ee/operations/incident_management/index.html):
> We improved alerts by adding an alert-specific reference in GitLab-flavored Markdown, making it easy for you to share and reference alerts. Use `^alert#1234` to reference an alert in any Markdown field in incidents, issues, or merge requests. This alert reference also helps you identify to-dos resulting from alerts, rather than issues or merge requests!
Incident Management[Create incidents as a type of issue](https://docs.gitlab.com/ee/operations/incident_management/manage_incidents.html#from-the-issues-list):
> Not every problem that arises triggers an alert first: customers report outages, and team members identify performance problems. Incidents are now a type of issue, so your team members can quickly create incidents through a familiar workflow. Click **New Issue** from anywhere within GitLab, and in the **Type** field, select **Incident**.
Incident Management[Set and edit incident severity](https://docs.gitlab.com/ee/operations/incident_management/incidents.html):
> An incident's severity tells responders and stakeholders the impact of an outage, and the methods and urgency needed for responses. As your team shares findings during the fire-fight and remediates the outage, they can edit the incident's severity. You can now edit the severity of the incident in the right-hand sidebar of the Incident Details page, and the severity is displayed in the incident list.
Incident Management[View alert payload on incidents](https://docs.gitlab.com/ee/operations/incident_management/incidents.html#incident-details):
> An alert's payload contains critical information to diagnosing outages and restoring service, and this information must be easily accessible so you don't need to switch tools or tabs when working to resolve the incident. Incidents created from alerts display the alert's full payload in the **Alert Details** tab.
Incident Management