GitLab.org/GitLab: Release v13.0.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 13.0
Released: 2020-05-22
License: MIT
Release Assets:
[Okta SCIM Integration Application for GitLab.com](https://docs.gitlab.com/ee/user/group/saml_sso/scim_setup.html#okta-configuration-steps) (SaaS only):
> We now offer an Okta SCIM integration application for Gitlab.com groups! When Okta SCIM is provisioned for a GitLab group, membership of that group is synchronized between GitLab and Okta.
> This reduces group administrator time spent to onboard and offboard users.
Authentication and Authorization, Users[Implement a deployment freeze with the Freeze Period API](https://docs.gitlab.com/ee/api/freeze_periods.html):
> In this milestone, GitLab introduces more controls for environments. With the Freeze Period API, you can easily prevent an unintended production release during a period of time specified by you, whether it is a large company event or holiday. You can now rely on the enforcement of policies that are typically outside the scope of GitLab to reduce uncertainty and risk while automating deployments.
Release Orchestration[View Epic hierarchy on a Roadmap](https://docs.gitlab.com/ee/user/group/roadmap/):
> When leveraging Multi-Level Epics, it can be difficult to keep track of where each child epic lives on the Roadmap. You can now quickly expand
> a parent epic on your roadmap to view all its child epics to ensure work is properly organized and your planned timeline is on track!
Roadmaps, Epics[Standalone Vulnerability Objects](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/index.html):
> We are excited to announce the first feature release for Vulnerability
> Management, standalone vulnerability objects. With this release, we’ve
> implemented a new vulnerability object model, enabling a whole new set
> of capabilities that span the entire lifecycle of vulnerability
> management.
>
> One of the biggest benefits is each vulnerability occurrence will now
> have a unique URL, meaning a vulnerability can be directly linked to,
> shared, referenced, and tracked as the Single Source of Truth. On this page, you can change the status of a vulnerability to Detected, Confirmed, Dismissed, or Resolved. Another
> benefit is vulnerability occurrences will persist across scanner runs.
> Previously, running scans on the same branch would overwrite any
> previous findings with the new results. Persisting vulnerabilities will
> improve tracking, visibility, and cut down on duplication of findings
> between runs. It also enables the future ability to report on group and
> project vulnerability trends over time across a broad range of
> variables.
Vulnerability Management[REST API support for DAST scans](https://docs.gitlab.com/ee/user/application_security/dast/#api-scan):
> GitLab 13.0 supports DAST scans of REST APIs. This allows for full DAST security coverage of an application, not just the UI. By supporting use of an OpenAPI specification as a guide for what URLs and REST endpoints need to be scanned, DAST helps secure an application's entire attack surface and provides more insight into the potential vulnerabilities of any running application.
DAST[SAST for .NET Framework](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks):
> We're introducing initial support for .Net Framework which will allow developers to enable [SAST Security Scans](https://docs.gitlab.com/ee/user/application_security/sast/#overview) on additional types of .NET projects. Like our other SAST jobs, this will use Linux GitLab Runners. We plan to expand support to GitLab Windows Runners in a future release. Since introduction in GitLab 11.0, [SAST for .NET](https://gitlab.com/gitlab-org/gitlab/issues/4824) only contained support for .NET Core projects.
>
> | [Supported Language](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) | Scan tool | Introduced in GitLab Version |
> | ------ | ------ | ------ |
> | .NET Core | [Security Code Scan](https://security-code-scan.github.io) | 11.0 |
> | .Net Framework | [Security Code Scan](https://security-code-scan.github.io) | 13.0 |
SAST[Secret Detection for the Full History of a Repository](https://docs.gitlab.com/ee/user/application_security/secret_detection/#full-history-secret-scan):
> GitLab 13.0 updates our [Secret Detection Security Scanning](https://docs.gitlab.com/ee/user/application_security/secret_detection/) to support a new configuration variable ([`SAST_GITLEAKS_HISTORIC_SCAN`](https://docs.gitlab.com/ee/user/application_security/secret_detection/#full-history-secret-scan)) to allow scanning the full history of a repository. This allows you to identify historical secrets that might be hiding in your older git commit history. Since introduction in [GitLab 11.9](https://about.gitlab.com/releases/2019/03/22/gitlab-11-9-released/#detect-secrets-and-credentials-in-the-repository), Secret Detection scanned the commit history of changes in a merge request. This would detect new secrets but would not identify secrets in the repository's older git history. This new functionality is particularly useful when you are enabling Secret Detection in a repository for the first time and you want to perform a full secret scan.
>
> We have created a [short video walkthrough](https://youtu.be/wDtc_K00Y0A) showcasing how you can perform a historical secret scan via [scheduled pipeline](https://docs.gitlab.com/ee/ci/pipelines/schedules.html) or with a [manual pipeline](https://docs.gitlab.com/ee/ci/pipelines/#run-a-pipeline-manually).
Secret Detection[View DAST Scanned Resources List](https://docs.gitlab.com/ee/user/application_security/dast/#list-of-urls-scanned):
> DAST analyzes your running web application for known runtime vulnerabilities, starting with each merge request. DAST scans many resources, but knowing precisely which ones was not possible before.
>
> GitLab 13.0 presents a full list of the resources that DAST scanned. You can now evaluate DAST scans to ensure all necessary application surfaces are covered. For further ease of analysis, you can download scan lists directly from the results screen.
DAST[Export vulnerabilities list from Instance and Project Security Dashboards](https://docs.gitlab.com/ee/user/application_security/security_dashboard/#export-vulnerabilities-1):
> We're pleased to announce the initial release of exportable vulnerability
> lists from the [Instance Security Dashboard](https://gitlab.com/gitlab-org/gitlab/-/issues/213014) and [Project Security Dashboard](https://gitlab.com/gitlab-org/gitlab/-/issues/197494).
> While the Security Dashboards let users manage vulnerabilities as part of
> the GitLab workflow, it hasn't been as easy to get a list of this information
> for external use.
>
> You can now download a CSV file containing the detected vulnerabilities
> for a given project or all projects configured on the Instance Security
> Dashboard. This export list can then be used for things such as creating
> compliance reports or as a data source for external dashboards.
> Simply go to the instance Security Dashboard or any [project’s Security Dashboard](https://docs.gitlab.com/ee/user/application_security/security_dashboard/index.html#export-vulnerabilities) and click the new Export
> button in the upper-right or go to the Security option under the More menu
> in the top navigation bar, then click the new Export button in the
> upper-right. Your browser will automatically start the download.
Vulnerability Management[Live Information about Vulnerability Database](https://docs.gitlab.com/ee/user/application_security/sast/#vulnerabilities-database-update):
> We know that understanding what GitLab scans for is important to ensure
> that you feel safe. With this release, we are introducing a [new page](https://advisories.gitlab.com)
> to give you more information about the vulnerability database our
> scanners use.
>
> From this page, you can get information about what we are scanning for,
> when we last updated our database, and also look up specific
> vulnerabilities you are concerned about.
Vulnerability Database[Container Network Policies SIEM Integration](https://docs.gitlab.com/ee/user/clusters/applications.html#fluentd):
> We're pleased to announce a new SIEM integration for Container Network Policies!
> The integration allows users to export their Cilium logs to a SIEM or central logging solution
> so they can review any anomalies detected by their Network Policies. This visibility into the logs also
> helps users to test and tune their Network Policies to reduce false positive rates. The SIEM
> integration can be configured on the **Operations > Kubernetes** page.
Container Network Security[Emojis render on status page](https://docs.gitlab.com/ee/operations/incident_management/status_page.html#incident-detail-page):
> GitLab issues support emojis in the issue title and all Markdown fields. When you publish a Gitlab issue to a public URL as a [status page](https://docs.gitlab.com/ee/operations/incident_management/status_page.html), the status page now supports and renders emojis used in issue titles, descriptions, and comments.
Alert Management[Status pages anonymized](https://docs.gitlab.com/ee/operations/incident_management/status_page.html#publishing-incidents):
> When an incident response team shares incident updates and status changes, the incident description is published publicly, but all user and group names in issue descriptions are anonymized to protect the privacy of individuals and teams.
Alert Management[Filtered search for instance-level audit events](https://docs.gitlab.com/ee/administration/audit_events.html):
> When you need to find a specific event, either for audit reporting or to investigate incidents, it should be easy. It shouldn't require a lot of time to manually dig through a large data set.
>
> Now, you can perform filtered searches on a single object, e.g., a user, group, or project in the instance-level audit events table to make this process much easier. This feature is available for self-managed customers only, but will be extended to groups and projects as part of a [the larger epic](https://gitlab.com/groups/gitlab-org/-/epics/3179) to make the instance, group, and project-level audit events experiences uniform and much friendlier to use.
Audit Events[Value Stream Analytics | Lead time, cycle time metrics](https://docs.gitlab.com/ee/user/analytics/value_stream_analytics.html#how-time-metrics-are-measured):
> Two key value stream metrics now give teams a baseline against which process improvement efforts may be measured so that they may more easily see the impact of process changes. Lead time measures the elasped time between a requested item and its delivery. Cycle time measures the length of the development cycle itself. By optimizing flow across the entire value stream, teams avoid moving a problem from one place to another and ship faster.
Value Stream Management[Value Stream Analytics | Tasks by Type](https://docs.gitlab.com/ee/user/analytics/value_stream_analytics.html#type-of-work---tasks-by-type-chart):
> This powerful new chart allows teams to see how delivery is distributed across different types of work. Use labels to see how many features are delivered vs. bugs from release to release, or how many items a given team ships vs. another. By reflecting on the distribution of work delivered through the value stream, teams can tune their processes to better align with strategic objectives or better balance resources across teams.
Value Stream Management[Group-level push rules](https://docs.gitlab.com/ee/user/group/index.html#group-push-rules-starter):
> Push rules provide additional control over what can and can’t be pushed to your repository. They allow you to create custom operational standards that align with your organizational policies.
>
> Previously, push rules could only be set at the instance or project level, forcing admins to manage large numbers of people and projects independently. New group-level push rules will allow group owners a way to govern policy in a central location, while still providing individual project owners with flexibility.
Compliance Management[API support for Feature Flag lists](https://docs.gitlab.com/ee/api/feature_flag_user_lists.html):
> As part of our support for [Feature Flag lists](https://gitlab.com/gitlab-org/gitlab/-/issues/13308), we have added API support to enable creating, editing, and deleting them. This will make it easier to automate the management and synchronization of these lists between different systems.
Continuous Delivery[Geo secondaries automatically forward SSH requests for unsynchronized repositories](https://docs.gitlab.com/ee/administration/geo/replication/configuration.html#git-operations-on-unreplicated-respositories) (self-managed only):
> Geo supports [selective
> synchronization](https://docs.gitlab.com/ee/administration/geo/replication/configuration.html#selective-synchronization)
> of projects, which allows systems administrators to choose a subset of
> data that is replicated to a secondary Geo node. Geo already supports
> redirecting HTTP(S) requests to the primary when trying to access these
> unsynchronized repositories. However, users trying to access
> unsynchronized repositories on a secondary node via SSH would receive an
> error that the repository was not available. This was confusing for
> users and forced them to either wait for the repository to synchronize
> or do extra work to connect to the right repository.
>
> In GitLab 13.0, any Git requests made via SSH to an unsynchronized
> secondary Geo node will be forwarded to the primary node. This results
> in a much more seamless user experience because users won't need to know
> what is or isn't replicated to this node - Geo will fulfill the request
> both via HTTP(S) and SSH without any additional configuration.
Geo-replication[Improved Geo replication performance for Job Artifacts, Uploads and LFS files](https://docs.gitlab.com/ee/administration/geo/index.html) (self-managed only):
> To determine what needs to be replicated from the primary, Geo compares the tracking database to the read-only secondary database. If Geo’s
> database queries time out, data can’t be replicated successfully. In
> GitLab 13.0, we use a [new approach to synchronize Job Artifacts and
> Uploads](https://gitlab.com/gitlab-org/gitlab/-/issues/210525), thereby
> eliminating the possibility of database statement timeouts. We also
> [improved the database query performance to retrieve Job Artifacts, LFS
> Objects, and Uploads when these files are stored
> locally](https://gitlab.com/gitlab-org/gitlab/-/issues/213382), which
> increases the overall scalability and performance of GitLab Geo.
>
> These iterations bring us closer to removing Geo's dependency on
> [Foreign Data
> Wrappers](https://wiki.postgresql.org/wiki/Foreign_data_wrappers), which
> were added for improved performance, but makes Geo more complex and
> harder to maintain.
Geo-replication, Disaster Recovery[Geo improvements to the administrator interface](https://docs.gitlab.com/ee/administration/geo/replication) (self-managed only):
> As GitLab grows, Geo continues to support replication for additional
> resources. This in turn increases the number of status pages that are
> shown in the sidebar. This approach does not scale well and makes it
> harder for systems administrators to find what they need. In GitLab
> 13.0, we [merged the sub-pages for Projects, Uploads and Designs into a
> single view](https://gitlab.com/gitlab-org/gitlab/-/issues/213219) that
> can be accessed via a single sidebar entry "Replication". This change
> groups all the information in one place and helps systems administrators
> access the replication status of individual items.
>
> Additionally, we've made a few other user experience improvements to the
> administrator interface:
>
> - [Made selective-sync settings more visible on the index page](https://gitlab.com/gitlab-org/gitlab/-/issues/11165)
> - [Display the last data update as part of the health status](https://gitlab.com/gitlab-org/gitlab/-/issues/211862) to make it more prominent
> - [Added empty state illustrations and help texts](https://gitlab.com/gitlab-org/gitlab/-/issues/200014) to guide users
> - [Modified the width of the Geo settings](https://gitlab.com/gitlab-org/gitlab/-/issues/215344) to conform with our design system
Geo-replication, Disaster Recovery[Raise warning when closing an issue with open blockers](https://docs.gitlab.com/ee/user/project/issues/related_issues.html):
> In GitLab 12.8, we [introduced](https://about.gitlab.com/releases/2020/02/22/gitlab-12-8-released/#blocking-issue-support) the ability to create dependencies between issues, where one issue can block another related issue. This means that the downstream issue should not be closed until the predecessor is completed and closed. This required you to check to see if an issue is blocked before you closed it.
>
> Having to check if an issue is blocked prior to closing the issue is an
> additional step that is unnecessary and easy to forget.
>
> We've eliminated that step by showing you a warning if you attempt to
> close an issue with unresolved blockers. We also provide links
> to the blocking issues so you can verify that your issue is safe to
> close.
>
> This level of increased dependency alerts helps keep projects running
> smoothly, and ensures that sequencing of issues can be maintained!
Issue Tracking[View Milestones on the Roadmap](https://docs.gitlab.com/ee/user/group/roadmap):
> Accurately tracking the status of work in flight is a must to help keep teams on track. Now, when viewing your
> roadmap, you can view how your epics line up with your various milestones helping you better understand
> when work will land, and identify if projects are ahead or behind expectations.
Roadmaps[Approved-by filter for merge requests](https://docs.gitlab.com/ee/user/search/#filtering-merge-requests-by-approved-by-starter):
> Merge Request Approvals require specific people to approve changes before they can be merged.
> When searching the merge request list, you can quickly find which merge requests need your
> approval using the **Approvers** filter. In GitLab 13.0, you can now also find any merge requests
> you previously approved using the new **Approved-By** filter.
Code Review[Support parent/ancestor groups and users in CODEOWNERS file](https://docs.gitlab.com/ee/user/project/codeowners/#the-syntax-of-code-owners-files):
> Groups can be used for organizing users in GitLab. This makes it easy to share projects,
> mention in comments, or assign as merge request approvers without selecting them one at a time.
>
> Groups and users can be assigned as code owners, but ancestor groups could not be used.
> This meant assigning a parent group from the project hierarchy as a code owner had no effect.
>
> GitLab 13.0 introduces the ability to include users and groups from a parent or ancestor group in a
> project's `CODEOWNERS` file, providing more flexibility when specifying Code Owners'
> rules.
Source Code Management, Code Review[Configurable browser performance testing threshold](https://docs.gitlab.com/ee/user/project/merge_requests/browser_performance_testing.html#configuring-degradation-threshold):
> [Browser Performance Testing](https://docs.gitlab.com/ee/user/project/merge_requests/browser_performance_testing.html) allows users to easily detect when there is a degradation in their web app before merging to master. In many cases this causes extra noise and clutters up the Merge Request page unnecessarily, even for minor changes.
> In this milestone, you can now set an optional degradation threshold as a requirement that must be met before the Performance report will be displayed.
Web Performance[Setting to allow Deploy tokens to read and write to the GitLab Package Registry](https://docs.gitlab.com/ee/user/project/deploy_tokens/#limiting-scopes-of-a-deploy-token):
> Deploy Tokens allow you to access your group's repositories, project's repositories, and container registries. Historically, the defined scopes of `read_repository`, `read_registry`, and `write_registry` have not allowed you to grant access to the GitLab Package Registry. As a result, DevOps teams have used insecure or expensive user-based workarounds.
>
> In GitLab 13.0, we are excited to announce more granular permissions for GitLab Deploy Tokens. You can now set read or write access for the Package Registry. You can also create and manage Deploy Tokens from within the GitLab application or by using the [API](https://docs.gitlab.com/ee/api/deploy_tokens.html).
Package Registry[View more robust data in the list view Package Registry user interface](https://docs.gitlab.com/ee/user/packages/#view-packages):
> Before this release, the Package Registry list view showed a limited amount of information related to the packages in the UI. While this information is important, it lacked key metadata such as version, branch, and commit.
>
> In 13.0, we've updated the design of this page to include additional metadata to help you find the package you are looking for and verify it was built properly. In addition to the package name, you can now see version, type, and more. Check out the video for an example or start using the feature today.
Package Registry[Package versions are now nested under their parents](https://docs.gitlab.com/ee/api/packages.html#get-a-project-package):
> The GitLab Package Registry has been treating each new version of a package as a *new* package. This has made it difficult to find the package you are looking for or to understand what has changed from version to version.
>
> In GitLab 13.0, we are excited to announce that each version of a package will now be nested under its uniquely-named parent. This will make it easier to find the package you are looking for in the UI and to better understand what has changed from version to version. This change applies to both the group and project-level views of the Package Registry. In addition, when using the [Packages API](https://docs.gitlab.com/ee/api/packages.html), versions will now be returned as an array within the parent package.
Package Registry[View all of your Python packages in one place with the GitLab Package Registry](https://docs.gitlab.com/ee/user/packages/pypi_repository/index.html):
> The GitLab Package Registry user interface allows you to confirm that your packages have been built properly and troubleshoot when something has gone wrong. However, the MVC of the new PyPI Repository that launched in 12.10 did not include this functionality.
>
> In 13.0, we've added the PyPI Repository to the Package Registry UI. Now, you can view and download your project or group's PyPI packages and reference metadata to validate that the package was built properly. You can also quickly copy setup and install commands for more efficient sharing and coding. If the package was built using a GitLab pipeline, you'll be able to view and link it to the pipeline, as well as the commit that was used to publish the package.
Package Registry[Auto Deploy to ECS](https://docs.gitlab.com/ee/topics/autodevops/index.html#aws-ecs):
> Until now, there hasn't been a simple way to deploy to Amazon Web Services. As a result, GitLab users had to spend a lot of time figuring out their own configuration.
>
> In GitLab 13.0, Auto DevOps has been extended to support deployment to AWS! GitLab users who are deploying to AWS Elastic Container Service (ECS) can now take advantage of Auto DevOps, even if they are not using Kubernetes. Auto DevOps simplifies and accelerates delivery and cloud deployment with a complete delivery pipeline out of the box. Simply commit code and GitLab does the rest! With the elimination of the complexities, teams can focus on the innovative aspects of software creation!
>
> In order to enable this workflow, users need to define AWS typed environment variables: `AWS_ACCESS_KEY_ID`, `AWS_ACCOUNT_ID` and `AWS_REGION`, and enable Auto DevOps. Then, your ECS deployment will be automatically built for you with a complete, automatic, delivery pipeline.
Continuous Delivery[Review summary of `terraform plan` in Merge Requests](https://docs.gitlab.com/ee/user/infrastructure/):
> If you use Terraform to define your infrastructure as code, you know the pain of having to pass around the resulting changes from your `terraform plan` command in slack and MR comments. In GitLab 13.0, you can now see the summary of your `terraform plan` command in the context where it is most useful, directly in your merge request. This helps you to more quickly verify your infrastructure changes and gives you a place to collaborate with your team members on the intended effects of your infrastructure as code changes.
>
> Users of the [Terraform template provided by GitLab](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Terraform.gitlab-ci.yml) will see the `terraform plan` merge request widget without additional configuration. Users of customized CI/CD templates for Terraform can update their template to use the image and scripts in the [official GitLab Terraform template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/Terraform.gitlab-ci.yml).
Infrastructure as Code[GitLab HTTP Terraform state backend](https://docs.gitlab.com/ee/user/infrastructure/):
> Users of Terraform know the pain of setting up their state file (a map of your configuration to real-world resources that also keeps track of additional metadata). The process includes starting a new Terraform project and setting up a third party backend to store the state file that is reliable, secure, and outside of your git repo.
>
> Many users wanted a simpler way to set up their state file storage without involving additional services or setups. Starting with GitLab 13.0, GitLab can be used as an HTTP backend for Terraform, eliminating the need to set up state storage separately for every new project.
>
> The GitLab HTTP Terraform state backend allows for a seamless experience with minimal configuration, and the ability to store your state files in a location controlled by the GitLab instance. They can be accessed using Terraform's [HTTP backend](https://www.terraform.io/docs/backends/types/http.html), leveraging GitLab for authentication. Users can migrate to the GitLab HTTP Terraform backend easily, while also accessing it from their local terminals.
>
> The GitLab HTTP Terraform state backend supports:
>
> * Multiple named state files per project
> * Locking
> * Object storage
> * Encryption at rest
>
> It is available both for GitLab Self-Managed installations and on GitLab.com.
Infrastructure as Code[Reduced memory consumption of GitLab with Puma](https://docs.gitlab.com/ee/administration/operations/puma.html) (self-managed only):
> Puma is now the default web application server for both the Omnibus-based and Helm-based installations. Puma reduces the memory footprint of GitLab by about 40% compared to Unicorn, increasing the efficiency of GitLab and potentially saving costs for self-managed instances.
>
> Installations which have customized the number of Unicorn processes, or use a slower NFS drive, may have to adjust the default Puma configuration. See the [Important notes on upgrading](#upgrade) and [GitLab chart improvements](#gitlab-helm-chart-improvements) for additional details.
Omnibus Package, Cloud Native Installation[Enable group-level default branch protection](https://docs.gitlab.com/ee/user/group/index.html#changing-the-default-branch-protection-of-a-group):
> Previously, the translation of instance-level [default branch protection](https://gitlab.com/gitlab-org/gitlab/issues/7583) settings down into projects was confusing because, in certain scenarios, it created an unintuitive experience: developers could not push new commits to projects they could create. This made it difficult for organizations to strike a balance between mitigating risk and allowing carte blanche access to projects for all developers since the workaround required promoting them to Maintainer.
>
> Now, default branch protection can be set at the group level to provide better flexibility for administrators and group owners. Using a combination of default branch protection and default project creation settings, organizations can [find the right mix](https://gitlab.com/gitlab-org/gitlab/-/issues/7583#note_288469003) of autonomy and control, such as using custom default branch protection and allowing only maintainers to create new projects. This would allow developers to push new commits (not force push or delete a branch) to new projects, but allow maintainers to control project creation.
>
> This group-level configuration of default branch protection can [be disabled](https://docs.gitlab.com/ee/administration/settings/visibility_and_access_controls.html#disable-group-owners-from-updating-default-branch-protection) for organizations requiring more strict controls in place. By disabling the group-level setting for default branch protection, maintainers can apply more stringent controls on developer access and permissions.
Compliance Management[Email notification for unknown sign-ins](https://docs.gitlab.com/ee/user/profile/unknown_sign_in_notification.html):
> Users will now receive an email notification when a sign-in using their credentials occurs from a new IP address or device. This new functionality helps users quickly identify potential malicious activity related to their accounts.
Authentication and Authorization[Export and Import Groups in the UI](https://docs.gitlab.com/ee/user/group/settings/import_export.html):
> Previously, users could only migrate groups by using the [Export/Import API](https://gitlab.com/groups/gitlab-org/-/epics/1952) to create an Export file, then using the API a second time to upload the file to the target instance.
>
> As a first step toward a more frictionless solution, we have enabled Group Export in the GitLab UI. We plan to introduce similar [Import functionality](https://gitlab.com/gitlab-org/gitlab/-/issues/211807) to the UI within the next few weeks.
Importers[Update Release's milestone in Web UI](https://docs.gitlab.com/ee/user/project/releases/#edit-a-release):
> GitLab's Release Management team is working on expanding the Release Page to include all the Release API's functionality. In 13.0, it is now easier to add a single or multiple milestones to your Releases. With this addition, you no longer have to manually call the Release API to take advantage of planning features, such as the Release Progress View, which was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/31289) in 12.9.
Release Orchestration[Use Cloud Native Buildpacks for Auto DevOps (beta)](https://docs.gitlab.com/ee/topics/autodevops/stages.html#auto-build-using-cloud-native-buildpacks-beta):
> [Cloud Native Buildpacks](https://buildpacks.io/) are the next iteration of buildpacks. While GitLab currently defaults to Herokuish buildpacks, we intend to move Auto DevOps to Cloud Native Buildpacks when the project matures, to provide a future-proof and well-maintained solution to our users. With this release, you can opt in to use the beta for Cloud Native Buildpacks in Auto DevOps pipelines by setting the `AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLED` CI variable.
Auto DevOps[GitLab Helm chart improvements](https://docs.gitlab.com/charts/) (self-managed only):
> - The Helm chart now supports configuration of multiple Redis instances. This allows you to have different Redis instances for different storage types, for use with our [10,000 users Reference Architecture](https://docs.gitlab.com/ee/administration/reference_architectures/10k_users.html). For details on specific changes, refer to the [issue](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/1644).
> - Now that Puma is the [default web application server](#reduced-memory-consumption-of-gitlab-with-puma), with the option to still switch back to using Unicorn, the name of the Unicorn chart has changed from `unicorn` to `webservice`. For configuration details, see the [Charts documentation](https://docs.gitlab.com/charts/charts/gitlab/webservice/index.html).
> - The ConfigMap entries for `puma.rb` and `unicorn.rb` files have been removed in favor of environment variables. Please note that if you have modified the `unicorn.rb` from the ConfigMap (via Helm + Kustomize) in the past, you will be impacted by this change. We are doing this to eliminate maintaining two copies of these files. Until now, the `puma.rb` and `unicorn.rb` files were static within the `gitlab-webservice` container and overwritten by ConfigMap items from the `gitlab/unicorn` chart. For details on the new environment variables, refer to [the associated merge request](https://gitlab.com/gitlab-org/build/CNG/-/merge_requests/430).
> - The version of Ruby used by the GitLab Helm chart has been updated to 2.6.6.
Cloud Native Installation[PostgreSQL 11 is now the minimum required version to install GitLab](https://docs.gitlab.com/omnibus/settings/database.html) (self-managed only):
> The minimal required version of PostgreSQL for all self-managed installations is now PostgreSQL 11. PostgreSQL versions 9.6 and 10 have been removed in GitLab 13.0. This update allows us to start introducing performance improvements based on [the partitioning features that were added in PostgreSQL 11](https://www.postgresql.org/about/news/1894/). We plan to support PostgreSQL 11 for the entire duration of the GitLab 13.x series of releases. Support for PostgreSQL 12 [will be added in the near future](https://gitlab.com/groups/gitlab-org/-/epics/2374). See [Important notes on upgrading](#upgrade) for PostgreSQL-related upgrade guidelines.
Omnibus Package, Cloud Native Installation[Omnibus improvements](https://docs.gitlab.com/omnibus) (self-managed only):
> - The minimum required version of PostgreSQL is now PostgreSQL 11. See [the PostgreSQL 11 announcement](#postgresql-11-is-now-the-minimum-required-version-to-install-gitlab) for more details.
> - In Redis 5, the terminology for `slave` was changed to `replica`. In GitLab 13.0, this change was made in the Redis configuration in Omnibus. See [Important notes on upgrading](#upgrades) for upgrade instructions.
> - GitLab 13.0 includes [Mattermost 5.22](https://mattermost.com/blog/mattermost-5-22-read-only-channels-channel-moderation-settings-in-e20/), an [open source Slack-alternative](https://mattermost.com/). This release includes team switch shortcuts, ability to unarchive channels from the user interface, experimental channel sidebar features, and much more. This version also includes [security updates](https://mattermost.com/security-updates/). If you have a Mattermost environment that contains a lot of emoji reactions, please refer to [Important notes on upgrading](#upgrade) for information on longer upgrade times.
> - The version of Ruby packaged in Omnibus GitLab has been updated to 2.6.6.
Omnibus PackagePerformance Improvements
> We are continuing to make great strides improving the performance of GitLab in every release. We’re committed to not only making individual instances of GitLab even faster, but also to greatly improving the performance of GitLab.com, an instance that has over 1 million users!
>
> In GitLab 13.0 we are shipping performance improvements for issues, projects, milestones, and a lot more! Some of the improvements in GitLab 13.0 are:
>
> - [A comprehensive list of performance improvements to atomic processing of pipelines](https://gitlab.com/gitlab-org/gitlab/-/issues/197930#note_320405586)
> - [Use NDJSON for Group and Project Exports and Imports to improve memory usage](https://gitlab.com/groups/gitlab-org/-/epics/2734)
> - [Make Elasticsearch enabled check in Redis more efficient](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/29751)
> - [Speed up NOT (!=) filters](https://gitlab.com/gitlab-org/gitlab/-/issues/198324)
> - [Switch ThreadMemoryCache to ProcessMemoryCache](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/31135)
> - [Reorder email handlers for better performance](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/31243)
Bug fixes
> Some of the notable bug fixes in GitLab 13.0 are:
>
> - [Let's Encrypt integration doesn't scale and does not give any feedback to user on errors](https://gitlab.com/gitlab-org/gitlab/-/issues/30146)
> - [Environments page returns error 500](https://gitlab.com/gitlab-org/gitlab/-/issues/216118)
> - [Adding pages domain with any validation error result in 500](https://gitlab.com/gitlab-org/gitlab/-/issues/216728)
> - [Text for future Release date grammatically incorrect](https://gitlab.com/gitlab-org/gitlab/-/issues/199046)
> - [Skipped tests are included in success percentage calculation](https://gitlab.com/gitlab-org/gitlab/-/issues/216265)
> - [JUnit parsing errors are not visible to users](https://gitlab.com/gitlab-org/gitlab/-/issues/210328)
> - [Tags can be deleted again when a branch with the same name exists](https://gitlab.com/gitlab-org/gitaly/-/issues/1439)
> - [Only Code Owners are allowed to merge](https://gitlab.com/gitlab-org/gitlab/-/issues/217125)
> - [Fix permissions of docker volumes created by Runner](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/25440)
> - [Fix removal of build volume when disable_cache set to true](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/25438)
> - [Fix err checks from volume manager](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/25428)
> - [Fix duplicate volume check with trailing slash](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/25432)
> - [ActionView::Template::Error: undefined method `can?' for nil:NilClass](https://gitlab.com/gitlab-org/gitlab/-/issues/217450)
> - [Scala GitLab CI template does not work](https://gitlab.com/gitlab-org/gitlab/-/issues/38080)
> - [Make it possible to set weight of board scope to None or 0](https://gitlab.com/gitlab-org/gitlab/-/issues/11529)
> - [Fix subgroup milestone links in group milestones view](https://gitlab.com/gitlab-org/gitlab/-/issues/208279)
> - [Fix error when attempting to promote some issues to epics](https://gitlab.com/gitlab-org/gitlab/-/issues/215549)
> - [Fix counts in some GraphQL pagination responses](https://gitlab.com/gitlab-org/gitlab/-/issues/216851)
> - [Author issues imported from Jira as the user running the import](https://gitlab.com/gitlab-org/gitlab/-/issues/215569)
> - [Make issues API and Web UI display same results](https://gitlab.com/gitlab-org/gitlab/-/issues/197170)
> - [Roadmap showing Closed Epics, when display "Open Epics" is selected](https://gitlab.com/gitlab-org/gitlab/-/issues/215090)
> - [Search API scoped to blobs does not honor per_page](https://gitlab.com/gitlab-org/gitlab/-/issues/207324)
> - [Elasticsearch: wiki is not correctly indexed on import](https://gitlab.com/gitlab-org/gitlab/-/issues/207491)
> - [Clicking on search results does not follow link](https://gitlab.com/gitlab-org/gitlab/-/issues/208171)
> - [Wiki search doesn't work with project repository disabled](https://gitlab.com/gitlab-org/gitlab/-/issues/209270)
> - [Indexer may eventually panic with repeatedly requests failure](https://gitlab.com/gitlab-org/gitlab-elasticsearch-indexer/-/issues/51)
[Gitaly Cluster for high availability Git storage](https://docs.gitlab.com/ee/administration/gitaly/praefect.html) (self-managed only):
> GitLab now supports highly available Git storage without using NFS. High Availability (HA) configurations improve the availability of important systems, like Git storage, by removing single points of failure, detecting outages, and automatically switching to a replica. This means that an individual component of the system can fail without causing the end user to experience an outage. Access to Git repositories is critical to developers and businesses, because when an outage occurs, developers can't push code, and deployments are blocked.
>
> Internally, Git repository storage is handled by [Gitaly](/blog/2018/09/12/the-road-to-gitaly-1-0/), and now Praefect too. Praefect is a new router and transaction manager we built for Gitaly to coordinate leader election and asynchronous replication. When using a Gitaly Cluster, requests for Git data are routed through one of multiple Praefect nodes to a Gitaly node. This means that there are always multiple warm replicas ready to take over if an outage occurs.
>
> In the future we plan to support [strong consistency](https://gitlab.com/groups/gitlab-org/-/epics/1189), so that write operations succeed on multiple Gitaly nodes, before responding with a success signal, and support [horizontally distributing reads](https://gitlab.com/groups/gitlab-org/-/epics/2013) so that CPU and memory resources can be better scaled.
Gitaly[Versioned Snippets](https://docs.gitlab.com/ee/user/snippets.html#versioned-snippets):
> Snippets are useful for sharing small bits of code and text that may not belong in the main project's codebase. These items are important to groups and users who rely on them for other tasks, like scripts to help generate diagnostic output or setup supporting services for testing and demo environments. Unfortunately, a lack of version control has made it hard to know if a snippet was the latest version or what changes may have happened and how to reconcile those.
>
> Snippets in GitLab are now version controlled by a Git repository. When editing a Snippet, each change creates a commit. Snippets can also be cloned to make edits locally, and then pushed back to the Snippet repository.
>
> This is the first step in enabling more collaboration on Snippets. In future releases we'll introduce support for [multiple files](https://gitlab.com/groups/gitlab-org/-/epics/2829), continue to [expand features](https://gitlab.com/groups/gitlab-org/-/epics/2830) and [expand permissions](https://gitlab.com/groups/gitlab-org/-/epics/2521).
Snippets[Dark Theme in the Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/#themes):
> For people who spend time working in code editors, the ability to customize the environment to match their preferences is important. Dark themes are some of the most [popular](https://marketplace.visualstudio.com/search?target=VSCode&category=Themes&sortBy=Installs) for other editors and important for providing a comfortable experience. It's also clear that GitLab users love their dark themes as a Dark Application theme for all of GitLab is the second most popular request in the [GitLab Issue Tracker](https://gitlab.com/gitlab-org/gitlab/-/issues?sort=popularity).
>
> The GitLab Web IDE is now completely themed dark for users who choose the **Dark** [syntax highlighting theme perference](https://docs.gitlab.com/ee/user/profile/preferences.html#syntax-highlighting-theme). This is an important step in delivering an editing experience users love and a valuable step in understanding how the GitLab UI responds to dark themes. You can [read more](https://about.gitlab.com/blog/2020/05/20/creating-a-dark-ui-for-gitlabs-web-ide/index.html) about the design process here.
Web IDE[Exclude large files using Partial Clone](https://docs.gitlab.com/ee/topics/git/partial_clone.html):
> Storing large binary files in Git is normally discouraged, because every large file added will be downloaded by everyone who clones or fetches changes thereafter. This is slow, if not a complete obstruction when working from a slow or unreliable internet connection.
>
> In GitLab 13.0, Partial Clone has been enabled for blob size filters, as well as experimentally for other filters. This allows troublesome large files to be excluded from clones and fetches. When Git encounters a missing file, it will be downloaded on demand. When cloning a project, use the `--filter=blob:none` or `--filter=blob:limit=1m` to exclude blobs completely or by file size. Note, Partial Clone requires at least Git 2.22.0.
>
> Read more in our recent blog, [How Git Partial Clone lets you fetch only the large file you need](/blog/2020/03/13/partial-clone-for-massive-repositories/).
Gitaly[Use emojis in design comments to enhance feedback 👍](https://docs.gitlab.com/ee/user/project/issues/design_management.html#starting-discussions-on-designs):
> In 13.0, Design discussions are one step closer to the commenting experience in GitLab. We've added emoji support so you can convey your feedback in a more fun and imaginative way! 😼
Design Management[Design Management moved to Core](https://docs.gitlab.com/ee/user/project/issues/design_management.html):
> In the 12.2 release, Design Management debuted with [Design Uploads](/releases/2019/08/22/gitlab-12-2-released/#design-management-uploads) and [Point of Interest Discussions](/releases/2019/08/22/gitlab-12-2-released/#annotations-for-designs) as a GitLab Premium feature. Since then, we’ve considered our users who are designing products as individual contributors and, in 13.0, we’re excited to announce we’ve moved these two features down to GitLab Core! This aligns with our [Individual Contributor Buying Model](/company/pricing/#buyer-based-tiering-clarification) and we expect to add other great team features in the future, like approvals, as we progress towards category maturity.
>
> So now, all users can upload and participate in design feedback on issues in GitLab!
> As a refresher, you’ll find the **Design** tab next to the **Discussion** tab on any issue. Try a drag-and-drop upload of a screenshot to get started!
Design Management[New comparison mode for Merge Requests](https://docs.gitlab.com/ee/user/project/merge_requests/versions#head-comparison-mode-for-merge-requests):
> Merge Requests, particularly the **Changes** tab, is where source code
> is reviewed and discussed. In circumstances where the target branch was
> merged into the source branch of the merge request, the changes in the
> source and target branch can be shown mixed together making it hard to
> understand which changes are being added and which already exist in the
> target branch.
>
> In GitLab 13.0, we are adding an experimental comparison mode, which
> will show a diff calculated by simulating a merge - a more accurate
> representation of the change than using the merge base of the two
> branches. The new mode is available from the comparison target drop down
> by selecting **master (HEAD)**. In the future it will
> [replace](https://gitlab.com/gitlab-org/gitlab/issues/198458) the
> current default comparison.
Code Review[Improved Snippets editor](https://docs.gitlab.com/ee/user/snippets.html):
> With the release of [Versioned Snippets](#versioned-snippets) in GitLab 13.0, we've upgraded the Snippets editor to a lighter-weight version of the editor found in our Web IDE. With this editor, users will benefit from basic code completion and linting for some languages. We've also improved source code language detection for better syntax highlighting, and added support for all our [syntax highlighting themes](https://docs.gitlab.com/ee/user/profile/preferences.html#syntax-highlighting-theme). These improvements will make it easier to edit and collaborate on Snippets.
>
> We're excited to bring consistency to the editors in Snippets and the Web IDE. In a future release we'll expand this functionality to our [single file editor](https://gitlab.com/gitlab-org/gitlab/-/issues/198605) and in our [`.gitlab-ci.yml` editing](https://gitlab.com/gitlab-org/gitlab/-/issues/198606) experiences.
Snippets[Syntax Highlighting Themes for the Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/#themes):
> GitLab supports six [syntax highlighting preferences](https://docs.gitlab.com/ee/user/profile/preferences.html#syntax-highlighting-theme) when viewing code. Themes are important to developers when viewing and editing code on GitLab since it's imperative that they work comfortably throughout the day. We've now released support for all six syntax highlighting preferences in the Web IDE. This includes [Solarized Dark](https://gitlab.com/gitlab-org/gitlab/-/issues/201927), [Solarized Light](https://gitlab.com/gitlab-org/gitlab/-/issues/201930), [Monokai](https://gitlab.com/gitlab-org/gitlab/-/issues/199883) and a [no highlighting](https://gitlab.com/gitlab-org/gitlab/-/issues/216543) option.
>
> Over the last few releases (for example, [12.8](/releases/2020/02/22/gitlab-12-8-released/#dark-syntax-highlighting-theme-for-web-ide) and [12.9](/releases/2020/03/22/gitlab-12-9-released/#white-syntax-highlighting-theme-for-web-ide)) we've been steadily adding and improving support for syntax highlighting preferences in the Web IDE. These updates follow this effort and help to lay the foundation for our [Dark Theme in the Web IDE](#dark-theme-in-the-web-ide), also launching in 13.0. We're excited to continue to expand on developer experience and making the Web IDE feel more like home.
Web IDE[WYSIWYG for the Static Site Editor](https://docs.gitlab.com/ee/user/project/static_site_editor/#static-site-editor):
> Markdown is a powerful and efficient syntax for authoring web content, but even seasoned authors of Markdown content can struggle to remember some of the less-frequently used formatting options or write even moderately-complex tables from scratch. There are some jobs better accomplished with a rich text, "What You See Is What You Get" (WYSIWYG) editor.
>
> GitLab 13.0 brings a WYSIWYG Markdown authoring experience to the Static Site Editor with formatting options for common formatting options like headers, bold, italics, links, lists, blockquotes, and code blocks. The WYSIWYG editor also removes the onerous task of editing tables in Markdown by letting you visually edit table rows, columns and cells in the same way you would edit a spreadsheet. For those more comfortable writing in raw Markdown, there's even a tab for switching between WYSIWYG and plain text editing modes.
Static Site Editor[Visually highlight design comment pins so you can follow the discussion](https://docs.gitlab.com/ee/user/project/issues/design_management.html#starting-discussions-on-designs):
> When there are a lot of discussion threads on a design it can be hard to identify which thread relates to which comment pin on the design without scanning for the correct comment number.
>
> In 13.0, we added a mechanism to highlight the relevant design discussion comment pin when you click on the comment. We also added the reverse where you can click on the comment pin and have the relevent comment scroll into view. This reduces manual scrolling and sifting through the noise when you have lots of comment pins.
Design Management[Commit navigation buttons in merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/reviewing_and_managing_merge_requests.html#merge-requests-commit-navigation):
> Easily navigating commits in large merge requests allows reviewers to be more efficient
> while reviewing on a commit-per-commit basis.
>
> The new commit navigation buttons allows users to seamlessly navigate between the current
> commit to the previous or next commit, making it more efficient to review merge request
> with a large number of changes.
Code Review[Inherit environment variables from other jobs](https://docs.gitlab.com/ee/ci/variables/#pass-an-environment-variable-to-another-job):
> Passing environment variables (or other data) between CI jobs is now possible. By using the `dependencies` keyword (or `needs` keyword for DAG pipelines), a job can inherit variables from other jobs if they are sourced with `dotenv` report artifacts. This offers a more graceful approach for updating variables between jobs compared to artifacts or passing files.
Continuous Integration (CI)[Make JUnit Reports available through the GitLab API](https://docs.gitlab.com/ee/api/pipelines.html#get-a-pipelines-test-report):
> A JUnit report can contain a wealth of information that can be used to update test plans, test execution history, and other artifacts which teams use to track the quality of their code. Updating those artifacts can be a painful, manual, process made worse by the fact that JUnit reports are only available to download from the GitLab UI.
> Starting in GitLab 13.0 users of the GitLab API will be able to access JUnit reports directly. This will enable users to parse JUnit data to create new issues or [update test execution history](https://gitlab.com/gitlab-org/quality/team-tasks/issues/387).
Code Testing and Coverage[GitLab Runner 13.0](https://docs.gitlab.com/runner) (self-managed only):
> We're also releasing GitLab Runner 13.0 today! GitLab Runner is the lightweight, highly scalable, cross-platform software agent 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:
>
> - [ARM64 Docker image is now available](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2076)
> - [Support more glob patterns for artifact/cache such as wildcard patterns](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2620)
> - [Make docker+machine autoscaling configuration more elastic](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/5069)
Continuous Integration (CI)[Filter pipelines by trigger author and branch name](https://docs.gitlab.com/ee/ci/pipelines/#view-pipelines):
> Searching for pipelines triggered by a specific user or that ran on a particular branch is now easier than ever before. With a new filter feature on the pipelines page, it is now possible to filter by trigger author and/or by branch name. Being able to refine the pipelines view by applying these filters will help to stay informed of pipeline activities that matter most to you.
Continuous Integration (CI)[Runner now supports downloading artifacts directly from Object Storage](https://docs.gitlab.com/runner/configuration/feature-flags.html#available-feature-flags):
> GitLab Runner 13.0 now supports downloading artifacts directly from object storage. When this option is enabled the GitLab server will redirect
> the Runner directly to object storage, rather than proxying the traffic. This can result in significant cost savings on network transfer costs, as well as
> reduced load on the GitLab server.
>
> To enable set the [`FF_USE_DIRECT_DOWNLOAD`](https://docs.gitlab.com/runner/configuration/feature-flags.html#available-feature-flags) feature flag to `true`
> via an environment variable.
GitLab Runner[Define policies to ensure important images are never deleted](https://docs.gitlab.com/ee/user/packages/container_registry/#managing-project-expiration-policy-through-the-ui):
> When using GitLab's Image Expiration Policy, there is no way to express something such as "no matter what, don't delete this tag". This introduces risk into the deletion process, as it's possible to delete `release` or `master` images, which should be immutable.
>
> In 13.0 we are excited to announce that you can now update your project's expiration policy to identify images you never want deleted. Simply enable the policy and use regex to identify the image you want to preserve.
Container Registry[Use search to quickly find and discover images hosted in the GitLab Container Registry](https://docs.gitlab.com/ee/user/packages/container_registry/#control-container-registry-from-within-gitlab):
> When you or someone on your team publishes an image to the GitLab Container Registry, you need a way to quickly find it and ensure the image was built properly. If you're using GitLab CI/CD to publish images with each build, it's been very difficult to find an image efficiently within the current user interface. Instead, you've relied on the command line or the [API](https://docs.gitlab.com/ee/api/container_registry.html#list-registry-repository-tags).
>
> We are excited to announce that in 13.0, we've added search functionality to the GitLab Container Registry. Simply navigate to your project or group's registry and enter an image name to see a list of all your images.
Container Registry[Web Application Firewall (WAF) SIEM Integration](https://docs.gitlab.com/ee/user/clusters/applications.html#fluentd):
> We're pleased to announce a new SIEM integration for the Web Application Firewall (WAF)!
> The integration allows users to export their WAF logs to a SIEM or central logging solution
> so they can review any anomalies detected by their WAF. This visibility into the logs also
> helps users to test and tune their WAF rules to reduce false positive rates. The SIEM
> integration can be configured by enabling Fluentd on the **Operations -> Kubernetes** page.
WAF[Use variables to power metric dashboards](https://docs.gitlab.com/ee/operations/metrics/dashboards/templating_variables.html):
> In GitLab 13.0, you can create dashboards powered by variables, enabling you to use a single dashboard to monitor multiple services and components, rather than creating hard-coded dashboards for each service you want to monitor. Instead of the time-consuming and repetitive task of recreating similar dashboards multiple times, you can now create a single dashboard and use variables to change the data you view in it.
Metrics[View payload and annotations of external IT alerts in GitLab](https://docs.gitlab.com/ee/operations/incident_management/index.html#alert-detail-page):
> The alert list view is helpful for triaging problems at a high-level, but it does not provide enough space for all alert attributes and the payload. The new alert detail page is dedicated to displaying and organizing the alert payload and annotations so that responders can quickly find critical information during an investigation.
Alert Management[Aggregate IT alerts from external tools in GitLab](https://docs.gitlab.com/ee/operations/incident_management/index.html#alert-management-list):
> When responding to alerts, responders need a single interface that aggregates IT alerts originating from multiple sources. The new alerts list enables you to sort through alerts quickly and intuitively to help you find and triage the most critical problems first. You can access the alerts list at **Operations >> Alerts**.
Alert Management[Add frequently used dashboards to favorites](https://docs.gitlab.com/ee/operations/metrics/dashboards/):
> In GitLab 13.0, you can now add your frequently-used dashboards to your favorites by clicking the **Star** button. Starring a dashboard displays it first in the dashboard search bar results to save you time.
Metrics[Toggle Metrics Dashboards visibility](https://docs.gitlab.com/ee/operations/metrics/index.html#metrics-dashboard-visibility):
> Previously, project administrators couldn't control permission to view a project's metrics dashboards. As part of GitLab 13.0, admins can now toggle metric dashboard visibility to either project members, or to everyone with access.
Metrics[Display charts in full screen mode](https://docs.gitlab.com/ee/operations/metrics/dashboards/index.html#expand-panel):
> In GitLab 13.0, you can now display metrics charts in full screen mode, helping you see chart information in more detail when triaging incidents.
Metrics[Add annotations to a Metrics Dashboard](https://docs.gitlab.com/ee/operations/metrics/dashboards/index.html#dashboard-annotations):
> Sometimes your metric charts can be hard to understand. Starting in GitLab 13.0, you can now add annotations to your metrics charts which appear as dotted horizontal lines overlaid on your graphs and charts, to help you interpret and understand the data.
Metrics