GitLab.org/GitLab: Release v13.3.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 13.3
Released: 2020-08-22
License: MIT
Release Assets:
[Set default role for SAML SSO users](https://docs.gitlab.com/ee/user/group/saml_sso/#role) (SaaS only):
> To simplify the group member onboarding flow, GitLab 13.3 introduces the ability for group owners to set any role as the ‘Default membership role’ for users added to the group by SSO or SCIM. Previously all group members added to the group by SSO or SCIM were assigned the 'Guest' role by default.
Authentication and Authorization[On-demand DAST scans](https://docs.gitlab.com/ee/user/application_security/dast/#on-demand-scans):
> Dynamic Application Security Testing at GitLab has always been focused on integrating DAST into the DevOps pipeline and enabling developers to scan their review app, running website, or API for vulnerabilities as early as possible. However, there are times when it is necessary to run a DAST scan against an already deployed application when no code changes have been made and no Merge Request has been created. These scans could be needed for audit or compliance reasons, to debug and reproduce an issue that has been found, or to support teams who do not commit code, such as security analysts. Because of the need for DAST scans that are not triggered by a code change or MR, on-demand DAST testing is now available.
> You don't need configuration files or code to start running on-demand scans. Configuration options for on-demand DAST scans are available within the GitLab UI. The result is quicker configuration and greatly improved ease of use. When starting a new on-demand scan you select from a site profile that contains your preferred settings.
> In 13.3, we are releasing the first iteration of the on-demand scans. These scans will initially be limited to a 60-second spider time and a passive DAST scan. This scan will give a quick reconnaissance-type overview of the site you are scanning, without causing any performance or security issues. Over the next few releases, we will be adding options to the Site profile and introducing the Scanner profile. These additions will allow you to increase the spider time, validate ownership of the target site, enable active scans, set authentication options, and more.
DAST[Guided SAST configuration experience](https://docs.gitlab.com/ee/user/application_security/configuration/):
> GitLab's [Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/) now supports a new guided configuration experience. Enabling SAST is now as simple as two clicks. We believe that [security is a team effort](https://about.gitlab.com/direction/secure/#security-is-a-team-effort) and this configuration experience makes it easier for non-CI experts to get started with GitLab SAST. The tool helps a user create a merge request to enable SAST scanning while leveraging best configuration practices like using the GitLab-managed [`SAST.gitlab-ci.yml` template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml) and properly [overriding template settings](https://docs.gitlab.com/ee/user/application_security/sast/#customizing-the-sast-settings).
>
> With GitLab SAST [covering 18 languages across 14 analyzers](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks), there are many SAST configuration options and it can be hard to understand and setup. This new guided SAST configuration experience helps anyone get started with SAST, and lays the foundation for us to introduce new configuration options like custom rulesets and more. We also intend to expand this guided experience to our other [security scanning tools](https://docs.gitlab.com/ee/user/application_security/#security-scanning-tools).
SAST[Additional details on Project Security Dashboard](https://docs.gitlab.com/ee/user/application_security/security_dashboard/#project-security-dashboard):
> The Project Security Dashboard is getting even more useful with the addition
> of new data fields to the vulnerability list. Putting more details on the
> main dashboard provides an even better overview of a project's vulnerabilities
> without having to open the individual vulnerability pages.
>
> For scanners that run against source code, you can now see the line number
> in the vulnerable file. We're also including the scanner type (SAST, DAST,
> etc.) which you can filter by. This makes it easy to quickly drill into a
> specific subset of vulnerabilities.
>
>
> We've also improved the display of vulnerability identifiers. Many scanners
> can include more than one identifier for a given vulnerability such as a CVE,
> CWE, or a proprietary ID. Previously, we picked the first identifier provided
> to display on the vulnerability list. Now, we always show the CVE if one is
> available. We also indicate the total number of other identifiers.
Vulnerability Management[Link existing Issues to a Vulnerability](https://docs.gitlab.com/ee/user/application_security/#managing-related-issues-for-a-vulnerability):
> We're enhancing the Vulnerability Management workflow by enabling users to link
> existing issues to vulnerabilities. Previously, you could only
> associate a single issue with a vulnerability by creating a new issue from
> the vulnerability record. These issues were automatically created in the
> same project as the vulnerability record.
>
> With this new functionality, you can link one or more existing issues to
> a vulnerability. It is also possible to link issues from other projects.
> This provides security and development teams greater flexibility and
> visibility when managing vulnerabilities, especially across projects.
Vulnerability Management[DAST vulnerability evidence](https://docs.gitlab.com/ee/user/application_security/#view-details-of-a-dast-vulnerability):
> Vulnerabilities that have been found by a DAST scan can be difficult to reproduce, since the vulnerability might be reproduced only under certain circumstances. It can also be difficult to pinpoint what code is responsible for the issue when attempting to fix it. Evidence of the vulnerability discovered by the DAST scan is now included in the vulnerability details, making reproduction and remediation easier.
DAST[Coverage-guided fuzz testing for Go and C/C++ applications](https://docs.gitlab.com/ee/user/application_security/coverage_fuzzing/):
> You can now run coverage-guided fuzz tests against your Go and C/C++
> apps. This is a great way to start finding security issues and bugs
> that other security scanners and traditional QA may miss. Coverage-guided
> fuzz testing uses contextual information about your app to randomly
> generate inputs and find crashes or other faults that you can
> then fix before they affect users in production.
>
> This is the first release that incorporates the new technology from the fuzz
> testing acquisitions we [recently announced](https://about.gitlab.com/press/releases/2020-06-11-gitlab-acquires-peach-tech-and-fuzzit-to-expand-devsecops-offering.html).
> We recently wrote a [blog post](https://about.gitlab.com/blog/2020/07/17/fuzz-testing/)
> with some more information about the acquisitions as well.
>
> We have much more on the way for fuzz testing. Check out all the details on our
> [fuzz testing direction page](https://about.gitlab.com/direction/secure/dynamic-analysis/fuzz-testing/)
> page. We'd love for you to let us know what you think!
Fuzz Testing[Container Network Policies Controls](https://docs.gitlab.com/ee/user/clusters/applications.html#install-cilium-using-gitlab-cicd):
> Container Network Policy Controls provide an easily discoverable way to find
> the documentation on how to install and uninstall Container Network Policies
> for a Kubernetes cluster. You can access these controls, along
> with a visual indicator of the current Container Network Policies status,
> in the **Operations > Kubernetes > Applications** page's new
> **GitLab Container Network Policies** section.
Container Network Security[Display strategy information on feature flags list view](https://docs.gitlab.com/ee/operations/feature_flags.html):
> With the introduction of support for [multiple strategies per feature flag](https://docs.gitlab.com/ee/operations/feature_flags.html#feature-flag-strategies) in GitLab 13.0, you are able to set strategies for your feature flags. However, you were unable to see the relevant strategy information in the list view of feature flags. It's now possible to see all related information about a feature flag in the list view. This includes the strategies, the environments, and the number or percent of users for which the flag is enabled. This view lets you quickly understand the configuration of all the flags in your project without the need to open each one of them individually.
Feature Flags[Run pipelines in the parent project for MRs from forks](https://docs.gitlab.com/ee/ci/merge_request_pipelines/#run-pipelines-in-the-parent-project-for-merge-requests-from-a-forked-project-starter):
> As a project maintainer, you might want to enable contributions from forked projects that are fully tested by your own project's CI/CD pipeline. Previously, you'd have to give contributors access to project CI runners, CI configuration, and CI variables, which is something many development groups aren't comfortable doing. Now, GitLab allows parent project members with the appropriate permissions to run a pipeline for an MR submitted from a fork using the parent project's CI/CD configuration. It also shows a warning dialog explaining the risks before starting the pipeline so you can better mitigate potential risks.
Continuous Delivery[Edit Feature Flag User Lists from the UI](https://docs.gitlab.com/ee/operations/feature_flags.html#user-list):
> You can now create, edit, and delete Feature Flag user lists directly in the UI. Previously, you could only perform these actions via the API. Add or remove users to the list quickly and easily, as well as change the name of the list.
Feature Flags[Improve code search matching for Advanced Search](https://docs.gitlab.com/ee/integration/elasticsearch.html#known-issues):
> The current code analyzer for the Elasticsearch integration doesn't take all code cases into account. For example, if you have a file with `a.b.c=one_two_three` and you search for `one_two_three`, you wouldn't get the file returned in the search.
> In GitLab 13.3, we have improved the code analyzer in Elasticsearch, and it is now more robust at matching searches with special characters.
Global Search[Geo is faster and easier to maintain](https://docs.gitlab.com/ee/administration/geo/replication) (self-managed only):
> Geo replicates data from a primary Geo node to one or several Geo
> secondary nodes. Backfilling data to secondary nodes as quickly as possible is critical to ensure that secondary nodes don't fall too far behind.
>
> After a number of iterations (51 MRs!), Geo no longer requires [PostgreSQL Foreign Data Wrappers (FDW)](https://wiki.postgresql.org/wiki/Foreign_data_wrappers). This eliminates the possibility of some database timeouts and increases the overall performance of backfill operations. Additionally, this change reduces a step when configuring Geo and makes it easier to maintain a Geo deployment. To give an idea of the reduction in complexity, this change resulted in 3,823 net lines of code being removed.
Geo-replication, Disaster Recovery[Create multiple custom value streams](https://docs.gitlab.com/ee/user/analytics/value_stream_analytics.html#creating-a-value-stream):
> In this release, we're making [customizable Value Stream Analytics (VSA)](https://docs.gitlab.com/ee/user/analytics/value_stream_analytics.html#customizable-value-stream-analytics)
> even better by allowing teams to create multiple custom value streams. Customizability in VSA allows teams to have detailed understanding of a group's
> activity, and you're now able to create and reuse your customized stages in this feature without needing to re-create them each time.
>
> This is ideal for projects and groups collaborating across multiple departments, where each department may measure value differently. A project manager may
> want to see a value stream defined by issue labels, but an engineering team may want to understand merge request activity and time to deploy. With multiple value
> streams, you're now able to create and customize separate value streams for both.
Value Stream Management[Merge Request Analytics](https://docs.gitlab.com/ee/user/analytics/merge_request_analytics.html):
> Many organizations, including GitLab, use throughput as
> a way of measuring how [fast a team can do work](https://weblogs.asp.net/wallen/throughput-vs-velocity). We're now introducing
> a first iteration of Merge Request Analytics to help your team better understand the rate of merged MRs in your projects.
>
> Available at the project level, Merge Request Analytics can help an engineering team quickly understand MR activity at a glance.
> Users interested in a more detailed look—for example, a team lead interested in MRs with a specific label—are also able
> to filter and see a detailed list of relevant MRs.
Code Analytics[Confirmation dialog before regenerating Feature Flag instance ID](https://docs.gitlab.com/ee/operations/feature_flags.html#integrate-feature-flags-with-your-application):
> It is too easy to accidentally regenerate an instance ID for a
> feature flag when you actually intend to copy the instance ID. If the instance id gets regenerated,
> you need to update it in your application and then restart the application in all environments.
> Now there is a confirmation step that requires you to type the name of the project before regenerating the ID. This will greatly reduce the risk of unintentional ID regeneration.
Feature Flags[Rename Feature Flag user strategies](https://docs.gitlab.com/ee/operations/feature_flags.html#feature-flag-strategies):
> In an effort to simplify the Feature Flag strategies and prevent confusion we have renamed them. `Percent rollout (logged in users)` has been changed to `Percent of users` and `List` has been changed to `User List`.
Feature Flags[Prevent forking outside a group](https://docs.gitlab.com/ee/user/group/#prevent-project-forking-outside-group-premium):
> Group administrators can now prevent the projects within their group from having new forks created outside of the current top-level group. This new setting gives group administrators additional mechanisms to protect their group's intellectual property.
Subgroups[Toggle epic confidentiality](https://docs.gitlab.com/ee/user/group/epics/manage_epics.html#make-an-epic-confidential):
> As confidential work becomes ready to be shared on a more public level, it can be difficult to share a collection of issues
> and their parent epic. You can now toggle the confidentiality of your epics, enabling or disabling visibility for those with the proper access.
Epics[Merge Request Approvals show who participated in the review](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html#multiple-approval-rules):
> Code review often involves multiple people and multiple iterations. It can be hard to know who has been reviewing the merge request, and which of those reviewers has approved and who hasn't. It is important so you can avoid duplicating work and wasting time.
>
> To show who has provided feedback via comments, the merge request widget now shows a **Commented by** column. This makes it easier for authors and reviewers to identify who to engage.
Code Review[Improve Fail Fast Testing Template](https://docs.gitlab.com/ee/user/project/merge_requests/fail_fast_testing.html):
> We introduced the Fail Fast Testing template in [GitLab 13.1](/releases/2020/06/22/gitlab-13-1-released/#run-tests-for-modified-files-first) and gathered feedback from internal stakeholders. We found that if the default image was being overridden in a `.gitlab-ci.yml` file, the template would not work. We've since improved the Fail Fast template so you can now trust the Fail Fast Template to work out of the box, even if you specify a different image.
Code Testing and Coverage[Audit logs for CI/CD group variables](https://docs.gitlab.com/ee/administration/audit_events.html#group-events-starter):
> When you can't track changes to CI/CD variables, it's difficult to understand what might have caused your pipeline to fail. Now, in our first iteration of variable audit logs, you can track changes to group-level CI/CD variables. This new audit log captures three events: group variable additions, removals, and protected state changes.
Continuous Integration (CI)[ECS task definition from local JSON](https://docs.gitlab.com/ee/ci/cloud_deployment/#deploy-your-application-to-the-aws-elastic-container-service-ecs):
> Today, GitLab's ECS deployment template updates existing task definitions that are already defined in your attached AWS account. It's also common to update your task-definition as part of your GitLab flow. Now, you can update the JSON task definition in your local repository and push it knowing the task will get appropriately created in the AWS account, improving your standard development flow.
Continuous Delivery[Project access tokens](https://docs.gitlab.com/ee/user/project/settings/project_access_tokens.html) (self-managed only):
> Project level access tokens allow access to a project without the need to provision a new GitLab user. Project access tokens can be generated by project Maintainers or Owners and be used to authenticate with the GitLab API. Project access tokens will be authorized as Maintainers. This new functionality will make programmatic access to GitLab easier and more secure.
Authentication and AuthorizationBug fixes
> Some of the notable bug fixes in 13.3 are:
>
> - [Release asset link type and filepath are not saved when creating a new Release through the API](https://gitlab.com/gitlab-org/gitlab/-/issues/230698)
> - [Access Control for GitLab Pages leads to 503 error](https://gitlab.com/gitlab-org/gitlab/-/issues/26460)
> - [Cannot cancel creation of new release](https://gitlab.com/gitlab-org/gitlab/-/issues/235515)
> - [Pages access control doesn't pick-up custom CA certs on authentication](https://gitlab.com/gitlab-org/gitlab/-/issues/25411)
> - [Error loading Vulnerability List when linked issue has been moved](https://gitlab.com/gitlab-org/gitlab/-/issues/233839)
> - [Mirrored projects don't replicate tags to secondary nodes](https://gitlab.com/gitlab-org/gitlab/-/issues/235674)
> - [Sign in doesn't work on a secondary with relative URL](https://gitlab.com/gitlab-org/gitlab/-/issues/230688)
> - [Geo: Redownloading repositories via snapshot does not work](https://gitlab.com/gitlab-org/gitlab/-/issues/209988)
> - [Jira issue importer limits project selection to 100 results](https://gitlab.com/gitlab-org/gitlab/-/issues/231394)
> - [Markdown not rendering in new iteration or iteration report](https://gitlab.com/gitlab-org/gitlab/-/issues/229889)
> - [Iteration issue list doesn't include subgroup issues](https://gitlab.com/gitlab-org/gitlab/-/issues/229433)
> - [Search results page is changing the sort order incorrectly/arbitrarily](https://gitlab.com/gitlab-org/gitlab/-/issues/229982)
> - [Generated Blob ID was too long to be handled by Elasticsearch](https://gitlab.com/gitlab-org/gitlab/-/issues/5870)
> - [Efficient Counters](https://gitlab.com/gitlab-org/gitlab/-/issues/24469)
> - [Child pipelines and their jobs are not found by API endpoints](https://gitlab.com/gitlab-org/gitlab/-/issues/207226)
> - [Remove public issues from suggestions when adding issue to confidential epic](https://gitlab.com/gitlab-org/gitlab/-/issues/219493)
[GitLab chart improvements](https://docs.gitlab.com/charts) (self-managed only):
> - It is now possible to configure a dependency proxy for upstream images/packages in the GitLab Helm chart. Note that backup and restore, and migration from Omnibus are not currently supported. To learn more about dependency proxy, see [Dependency Proxy](https://docs.gitlab.com/ee/user/packages/dependency_proxy). For configuration instructions, see [Configure Charts using Globals](https://docs.gitlab.com/charts/charts/globals.html#lfs-artifacts-uploads-packages-external-mr-diffs-and-dependency-proxy).
> - The settings to configure object storage have been consolidated so that object storage for all objects can be configured by one section in `values.yml`. This is a great improvement that makes object storage configuration much more efficient, including the ability to use a single credential for multiple S3 buckets. It also enables GitLab Workhorse to upload files directly with its own S3 client, eliminating the need for pre-signed URLs. For more details, refer to [the Object Storage documentation](https://docs.gitlab.com/charts/charts/globals#consolidated-object-storage).
> - For improved aggregation, the Workhorse log is now output in JSON rather than as unstructured data. For more details, see the [related issue](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/2249).
Cloud Native Installation[Links to search results now unfurl in tools like Slack](https://docs.gitlab.com/ee/user/search/advanced_search.html):
> Unfurling a URL in tools like Slack provides useful context for other team members. In GitLab 13.3, search result pages have updated meta headers to provide a better description when unfurled.
Global Search[Use API to source Pages domain configuration](https://docs.gitlab.com/ee/administration/pages/#domain-source-configuration):
> You can now configure GitLab Pages to source a project's configuration through the GitLab internal API, and take advantage of the API for quicker GitLab Pages daemon booting times.
Pages[Faster rendering of rich content](https://docs.gitlab.com/ee/user/project/repository/#supported-markup-languages-and-extensions):
> One of the common tasks users perform in the GitLab UI is viewing rich content, for example
> rendered markdown in an issue, a merge request, or just viewing a file. For large content, this
> can take a long time to complete, resulting in a lengthy wait.
>
> In GitLab 13.3, we have optimized how this content is generated, improving user experience and reducing load on the server.
> The [GitLab changelog](https://gitlab.com/gitlab-org/gitlab/-/blob/master/CHANGELOG.md), a 14,000 line markdown file,
> now takes 20 seconds to view instead of 35, for a 40% improvement!
Source Code Management[Faster loading of content with many references](https://docs.gitlab.com/ee/user/project/issues/crosslinking_issues.html):
> One of the benefits of GitLab being a single application for DevOps, is that it is really easy to link content together. We support referencing
> labels, milestones, snippets, commits, merge requests, issues, and epics in all parts of GitLab. It is not uncommon for a single piece of content to reference tens or even hundreds of other items. This connectedness however can cause delays in rendering the content to users, as the GitLab server needs to look up each reference to present additional context.
>
> In GitLab 13.3, the performance of reference lookups has been improved significantly. For a sample piece of content with 165 references, it was generated [75% faster with half the memory footprint](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36735#note_379153150), resulting in a significantly faster user experience with less load on the GitLab server.
Source Code Management[Option to disable unknown sign-in email notifications](https://docs.gitlab.com/ee/administration/settings/sign_in_restrictions.html#email-notification-for-unknown-sign-ins) (self-managed only):
> We have improved the logic for unknown sign-in email notifications so that users receive fewer emails. We recommend leaving unknown sign-in email notifications enabled, but GitLab administrators will now also have the option to disable unknown sign-in email notifications for their instance. This option can be used in cases where users cannot accept cookies in their browser and users' IPs change often.
Authentication and Authorization[Omnibus improvements](https://docs.gitlab.com/omnibus) (self-managed only):
> - To prevent PostgreSQL upgrade failures due to insufficient space, and to make the upgrade experience smoother, GitLab now checks to make sure you have [sufficient free space](https://docs.gitlab.com/omnibus/settings/database.html#upgrade-packaged-postgresql-server) before performing a PostgreSQL upgrade with the `pg-upgrade` command.
> - It is now easier to [specify a timeout value](https://docs.gitlab.com/omnibus/settings/database.html#upgrade-packaged-postgresql-server) for PostgreSQL upgrades. Previously, the timeout value for `pg-upgrade` could only be specified in units of milliseconds. It is now also possible to specify the value in days, hours, minutes, seconds, or milliseconds, or some combination of these. For example, `1d2h3m4s5ms`.
> - GitLab 13.3 includes [Mattermost 5.25](https://mattermost.com/blog/mattermost-release-v5-25/), an [open source Slack-alternative](https://mattermost.com/) whose newest release includes a Jitsi integration for video conferencing and screen sharing, an enhanced Welcomebot plugin, and more. This version also includes [security updates](https://mattermost.com/security-updates/). Upgrading from earlier versions is recommended.
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!
>
> Some notable performance improvements in GitLab 13.3 are:
>
> - [Investigate and reduce amount of 'CACHE' SQL for Projects::NotesController#create](https://gitlab.com/gitlab-org/gitlab/-/issues/228626)
> - [Rollout update nodes optimization feature for banzai reference filter](https://gitlab.com/gitlab-org/gitlab/-/issues/230689)
> - [Wasteful extra project ID filtering in project scoped search](https://gitlab.com/gitlab-org/gitlab/-/issues/228818)
> - [Prevent N+1 in board list issue service via strong memoize](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/38050)
[PostgreSQL 12 is now available](https://docs.gitlab.com/omnibus/update/gitlab_13_changes.html#postgresql-123-support) (self-managed only):
> PostgreSQL 12 is now supported as an opt-in PostgreSQL version for self-managed installations of GitLab. PostgreSQL 12 includes a number of performance improvements such as improved query performance for large data sets. For a full list of improvements, see [the PostgreSQL release page](https://www.postgresql.org/about/news/1976/). Support for using PostgreSQL 12 with a PostgreSQL cluster and Geo sites will be coming soon. For more details on support for PostgreSQL 12 in GitLab, see [the PostgreSQL 12 epic](https://gitlab.com/groups/gitlab-org/-/epics/2374). PostgreSQL 12 is [scheduled to become the default version of PostgreSQL in GitLab 13.6](https://gitlab.com/groups/gitlab-org/-/epics/3835), but it will still be possible to opt out of this version.
Omnibus Package[Set a deploy freeze in the UI](https://docs.gitlab.com/ee/user/project/releases/#prevent-unintentional-releases-by-setting-a-deploy-freeze):
> This feature expands on the API capability of [setting a deploy freeze window](https://docs.gitlab.com/ee/api/freeze_periods.html), which we introduced in 13.0. Now, from the GitLab UI, you can easily set a time period when deployments can't occur. You no longer have to use the API to script your deploy freeze or use `.gitlab-ci.yml`. Instead, you can easily go to the UI settings to create a recurring or one-time deploy freeze.
Release Orchestration[Track deployment events in GitLab with webhooks](https://docs.gitlab.com/ee/api/projects.html#hooks):
> GitLab has made it easier for you to build deployment automation with a webhook that supports successful, failed, and canceled deployments.
Release Orchestration[Review App links accessible for any user](https://docs.gitlab.com/ee/ci/review_apps/):
> Until now, you weren't able to see Review App links on a Merge Request if you weren't a member of the respective project where the MR was originally created. In 13.3, we have made review apps accessible to any user, allowing you to get feedback on your code changes from anyone, even your customers. By allowing everyone to contribute, you can better collaborate and shorten your feedback loop.
Review Apps[Display a single file when reviewing merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/reviewing_and_managing_merge_requests.html#file-by-file-diff-navigation):
> Reviewing merge requests diffs is an essential task when reviewing code
> contributions, as this is where most of the communication between author and
> reviewer takes place. However, as merge requests become larger and more files
> are involved, navigation and performance of merge request diffs can become difficult.
>
> To resolve this, GitLab 13.3 introduces an option to see one file
> at a time on the **Changes** tab of merge requests. It provides a cleaner
> workspace and enhances the reviewer focus on one single file. At the
> bottom, you can navigate between the files changed by clicking the
> **Prev** and **Next** buttons. It can be optionally enabled through user
> preferences.
>
> Thanks to GitLab user [Osher](https://gitlab.com/osherdp) for contributing
> to the initial iteration.
Code Review[Instance-level project integration management for external services](https://docs.gitlab.com/ee/administration/settings/project_integration_management) (self-managed only):
> Administrators of self-managed GitLab can now integrate third-party services with all projects on the instance from a single interface.
>
> Previously, integrations had to be configured per project, which meant that if an instance had thousands of projects, thousands of individual configurations had to be manually configured. Not only was this time-consuming, but it was also error-prone, hard to update, and made it difficult to enforce integrations as a policy.
>
> By configuring integrations across all projects, administrators save themselves and their project owners incredible amounts of time and effort.
>
> This is the first iteration of this functionality. In upcoming releases, we will expand this feature to the group level, add more configuration and compliance options, and more.
Integrations[GitLab Workflow extension for Visual Studio Code now official](https://gitlab.com/gitlab-org/gitlab-vscode-extension/):
> [Over two years ago](https://about.gitlab.com/blog/2018/03/01/gitlab-vscode-extension/), [Fatih Acet](https://gitlab.com/fatihacet) created an extension to integrate GitLab with development in Visual Studio Code. Fatih and more than 25 contributors continued to improve the extension with new features, and it has now been installed over 160,000 times. Fatih transferred maintainership to GitLab, and we'll continue to improve and support this extension.
>
> The GitLab Workflow is now [officially maintained and supported](/blog/2020/07/31/use-gitlab-with-vscode/) by the [Editor Group](/handbook/product/categories/#editor-group). We'll be continuing to contribute features, and support the community who was actively involved in our early releases. If you have ideas or feedback, please [open an issue](https://gitlab.com/gitlab-org/gitlab-vscode-extension/-/issues/new?issue%5Bassignee_id%5D=&issue%5Bmilestone_id%5D=).
Editor Extension[Multi-line comments for merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/reviewing_and_managing_merge_requests.html#commenting-on-multiple-lines):
> Commenting on a specific line in a merge request diff is a great way to leave feedback for the author.
> Reviewers often need to comment on an entire section of the code, for example a function or expression which covers multiple lines of code.
> Leaving a comment on a single line, while referring to many lines, makes communication less clear and less efficient.
>
> With the introduction of multi-line comments, reviewers will no longer need to decide which single line
> of code to choose during a review, instead they will be able to provide feedback to multiple lines in
> the merge request diff.
>
> Future iterations will include multi-line suggestions as well as increased ease of use. You can follow along
> in the [multi-line comments epic](https://gitlab.com/groups/gitlab-org/-/epics/1431).
Code Review[Drag and drop to reorder designs](https://docs.gitlab.com/ee/user/project/issues/design_management.html#reordering-designs):
> If you are using GitLab to design a product with screens or a user flow, you'll want to place your designs in a specific sequence to present the full concept to your team.
>
> Previously, designs were only displayed in the order in which they were uploaded, complicating reviews and leading to frustration.
>
> As of 13.3, you can now drag and drop your designs into any order! The order is saved so that anyone who views your designs will see the order you intended. Go forth and create the flows you imagine or re-order to match your frames in Figma or Sketch!
Design Management[Concurrent Git repository backups](https://docs.gitlab.com/ee/raketasks/backup_restore.html#back-up-git-repositories-concurrently) (self-managed only):
> Backups protect against data loss events and should be run regularly, and before maintenance and upgrades. For this reason, GitLab has a `gitlab-backup` script so that system administrators can back up everything. As the number and size of repositories increases, backing up repository data using the script becomes impossibly slow.
>
> A significant reason why the script is slow is that repositories are backed up one by one. This underutilizes the available CPU and memory resources, particularly when there are multiple Gitaly nodes. Adding concurrency allows multiple repositories to be backed up at the same time, significantly reducing backup time.
Backup/Restore of GitLab instances, Gitaly[Gitaly Cluster read distribution](https://docs.gitlab.com/ee/administration/gitaly/praefect.html#distributed-reads) (self-managed only):
> Repositories with many contributors combined with highly parallelized CI pipelines, or highly variable project access patterns can cause high CPU and memory usage, decreasing availability. Mitigating these performance problems by sharding generally results in over-provisioning to handle peak load.
>
> Gitaly Cluster allows Git repositories to be replicated on multiple warm Gitaly nodes, and can be used to scale performance by distributing read operations between up-to-date replicas. From GitLab 13.3, when using Gitaly Cluster, read operations will automatically be distributed between up-to-date replicas. This better utilizes the available CPU and memory resources, and scales better in comparison to sharding. Read the [Cluster or Shard](https://docs.gitlab.com/ee/administration/gitaly/praefect.html#cluster-or-shard) documentation to learn more about the benefits of Gitaly Cluster.
>
> **Note:** Gitaly Clusters can be created using GitLab Core and higher tiers. However, technical support is limited to GitLab Premium and Ultimate customers only.
Gitaly[Gitaly Cluster reference transactions](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. Write operations are currently replicated asynchronously however, which means that the GitLab server only has one copy of the change from when the write is accepted, until replication is complete.
>
> Transactional write operations to Git repositories in GitLab 13.3 causes changes to be broadcast to all Gitaly nodes. Only the Gitaly nodes that vote in agreement with the primary node persist the changes to disk. Dissenting nodes are brought in sync by asynchronous replication. This means the change will typically be written to all Gitaly nodes when the write is accepted. This is not guaranteed, however, because all replica nodes could vote against the primary. [Quorum-based voting (beta)](#gitaly-cluster-quorum-based-voting-beta) can be enabled to prevent this.
>
> **Note:** Gitaly Clusters can be created using GitLab Core and higher tiers. However, technical support is limited to GitLab Premium and Ultimate customers only.
Gitaly[Squash Commits Options](https://docs.gitlab.com/ee/user/project/merge_requests/squash_and_merge.html#squash-commits-options):
> Squashing commits in Git is a great way to combine several commits into a single one. It's great for grouping several commits, which by themselves may provide little historical value, into a single large commit before pushing upstream. Pushing a single commit allows for a more meaningful commit message, as well as ensuring the group of commits provides a "green" continuous integration pipeline.
>
> In GitLab 13.3 we are adding configurable defaults for squashing commits, allowing project maintainers to configure the option to suit their preferred workflow. Because changing squash configuration may introduce unwanted behavior, configuration has not been changed for new or existing projects. With 314 upvotes 👍, this is one of the most highly requested improvements by the community and we hope it allows more users to use this powerful feature.
Source Code Management, Code Review[Find references added to Code Intelligence](https://docs.gitlab.com/ee/user/project/code_intelligence.html#find-references):
> Code review is an important process that requires an understanding of the proposed change and surrounding code to know if it has been made in a maintainable way. GitLab's native Code Intelligence helps developers navigate code and understand changes introduced in merge requests. This is important to understand existing code as well to ensure new code is added in a responsible way.
>
> GitLab 13.3 introduces the ability to display references for projects using GitLab's native Code Intelligence. Clicking on an object in your code will display the definition and offer the ability to browse references on the second tab, displaying the full path and line number where the object is being used.
>
> Future iterations will include API support and displaying the code for references in the popover. You can follow along in the [Code Intelligence epic](https://gitlab.com/groups/gitlab-org/-/epics/1576).
Source Code Management, Code Review[WIP merge requests renamed Draft merge requests](https://docs.gitlab.com/ee/user/project/merge_requests/drafts.html):
> WIP (work in progress) status for merge requests provide a clear signal to reviewers
> that the merge request in question is not yet ready to be merged.
>
> In order to use a more inclusive and self-explanatory term,
> the WIP (work in progress) feature for Merge Requests has been renamed to "Draft".
> This term clearly communicates the MR in question is not ready for
> review as well as not making any assumptions about the progress being made towards it.
> Additionally, it reduces the cognitive load for new users, non-English speakers, and anyone
> not familiar with the WIP acronym.
>
> WIP merge requests are now deprecated in favor of **draft** merge requests, however both
> terms will be supported until the next major GitLab release (14.0), after which it will be
> [removed](https://gitlab.com/gitlab-org/gitlab/-/issues/228685).
Code Review[Display non-Markdown content in the WYSIWYG Static Site Editor](https://docs.gitlab.com/ee/user/project/static_site_editor/#use-the-static-site-editor-to-edit-your-content):
> Static site generators often rely on Markdown to organize content and the Static Site Editor offers an intuitive WYSIWYG Markdown editing experience for those documents. However, their content isn't always written in Markdown. Many generators support additional markup embedded in the Markdown to extend the author's capabilities. It is also valid to write HTML alongside markdown content.
>
> The Static Side Editor's WYSIWYG mode now separates non-Markdown content into uneditable content blocks, displayed inline with your content. This prevents unexpected formatting errors that can arise when the editor attempts to convert non-Markdown content to HTML. The non-Markdown content is still editable in the raw source mode of the Static Site Editor and future iterations will enable safely editing this kind of content within the WYSIWYG mode.
Static Site Editor[Transactional writes for Gitaly Cluster (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. However, because write operations are currently replicated asynchronously, the GitLab server only has one copy of the change initially.
>
> In GitLab 13.2, transactional write operations to Git repositories can be enabled for Gitaly Cluster. When this option is enabled and an update is pushed to GitLab, the write operation will be proxied to the replica Gitaly nodes. The write operation will be coordinated between the Gitaly nodes using the two-phase commit protocol, so that they agree on the new state of the repository. Write transactions are currently limited to operations pushed over the HTTP and SSH Git interfaces, and does not include write operations via the GitLab interface like the Web IDE.
Gitaly[Enhanced Web Editor](https://docs.gitlab.com/ee/user/project/repository/web_editor.html):
> We've upgraded the web editor to a lighter-weight version of the editor found in our Web IDE. This adds 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 make it easier to edit and collaborate on files in projects.
Web IDE[Create a matrix of jobs using a simple syntax](https://docs.gitlab.com/ee/ci/yaml/#parallel-matrix-jobs):
> GitLab's [child/parent pipelines](https://gitlab.com/gitlab-org/gitlab/-/issues/16094) let you write your own code to generate an entire pipeline YAML. This is a powerful way to generate custom behaviors, including generating jobs at runtime. This might not be needed for simpler scenarios where you just want to create multiple similar jobs for a defined set of cases. In this release you can find a new `matrix` keyword that works along with `parallel` to handle the creation of multiple jobs for you, each with different variables.
>
> For example, you could configure your pipeline to automatically create jobs for 4 different architectures, each with a `debug` and `release` target for 3 different versions, all with a single matrix-style configuration. This would create 24 unique jobs (4x2x3) to cover every possible combination.
Continuous Integration (CI)[Visualization of Directed Acyclic Graph (DAG) pipelines](https://docs.gitlab.com/ee/ci/directed_acyclic_graph/#dag-visualization):
> You may have noticed the new DAG tab on your pipelines that visually renders the [directed acyclic graph](https://docs.gitlab.com/ee/ci/directed_acyclic_graph/index.html) dependencies for pipelines using the `needs` keyword. This makes it easier to understand complex webs of dependencies in your CI/CD configuration. In this release, we consider the feature officially released and are removing the beta tag! Your feedback is still welcome, as always, so let us know what you think.
Continuous Integration (CI)[View and manage group Runners](https://docs.gitlab.com/ee/ci/runners/runners_scope.html#view-and-manage-group-runners):
> We've added a new group management user interface (UI) for managing your organization's Runners. In this new UI, you can view, edit, pause, and stop any Runner that's associated with your group in GitLab. This makes it easier to troubleshoot potential issues with Runners for multiple projects at once.
GitLab Runner[GitLab Runner 13.3](https://docs.gitlab.com/runner):
> We’re also releasing GitLab Runner 13.3 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:
>
> - [Add an ENTRYPOINT script to the GitLab Runner helper image](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3371)
> - [Update installed Git version for Windows helper images](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/2306)
> - [Update Ubuntu Docker container to Ubuntu 20.04](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/2286)
>
> #### Bug Fixes:
>
> - Fix: [Register with the `--run-untagged ` option not working with rpm/deb latest in gitlab-runner-13.2.0-1](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26609)
> - Fix: [SELinux alerts: SELinux is preventing gitlab-runner from name_connect access on the tcp_socket port 443](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3440)
> - Fix: [PowerShell error when running job](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26623)
> - Fix: [Network per build: health check for services time out](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/25660)
>
> The list of all changes is in the GitLab Runner [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/13-3-stable/CHANGELOG.md).
GitLab Runner[CI linter now can provide warnings in addition to errors](https://docs.gitlab.com/ee/ci/lint.html):
> The CI linter can now provide warnings in addition to error messages when validating your `.gitlab-ci.yml` file. This gives us the opportunity to provide more guidance when evaluating your pipelines, thereby making it easier to avoid more kinds of mistakes by catching them earlier.
>
> Our initial iteration is to provide a warning when the `when:always` rule is used without `workflow:rules`; this scenario causes duplicate pipelines when an MR is created and has also been a source of confusion. And in addition to displaying this new warning message on the linter page, it will also appear on the pipeline view and run pipeline page to help you improve your CI configurations.
Continuous Integration (CI)[JUnit Report Improvements](https://docs.gitlab.com/ee/ci/unit_test_reports.html#junit-test-reports):
> We introduced the JUnit report in [GitLab 12.5](https://about.gitlab.com/releases/2019/11/22/gitlab-12-5-released/#display-junit-error-details-in-merge-request) which provides a view of all JUnit tests that run in a pipeline. The wider community helped identify some readability and usability issues in the report interface that made it hard to use, especially when the names of tests or suites exceeded a specific number of characters. Additionally, performance of the page could be slow when parsing very large files or a large quantity of `junit.xml` files.
> Now, you're presented with a JUnit report that's easier to read and you can take confidence in the fact that the pipeline page will load quickly even when loading thousands of tests. This feature is no longer behind a feature flag by default and is enabled for all users on GitLab.com.
Code Testing and Coverage[Better linting for .gitlab-ci.yml files](https://docs.gitlab.com/ee/ci/lint.html):
> When reviewing your CI definitions, you can now use our CI linter to go deeper into pipeline processing to validate the correctness of your `.gitlab-ci.yml`. The CI linter provides feedback not only for syntax validation, but it also validates other kinds of logical errors and invalid configurations by simulating the pipeline as if you were running on master (without actually running anything). This helps you produce a properly configured pipeline faster and helps you avoid situations where a pipeline passed the linter but still could not run.
Continuous Integration (CI)[Configure a job artifact to never expire](https://docs.gitlab.com/ee/ci/yaml/#artifactsexpire_in):
> As a developer, you have the ability to specify a job artifact's exact expiration date, but there are scenarios where you may need to retain an artifact forever. Now, you can set an artifact to never expire by setting the value of `expire_in` to `never` in your CI configuration.
Continuous Integration (CI)[CI/CD rules:if support logical expressions with parentheses](https://docs.gitlab.com/ee/ci/yaml/#rulesif):
> **If** you use the `rules` keyword with `if` clauses, it's now even more powerful, with support for bracketed expressions evaluated by the pipeline processor. You can use more complex and efficient AND (`&&`) / OR (`||`) expressions, making your pipelines rules more logical, powerful, and easier to manage.
Continuous Integration (CI)[Package Registry now available in Core](https://docs.gitlab.com/ee/user/packages/):
> A year and a half ago, we expanded our support for Java projects and developers by building Maven support directly into GitLab. Our goal was to provide a standardized way to share packages and have version control across projects. Since then, we've invested to build out the Package team further while working with our customers and community to better understand your use cases. We also added support for Node, C#/.NET, C/C++, Python, PHP, and Go developers. Your increased adoption, usage, and contributions to these features have allowed us to expand our vision to a more comprehensive solution, integrated into our single application, which supports package management for all commonly-used languages and binary formats. This goal could not have been achieved without the explicit support of the GitLab community.
>
> As part of GitLab's stewardship promises, we are excited to announce that the basic functionality for each package manager format is now available in the GitLab Core Edition. This means that if you use npm, Maven, NuGet, Conan, PyPI, Composer or Go modules, you will be able to:
>
> - Use GitLab as a private (or public) package registry
> - Authenticate using your GitLab credentials, personal access, or job token
> - Publish packages to GitLab
> - Install packages from GitLab
> - Search for packages hosted on GitLab
> - Access an easy-to-use UI that displays package details and metadata and allows you to download any relevant files
> - Ensure that your contributions are available for ALL GitLab users
>
> We look forward to hearing your feedback and continuing to improve these features with all of our users.
Package Registry[Use CI job token to publish NuGet packages](https://docs.gitlab.com/ee/user/packages/nuget_repository/index.html#publishing-a-nuget-package-with-cicd):
> You can use the GitLab NuGet Repository to build, publish, and share .NET 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 NuGet Repository, or you may have decided not to use the repository at all.
>
> Now it is easier than ever for you to use GitLab CI/CD to publish and install NuGet packages using the pre-defined `CI_JOB_TOKEN` environment variable.
Package Registry[Improved presentation of package metadata and activity](https://docs.gitlab.com/ee/user/packages/package_registry/#view-packages):
> The GitLab Package Registry is where you store and share a variety of package formats. When you navigate to the user interface, you want to quickly understand how the package was built and how to install it. We've redesigned the package details page to prioritize recent activity, code snippets, and additional metadata. We removed the two-column table that had data that was duplicated or not useful.
>
> The main section of the package detail UI now includes:
>
> - A new "History" feed that shares the time-based metadata related to a package.
> - The installation commands and registry setup instructions.
> - A way to add "Additional Metadata" to capture any metadata not related to time. This additional metadata section offers the flexibility of including a variety of details specific to different package formats.
>
> This change is a clear sign that the Package Registry capabilities with GitLab are maturing. The 'ugly' table that we removed was a carry-over from the original Maven Repository. Back then, we only presented basic metadata like `name` and `created_date`. Now you can see how a package was built and trace back to which pipeline and which commit was responsible. We look forward to the continued evolution of this product. Enjoy and let us know what you think!
Package Registry[SAST security analyzers available for all](https://docs.gitlab.com/ee/user/application_security/sast/#making-sast-analyzers-available-to-all-gitlab-tiers):
> We want to help developers write better code and worry less about common security mistakes. [Static Application Security Testing (SAST)](https://docs.gitlab.com/ee/user/application_security/sast/) helps prevent security vulnerabilities by allowing developers to easily identify common security issues as code is being committed and mitigate proactively. As part of our [community stewardship commitment](/company/stewardship/#promises) we have made [all 15 of our open source based SAST analyzers](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) available in every [GitLab tier](/pricing/). This allows **ALL** GitLab users developing in any of our [18 supported languages and frameworks](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) to leverage GitLab SAST in their projects.
>
> Getting started is as easy as using our [new guided SAST configuration experience](https://docs.gitlab.com/ee/user/application_security/sast/#configure-sast-in-the-ui), enabling [Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/), or adding the [SAST configuration template](https://docs.gitlab.com/ee/user/application_security/sast/#configuration) to your `gitlab-ci.yml` file. Customers not on the Ultimate tier can interact with generated [SAST vulnerability report](https://docs.gitlab.com/ee/user/application_security/sast/#reports-json-format) by [downloading the SAST job artifact](https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#downloading-artifacts). We've also updated our docs with details about the [tier breakdown for all our SAST features](https://docs.gitlab.com/ee/user/application_security/sast/#summary-of-features-per-tier).
SAST[Kubernetes Pod health dashboard](https://docs.gitlab.com/ee/operations/metrics/dashboards/default.html#kubernetes-pod-health-dashboard):
> Seeing all of your system's metrics in one place, including cluster metrics, is critical for understanding the health of your system. In GitLab 13.3, you can view the health of your Kubernetes pods in the new out-of-the-box Pod health metrics dashboard, whether you are using a [managed Prometheus](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#managed-prometheus-on-kubernetes), or have an existing instance of Prometheus running in your cluster, by connecting it to your GitLab instance. Select the desired pod in the dropdown and see key metrics such as CPU, memory usage, Network, and more.
Metrics[Create and manage IT Incidents in GitLab](https://docs.gitlab.com/ee/operations/incident_management/incidents):
> Investigating incidents requires on-call engineers to evaluate different data sources across multiple tools. Assessing metrics, logs, and traces, sharing findings, and updating stakeholders requires engineers to manually aggregate information through screengrabs, copying, and pasting. This work is inefficient and time-consuming, which leads to alert fatigue, increased stress, and low morale.
>
> In 13.3, GitLab is excited to introduce a dedicated list for triaging and managing Incidents in the Operations section of GitLab to help you reduce resolution time. The [Incident list](https://docs.gitlab.com/ee/operations/incident_management/incidents) provides a high-level summary of the incident, and critical details: when it was created, who is assigned, and the [Status Page](https://docs.gitlab.com/ee/operations/incident_management/status_page.html#gitlab-status-page) publication state. Additionally, there are different views organized by status (open, closed, and all) making it easy to identify active incidents.
>
> In GitLab 13.4 and beyond we plan to improve incident response workflows by [surfacing related metrics charts](https://gitlab.com/gitlab-org/gitlab/-/issues/230848), [embedding logs](https://gitlab.com/gitlab-org/gitlab/-/issues/230849), and [rendering associated runbooks](https://gitlab.com/gitlab-org/gitlab/-/issues/230850). To view progress and suggest ideas for future improvements, see the [Incident Management epic](https://gitlab.com/groups/gitlab-org/-/epics/1494).
Incident Management[Simpler, streamlined Metrics dashboard control bar](https://docs.gitlab.com/ee/operations/metrics/):
> Previously, dashboard actions such as creating, editing, duplicating, and adding metrics were scattered across the metrics dashboard. GitLab 13.3 organizes these items into a single actions menu, simplifying access to dashboard management features.
Metrics[Display metrics dashboard data in gauge format](https://docs.gitlab.com/ee/operations/metrics/dashboards/panel_types.html#gauge):
> We've introduced gauge charts as a new visualization option on your monitoring dashboard to show progressive values for a single metric.
Metrics[Display metrics in alerts from externally-managed Prometheus](https://docs.gitlab.com/ee/operations/incident_management/index.html#view-an-alerts-metrics-data):
> When you receive alerts, GitLab helps you reduce investigation time by including the relevant metrics chart in the alert, helping you visualize what went wrong. In GitLab 13.3, we are introducing including metrics from an externally managed Prometheus instance within the alert.
Alert Management[Add runbooks to GitLab Alerts](https://docs.gitlab.com/ee/operations/metrics/alerts.html#linking-runbooks-to-alerts):
> When an incident occurs, knowing how to respond can be difficult if the on-call engineers didn't write the code causing an incident. Having access to runbooks, or knowledge about a metric causing alerts, is critical to identifying the root cause of a problem and solving it quickly. You can now add runbooks to the alerts you configure in GitLab so that triggered alerts provide your on-call team the steps needed to resolve the issue.
Incident Management[Link alerts from GitLab-managed Prometheus to logs](https://docs.gitlab.com/ee/operations/incident_management/alertdetails.html#view-an-alerts-logs):
> When triaging alerts, there's no time to lose: you must investigate quickly without context-switching. GitLab 13.3 saves you time by linking from the chart, located in the Metrics tab of an alert, to the logs for a metric.
Incident Management[Manually create Incidents from the Incidents List](https://docs.gitlab.com/ee/operations/incident_management/manage_incidents.html#from-the-incidents-list):
> When maintaining the availability and reliability of a service, you don't always learn of problems from your alerting systems: customers report outages, or team members spot anomalies. Regardless of the source, you can now manually create Incidents from the Incident List to mobilize your response teams when you learn of a problem.
Incident Management[Organize Incidents by status in list view](https://docs.gitlab.com/ee/operations/incident_management/incidents):
> When coordinating response teams across multiple incidents, it's extremely important to know which Incidents are open - and require immediate attention - and which ones are resolved and closed. GitLab 13.3 now separates Incidents by status and organizes them into tabs, helping you to focus on the relevant, open Incidents.
Incident Management[Create GitLab issues from PagerDuty Incidents](https://docs.gitlab.com/ee/operations/incident_management/manage_incidents.html#using-the-pagerduty-webhook):
> You can now generate GitLab issues from PagerDuty incidents, automatically notifying your responders when alerts are triggered, and centralizing your responses within GitLab.
Alert Management