GitLab.org/GitLab: Release v13.1.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 13.1
Released: 2020-06-22
License: MIT
Release Assets:
#### [Ultimate](https://about.gitlab.com/pricing/ultimate/)
##### [Plan](https://about.gitlab.com/stages-devops-lifecycle/plan/)
[Satisfy requirements from a CI job](https://docs.gitlab.com/ee/user/project/requirements/index.html#allow-requirements-to-be-satisfied-from-a-ci-job):
> Now that you're able to create requirements in GitLab, the next step towards a full requirements management solution is showing your requirements are satisfied.
>
> We're excited to release the first step by allowing you to configure jobs within the standard CI pipeline that, when triggered, will mark all existing requirements as satisfied. This CI job can be either manual or automatic, and like other CI jobs can be configured to allow failure so it doesn't block the pipeline from completing. Future iterations will allow [selectively satisfying requirements from pipeline testing](https://gitlab.com/gitlab-org/gitlab/-/issues/215514) as well as allowing our customers performing manual verification to [indicate satisfied requirements through the interface](https://gitlab.com/gitlab-org/gitlab/-/issues/218607).
Requirements Management[Dynamic Issue status icons on Security Dashboards](https://docs.gitlab.com/ee/user/application_security/security_dashboard/):
> Previously, in Security Dashboards, vulnerability list items with an
> associated issue displayed a static icon with a link to the issue. With
> this usability improvement, the icon now dynamically reflects whether the
> issue is open or closed. At a glance, you can now tell if a vulnerability
> might need additional attention.
Vulnerability Management[Export vulnerabilities list from Group Security Dashboards](https://docs.gitlab.com/ee/user/application_security/security_dashboard/#export-vulnerabilities-1):
>
> From the Group Security Dashboard, you can now download a CSV file containing
> detected vulnerabilities for all projects in a group. This export list can
> then be used for things such as creating compliance reports or as a data
> source for external dashboards. This joins the ability to export
> reports from the [Instance](https://docs.gitlab.com/ee/user/application_security/security_dashboard/#export-vulnerabilities-1)
> and [Project Security Dashboards](https://docs.gitlab.com/ee/user/application_security/security_dashboard/#export-vulnerabilities).
>
> Simply go to any Group Security Dashboard and click the new 'Export'
> button. Your browser will automatically start the download.
Vulnerability Management[Filters persist on Security Dashboards](https://docs.gitlab.com/ee/user/application_security/security_dashboard/):
> GitLab 13.0 introduced [standalone vulnerability pages](https://docs.gitlab.com/ee/user/application_security/vulnerabilities/) as an important
> step towards the future of Vulnerability Management. The switch from popup
> information boxes to independent pages, however, presented some new UI
> considerations.
>
> Navigating from the Security Dashboards to a vulnerability page and back
> previously cleared any filters applied on the dashboard. We received
> good feedback that improving this experience would improve the vulnerability
> triage and management experience. Your filters now
> persist when moving between vulnerability pages and a dashboard,
> greatly improving the efficiency of managing vulnerabilities. It also matches
> a familiar UX pattern found elsewhere in GitLab, such as managing your To-Do
> list.
Vulnerability Management[SAST Scanning for Helm Charts](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks):
> Our [Static Application Security Scanning (SAST) analyzer](https://docs.gitlab.com/ee/user/application_security/sast/) for [Kubernetes manifests](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) has been updated to support Helm Charts. This update also [adds support for two new environment variables](https://docs.gitlab.com/ee/user/application_security/sast/#analyzer-settings) to customize our analyzer settings: `KUBESEC_HELM_CHARTS_PATH` and `KUBESEC_HELM_OPTIONS`.
>
> A special thanks to [@agixid](https://gitlab.com/agixid) for their community contribution to this feature.
SAST[More prominent Secret Detection and new standalone Secret Detection template](https://docs.gitlab.com/ee/user/application_security/secret_detection/):
> Secret Detection has been promoted from a sub-feature of SAST to a [category](/direction/secure/secret-detection/secret-detection/) of its own. Secret Detection findings are now more visible, displaying in their own section in merge requests and pipeline security tabs. Secret Detection will also now display configuration status on the [Security Configuration Page](https://docs.gitlab.com/ee/user/application_security/configuration/) and display findings in [Project Security Dashboards](https://docs.gitlab.com/ee/user/application_security/security_dashboard).
>
> The Secret Detection CI/CD configuration settings are now provided in a separate GitLab-provided template and run as a new Secure scan type. This new Secret Detection template is also now [included in Auto DevOps](https://docs.gitlab.com/ee/user/application_security/#security-scanning-with-auto-devops). We recommend you [implement this new template](https://docs.gitlab.com/ee/user/application_security/secret_detection/#configuration) and then remove the [old SAST `secrets-sast` job definition](https://gitlab.com/gitlab-org/gitlab/-/blob/481ec0956fbc3d37ade25030126c109cb47bc95b/lib/gitlab/ci/templates/Security/SAST.gitlab-ci.yml#L180) from the [SAST configuration template](https://docs.gitlab.com/ee/user/application_security/sast/#configuration) in `SAST.gitlab-ci.yml` file. We have made a [video to guide you through the process of transitioning](https://www.youtube.com/watch?v=W2tjcQreDwQ&feature=emb_title) to this new template. We will deprecate the old SAST secret job definition in a future GitLab release.
Secret Detection[Policy Management for Container Network Policies](https://docs.gitlab.com/ee/user/application_security/threat_monitoring/#container-network-policy-management):
> With the first release of a policy management UI for Container Network Policies,
> users can easily scan a list of Network Policies deployed in their project
> and enable or disable those policies through GitLab's UI. You can find the new policy management experience
> at **Security & Compliance** -> **Threat Management** -> **Policies**.
Container Network Security[Status pages display images](https://docs.gitlab.com/ee/operations/incident_management/status_page.html#incident-detail-page):
> Images included in issue descriptions published to [GitLab status pages](https://docs.gitlab.com/ee/operations/incident_management/status_page.html) now render, giving meaningful context to customers, users, and stakeholders to help them make decisions about how to handle outages and performance degradations. Sharing visuals along with text raises transparency, which encourages user trust and confidence.
Alert Management[Contribution Analytics now show approvals](https://docs.gitlab.com/ee/user/group/contribution_analytics/#sorting-by-different-factors):
> Contribution Analytics helps teams understand how workload is balanced across many participants. Until now, the contributions of merge request approvers were overlooked, despite their valuable role in ensuring merge requests receive an appropriate level of review. The table of contributions per group member now includes a sortable **Approved MRs** column to display approvers by the number of approvals completed.
Value Stream Management[API support for setting multiple Feature Flags strategies](https://docs.gitlab.com/ee/operations/feature_flags.html#feature-flag-behavior-change-in-130):
> You can now create feature flag strategies and apply them to environments via a public API. Previously, strategies were bound to environments. Introducing new strategies required defining additional environments and attaching them to these environments. This new API will allow for defining strategies independent of environments.
Feature Flags[New Geo Disaster Recovery command for failover preflight checks](https://docs.gitlab.com/ee/administration/geo/disaster_recovery/planned_failover.html) (self-managed only):
> When performing a failover using GitLab Geo, systems administrators should perform a number of [preflight checks](https://docs.gitlab.com/ee/administration/geo/disaster_recovery/planned_failover.html#preflight-checks) before promoting a secondary to a primary to ensure that the failover is successful. Many of these preflight checks are manual, thereby increasing the chance of user errors.
>
> In GitLab 13.1, Geo includes a new command `gitlab-ctl promotion-preflight-checks` that lists all required [preflight checks](https://gitlab.com/gitlab-org/gitlab/-/issues/217461) and asks systems administrators to confirm that these checks were executed. The command is automatically run when running `gitlab-ctl promote-to-primary-node`.
>
> This is a first iteration [towards a simpler failover process](https://gitlab.com/groups/gitlab-org/-/epics/3131) and we plan to automate preflight checks in [future iterations](https://gitlab.com/groups/gitlab-org/-/epics/3279).
Disaster Recovery[IP access restriction available in Premium](https://docs.gitlab.com/ee/user/group/#ip-access-restriction-premium) (SaaS only):
> IP access restriction is now available for Premium and Silver tiers. This feature allows you to restrict access to groups and their underlying content by one or more IP subnets. Enabling IP access restriction ensures that particular content doesn’t leave the premises, while not blocking off access to the entire instance.
Authentication and Authorization[Explore Trends & Details in Issue Analytics ](https://docs.gitlab.com/ee/user/group/issues_analytics/index.html#drill-into-the-information):
> Issue Analytics allows users to quickly spot trends in issue data. To enhance this ability, you now have a table that lists key details such as issue age, status, milestone, weight, due date, assignees, and author. With this additional visibility, users may now follow the thread of their inquiry beyond the chart and into the specific issues behind the trend.
Planning Analytics[Added projects endpoint for Audit Events API](https://docs.gitlab.com/ee/api/audit_events.html#project-audit-events-starter):
> Thanks so much to [Julien Millau (@devnied)](https://gitlab.com/devnied) for this community contribution!
>
> GitLab's Audit Events API has been extended to add an endpoint for projects, enabling group owners to poll the API for specific project-level data. This change makes it easier to find and retrieve the data you need to manage your compliance programs, and build out tooling you need for the auditability and traceability of your GitLab projects.
Audit Events[Reduced index size in Advanced Global Search](https://docs.gitlab.com/ee/integration/elasticsearch.html#adding-gitlabs-data-to-the-elasticsearch-index):
> In previous versions of GitLab, Advanced Global Search's indexing process supported partial matching by storing a list of all partial words in the index. Partial words provide better results for natural-language search queries, but users performing code searches frequently search for specific text, like function definitions.
>
> Partial matching for code has been disabled in GitLab 13.1, reducing the index size by 75%. If desired, users can continue using partial matching by using wildcards in their code search query. Partial matching for other content types, like issues or merge requests, is still supported.
>
> Self-managed customers who have enabled Advanced Global Search must reindex after updating to take advantage of this reduction in index size.
Global Search[Improved Search API response time](https://docs.gitlab.com/ee/api/search.html):
> If you've ever used the search API, you might have noticed that some scope searches were averaging a response time of over 11000ms. This was clearly not very efficient.
>
> In GitLab 13.1, we addressed some N+1 database calls and as a result, we saw a 40% improvement in the response times! Scope searches have never been faster.
Global Search[Added audit event when a new SSH key is created via the API](https://docs.gitlab.com/ee/api/users.html#add-ssh-key-for-user):
> Thank you to [Rajendra Kadam (@raju249)](https://gitlab.com/raju249) for this community contribution!
>
> When an SSH key is created for a user via the API, either by the [user](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/34645) or an [administrator](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33859), you will now see this action logged in the audit events table. Previously, these actions were not logged and created a gap in the auditability of SSH credentials for a user.
Audit Events[Group membership allow list supports multiple email domains](https://docs.gitlab.com/ee/user/group/#allowed-domain-restriction-premium):
> In GitLab 13.1, Owners can now restrict group membership to users with email addresses across multiple domains instead of a single domain. This new configuration option will give you greater flexibility while securing access to your group.
Subgroups[Set Feature Flag Strategy Across Environments](https://docs.gitlab.com/ee/operations/feature_flags.html#create-a-feature-flag):
> In this release, we redesigned the feature flags UI to enable setting strategies for multiple environments. Previously, it was much more difficult to manage Feature Flags and set strategies as the number of environments increased. This improvement gives you more flexibility to create and apply strategies to environments at-scale.
Feature Flags[Control Feature Flags with User Lists](https://docs.gitlab.com/ee/operations/feature_flags.html#list):
> GitLab already supports the ability to [control feature rollout based on user IDs](https://docs.gitlab.com/ee/operations/feature_flags.html#user-ids).
> However, it's tedious to repeatedly add more users for every flag or environment.
> To make this process more convenient, we have added a new Feature Flag strategy called "lists."
> User lists are created and modified with the API. After creation, use them by choosing the "list" strategy for your feature flag and selecting the appropriate list. If you already have lists created, you can use them right away.
Feature Flags[Run tests for modified files first](https://docs.gitlab.com/ee/user/project/merge_requests/fail_fast_testing.html):
> As a developer, you want to get feedback quickly about your changes, including results of newly-written tests. In large projects like GitLab, this can be especially difficult with wait times up to 45 minutes just to see a new unit test pass, or — even worse — fail. This slowness can lead you to skip automated test development entirely.
>
> Ruby developers can shorten the feedback loop by using the TestFileFinder gem to find tests that target the modified code, then running those tests in an early stage in the pipeline. This is an [MVC approach](/handbook/values/#move-fast-by-shipping-the-minimal-viable-change) to solving the problem, but one we hope you're excited about. We look forward to feedback and ideas in the [TestFileFinder project](https://gitlab.com/gitlab-org/ci-cd/test_file_finder/-/issues).
Code Testing and Coverage[Use metadata to understand how your NuGet packages are built](https://docs.gitlab.com/ee/user/packages/#view-packages):
> When a NuGet package is uploaded to GitLab, a job opens the archive and reads the `.nuspec` file. The package name and version are extracted, but several other fields, like `dependencies`, `project_url` and `tags` are available but not extracted. These fields are useful for understanding how a package has been built and what its dependencies are.
>
> In GitLab 13.1, we are excited to announce that this metadata will now be extracted as part of the upload and included in the user interface so that you validate that package was built properly.
Package Registry[Documentation for blue-green deployments](https://docs.gitlab.com/ee/ci/environments/incremental_rollouts.html#blue-green-deployment):
> We've documented an example of a blue-green deployment using NGINX that swaps the deployments directly from the `.gitlab-ci.yml` file. This example will help you set up blue-green deployments if you're using a similar configuration, and provides guidance you can customize for other types of applications.
Continuous DeliveryBug fixes
> Some of the notable bug fixes in 13.1 are:
>
> - [GitLab release evidence is not being collected if release is created via UI](https://gitlab.com/gitlab-org/gitlab/-/issues/215162)
> - [Images overflow at releases list panel](https://gitlab.com/gitlab-org/gitlab/-/issues/212063)
> - [Release description markdown not displayed correctly](https://gitlab.com/gitlab-org/gitlab/-/issues/208148)
> - [Display downstream pipeline errors in upstream pipelines](https://gitlab.com/gitlab-org/gitlab/-/issues/200016)
> - [Attempts to download the artifacts archive for a tag ref via the Jobs API fails with "404 Not Found"](https://gitlab.com/gitlab-org/gitlab/-/issues/216055)
> - [Validate the size of the value for instance level variables](https://gitlab.com/gitlab-org/gitlab/-/issues/217936)
> - [Show accurate error message when pipelines are disabled, merge request 'must succeed' option is on, and external pipelines are disabled](https://gitlab.com/gitlab-org/gitlab/-/issues/216031)
> - [Respect "ref" parameter when searching for commits](https://gitlab.com/gitlab-org/gitlab/-/issues/199245)
> - [Make sure setting of Elasticsearch `highlight.max_analyzed_offset` parameter consist throughout GitLab application](https://gitlab.com/gitlab-org/gitlab/-/issues/218576)
> - [Fix nested Array issue with Elasticsearch version 7.7.0](https://gitlab.com/gitlab-org/gitlab/-/issues/218324)
> - [Don't show notes in confidential issues as confidential notes](https://gitlab.com/gitlab-org/gitlab/-/issues/217616)
> - [Show issues added to Epic via API in the Epic tree](https://gitlab.com/gitlab-org/gitlab/-/issues/207898)
> - [Apply scoped labels in order when added by title via API](https://gitlab.com/gitlab-org/gitlab/-/issues/207269)
> - [Enable `NOT` boolean filter for Epics](https://gitlab.com/gitlab-org/gitlab/-/issues/212579)
[GitLab chart improvements](https://docs.gitlab.com/charts) (self-managed only):
> - The `extraEnv` pattern is [now supported](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/1399) in the GitLab Helm charts. This allows you to expose additional environment variables, such as proxy servers, for specific GitLab charts or globally for all GitLab charts. Refer to the [global settings documentation](https://docs.gitlab.com/charts/charts/globals.html#extraenv) or [subchart documentation](https://docs.gitlab.com/charts/charts/gitlab/) for details on how to implement `extraEnv`.
> - Custom annotations configured in the `deployment` section of the global settings in `values.yml` are [now available](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/1567) in all GitLab subcharts. Deployment annotations allow you to grant access at the deployment level rather than the node level, such as allowing a deployment to read an Amazon S3 bucket without having to grant the entire node access to the bucket. For details on how to set up deployment annotations, see the [Annotations documentation](https://docs.gitlab.com/charts/charts/globals.html#annotations).
> - The PostgreSQL libraries and client in the GitLab container images have been [updated](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/2010) to PostgreSQL 12 to allow using more versions of PostgreSQL. Note that GitLab 13.1 still only supports PostgreSQL 11, but support for PostgreSQL 12 is [planned for a future release](https://gitlab.com/groups/gitlab-org/-/epics/2374).
> - For improved security, you can now [pass a Kubernetes secret](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/1969) for sensitive header values such as Authorization token for the endpoints when configuring Registry notifications. For setup, see the [Registry chart documentation](https://docs.gitlab.com/charts/charts/globals.html#notifications).
Cloud Native Installation[Use IAM roles for encrypted Amazon S3 buckets](https://docs.gitlab.com/ee/administration/object_storage.html#encrypted-s3-buckets) (self-managed only):
> You can now use AWS IAM roles for accessing encrypted S3 buckets. Previously, encrypted S3 buckets would not work at all. To learn more, see the [Object Storage documentation](https://docs.gitlab.com/ee/administration/object_storage.html#encrypted-s3-buckets).
Omnibus Package, Cloud Native Installation[In-product link to guidance for deploying to AWS](https://docs.gitlab.com/ee/ci/cloud_deployment/#aws):
> Setting up AWS deployments is not always as easy as we'd like it to be. To make it easier for you to use our AWS features, we've added in-product links to our AWS templates and documentation when you start adding AWS CI/CD variables. These links should help you get up and running faster.
Continuous Delivery[Search in a group from a project in the search box dropdown](https://docs.gitlab.com/ee/user/search/advanced_search.html):
> In GitLab 13.1, the search dropdown now gives you the option of searching in the group from a project that belongs to the group.
> Before GitLab 13.1, the search dropdown options did not include **in this group** if searching from a project.
Global Search[Simplified setup for integrating Terraform](https://docs.gitlab.com/ee/user/infrastructure/):
> You can run GitLab-integrated Terraform features more easily with one of the GitLab-provided Terraform images. The GitLab Terraform images extend the official Terraform images for Terraform versions 0.12 and 0.13 beta by including simple commands to use Merge Request widgets without bloating your CI/CD YAML files.
Infrastructure as Code[Improved authorization for GitLab-managed Terraform state](https://docs.gitlab.com/ee/user/infrastructure/#gitlab-managed-terraform-state):
> Changing your infrastructure is always a high-risk action; it should always be supervised, audited, and restricted to team members with permission. We introduced the GitLab-managed Terraform state with a known limitation in GitLab 13.0: you were required to provide a personal access token to work with the state file. This option did not scale well.
>
> Starting with GitLab 13.1, we've extended the scope of [the auto-generated CI token](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html) with the acting user's credentials. The token is designed specifically to run Terraform state management jobs, enabling you to securely run Terraform job pipelines without any additional setup.
Infrastructure as Code[New API for generating user access reports](https://docs.gitlab.com/ee/administration/audit_reports.html):
> One of the most important aspects of compliance is knowing who can access your business systems and resources. You need to know what role or permissions they possess so you can audit that access against your policies. Generating this type of evidence should be easy, so we've added a new API to provide group and project memberships for a user. You can now programmatically list all of the groups and projects a user belongs to along with their respective role for each resource. You no longer need to search through groups, projects, and logs to aggregate this data.
Audit Reports[Omnibus improvements](https://docs.gitlab.com/omnibus) (self-managed only):
> - GitLab packages are now available for [Raspbian Buster](https://www.raspberrypi.org/blog/buster-the-new-version-of-raspbian/). To download and install GitLab on Raspbian Buster, visit the [Install page](https://about.gitlab.com/install/).
> - New documentation has been added to the Database Settings page to explain [how to upgrade an external PostgreSQL database](https://docs.gitlab.com/omnibus/settings/database.html#upgrade-a-non-packaged-postgresql-database).
> - The version of NGINX bundled in Omnibus GitLab has been updated from 1.16.1 to 1.18.0.
> - The expiration of the GPG key used to sign GitLab Omnibus packages has been extended to July 2021. If you validate the signatures of the Omnibus package for your installation, you must also update your copy of the signing key. Note that this key is separate to the repository signing key that was updated in April 2020. See the Omnibus documentation for instructions on [how to update the key](https://docs.gitlab.com/omnibus/update/package_signatures#package-signatures).
> - GitLab 13.1 includes [Mattermost 5.23](https://mattermost.com/blog/mattermost-5-23-automatic-hyperlinking-to-jira-issues-and-more/), an [open source Slack alternative](https://mattermost.com/). The newest release includes automatic hyperlinking to Jira issues and more. This version also includes [security updates](https://mattermost.com/security-updates/), and upgrade from earlier versions is recommended.
Omnibus PackagePerformance improvements
> In every release, we continue to make great strides improving GitLab's performance. [We're committed](/handbook/product/gitlab-the-product/#performance) to making every GitLab instance faster. This includes GitLab.com, an instance with over 1 million registered users!
>
> In GitLab 13.1, we're shipping performance improvements for CI pipeline processing, viewing git blame, and much more! Some improvements in GitLab 13.1 are:
>
> - [Lazy load commit date and authored date for file blame](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/34181)
> - [Cache content when viewing file blame](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/33283)
> - [Optimized CI pipeline processing](https://gitlab.com/gitlab-org/gitlab/-/issues/197930#note_320405586)
[Pipeline success after failure notification](https://docs.gitlab.com/ee/user/profile/notifications#notifications-on-issues-merge-requests-and-epics):
> Each time a pipeline fails, you automatically receive an email notification. However, when the pipeline succeeds after failure, no automatic notification is sent, which requires you to manually check the pipeline's status. In this release, we are excited to include a community contribution by [@jacopo-beschi](https://gitlab.com/jacopo-beschi) that solves this problem by automatically notifying you if a pipeline succeeds after a failure.
Continuous Delivery[Specify asset types for Release links](https://docs.gitlab.com/ee/user/project/releases/#links):
> GitLab now lets you conveniently specify the kind of asset link you have added to your Release with a dropdown menu. Previously, if you added links to a release, you were unable to communicate what type of asset it was. With this addition, you can choose the type of asset from the following options: "Runbook", "Package", "Image", or "Other."
Release Orchestration[Add optional expires_at parameter to /user/keys endpoint](https://docs.gitlab.com/ee/api/users.html#add-ssh-key):
> Thanks to [Petar Prokic (@pprokic)](https://gitlab.com/pprokic) for this community contribution!
>
> The Users API `/user/keys` and `/users/:id/keys` endpoints now support an optional `expires_at` parameter to define an expiration date for SSH keys. This change can help users and organizations manage the impact of a compromised credential in a regulated environment.
Compliance Management[Assign issues faster](https://docs.gitlab.com/ee/user/discussions#assign-an-issue-to-the-commenting-user):
> GitLab loves to make user workflows as easy as possible. You can now assign an issue to a commenter, right next to the comment, with the click of a button. This keeps your focus and effort centered around the comments, rather than having to navigate to the side panel or use a quick assign command.
Issue Tracking[Issue titles are now sticky](https://docs.gitlab.com/ee/user/project/issues/):
> Issue titles will now always remain visible at the top of the issue, regardless of what part of the issue you're reading. This ensures that you'll always have context, regardless of whether you've clicked a link to a deep conversation thread, scrolled deep within an issue, or you're working with multiple tabs of similar issues.
Issue Tracking[Gitaly Cluster automatic failover enabled by default](https://docs.gitlab.com/ee/administration/gitaly/praefect.html#automatic-failover-and-leader-election) (self-managed only):
> Gitaly Cluster improves fault tolerance of Git storage in GitLab by removing single points of failure, detecting
> outages, and automatically switching to a replica. From GitLab 13.1, when Gitaly Cluster is configured, SQL leader
> election and automatic failover are enabled by default.
>
> If unreplicated write operations are detected during failover, the cluster is put into read only mode to prevent
> a [split brain](https://en.wikipedia.org/wiki/Split-brain_(computing)). In the future,
> [strong consistency](https://gitlab.com/groups/gitlab-org/-/epics/1189) will require that write operations succeed
> on multiple Gitaly nodes before responding with a success signal, preventing this problem and the need to mark the
> cluster read only.
>
> Previously in GitLab 13.0, in memory leader election was default instead of automatic failover.
Gitaly[Distribute reads across Gitaly Cluster (beta)](https://docs.gitlab.com/ee/administration/gitaly/praefect.html#distributed-reads) (self-managed only):
> Gitaly Cluster allows you to replicate Git repositories on multiple warm
> Gitaly nodes, improving fault tolerance by removing single points of
> failure.
>
> In GitLab 13.1, Git read operations can be distributed between up-to-date
> Gitaly replicas. This makes better use of the available resources, and can
> improve performance.
>
> This feature is being released as
> [beta](https://docs.gitlab.com/ee/policy/experiment-beta-support.html) while we evaluate its performance
> under production loads.
Gitaly[Hide YAML front matter in the Static Site Editor](https://docs.gitlab.com/ee/user/project/static_site_editor/#static-site-editor):
> Static site generators consume the first few lines ("front matter") at the beginning of a Markdown file, between two `---` lines, to format, configure, or parse the page. Front matter isn't meant to be displayed alongside the content of the page, and must conform to specific formatting rules.
>
> GitLab's Static Site Editor now includes a rich content editing experience that parses the Markdown syntax and displays it in a more familiar style. However, the front matter, not being intended for display, gets rendered unexpectedly in this context, and editing it using the visual editor can have unintended consequences.
>
> GitLab 13.1 hides any YAML-formatted front matter included at the beginning of the Markdown file to prevent any confusion or unintended formatting changes. The front matter remains editable in the raw source editor, available by toggling the editor mode in the bottom right of the Static Site Editor.
Static Site Editor[Link and preview images in the Static Site Editor](https://docs.gitlab.com/ee/user/project/static_site_editor/#static-site-editor):
> The Static Site Editor offers immediate visual feedback when writing Markdown content, and intuitive formatting controls to ensure consistent and accurate markup. However, this visual editing experience introduced in GitLab 13.0 was limited to text content.
>
> In GitLab 13.1, you can quickly add images to your pages using the Static Site Editor. After clicking the Image icon in the formatting bar, just link to a URL, add optional [ALT text](https://moz.com/learn/seo/alt-text), and you're done. The link can reference images already hosted in your project, an asset hosted externally on a content delivery network, or any other external URL. The editor renders thumbnail previews so you can verify the correct image is included and there aren't any references to missing images.
Static Site Editor[EditorConfig support in the Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/index.html#configure-the-web-ide):
> Developers collaborating on projects follow certain coding standards and styles to maintain consistent levels of readability and formatting in the project. This configuration is often done through an [`.editorconfig`](https://editorconfig.org/) file inside of the project which provides instructions like indent style, indent size, and line endings.
>
> When opening a file, the Web IDE looks for a file named `.editorconfig` in the current directory and all parent directories. If a config file is found and has settings that match the file's path, the settings will be enforced on the opened file. The Web IDE provides support for most of the [widely supported features](https://github.com/editorconfig/editorconfig/wiki/EditorConfig-Properties#widely-supported-by-editors) of EditorConfig with an exception for [`charset`](https://github.com/editorconfig/editorconfig/wiki/EditorConfig-Properties#charset).
Web IDE[Paste image in Markdown in the Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/index.html#markdown-editing):
> When working with Markdown content in the Web IDE, you may need to add images to the content. Adding images in most editors requires finding that image, adding it to the directory structure and then referencing it through markdown syntax.
>
> The Web IDE now supports pasting images directly into the editing window. Copy an image to your clipboard, place your cursor in your the Web IDE where you'd like the image to appear, and paste. The image will automatically be uploaded to your project and appropriately referenced inside of your content, greatly speeding up the content creation process and reducing complexity for users.
Web IDE[Web IDE Terminal and File Sync moved to Core](https://docs.gitlab.com/ee/user/project/web_ide/index.html#interactive-web-terminals-for-the-web-ide):
> GitLab 11.6 introduced [Web Terminals for the Web IDE](/releases/2018/12/22/gitlab-11-6-released/#web-terminal-for-web-ide-beta). Several releases later, [file syncing to the Web Terminal](/releases/2019/06/22/gitlab-12-0-released/#file-syncing-to-web-terminal) was added, enabling the Web Terminal to interact with changes made in the Web IDE.
>
> Earlier in 2020, GitLab committed to [moving 18 features](/blog/2020/03/30/new-features-to-core/) to our open source core product. With this release of GitLab we've completed the work to move both the Web Terminal and File Sync utility to Core. We're excited about bringing these features to more users, and seeing what use cases and workflows you're able to use them for.
Web IDE[Mark any Design thread as resolved](https://docs.gitlab.com/ee/user/project/issues/design_management.html#resolve-design-threads):
> When you receive lots of feedback on a Design, the number of comment pins can build up quickly! As your discussion thread grows, it gets hard to know which discussions are complete and which still need work.
>
> With 13.1, you’ll have the ability to mark any comment as **Resolved** to signify that it is now complete. Even better — your resolved comment pins will disappear from the Design so you can focus on what’s left! And, of course, if you need to revisit something, all of your resolved threads will be available in the **Resolved Comment** area at the bottom of the sidebar. From there, you can find them again and see which revision applied at the point of revision.
>
> We think this will greatly improve your workflow so you can focus on what is important.
Design Management[Merge Request Reviews moved to Core](https://docs.gitlab.com/ee/user/discussions/index.html#merge-request-reviews):
> Originally introduced in GitLab 11.4 as a GitLab Premium feature,
> Merge Request Reviews
> allow merge request reviewers to submit multiple comments at once, cutting down on notification noise
> for the merge request author, and allowing for a more cohesive and streamlined review process.
>
> Since its introduction, we've re-evaluated its place in our
> [buyer-based pricing model](https://about.gitlab.com/company/pricing/#four-tiers)
> and as part of 13.1 we're excited to announce this feature has now moved to GitLab Core.
Code Review[Code Intelligence](https://docs.gitlab.com/ee/user/project/code_intelligence.html):
> 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. Easily browsing definitions while writing new code
> or reviewing changes to existing code allows developers to gain a better understanding
> of the software being written. This is extremely useful when reviewing new code as well as code
> changes in merge requests. However, setting up browsable definitions generally meant configuring
> external tools and resources, or using a dedicated IDE. With GitLab, this is no longer the case.
>
> Taking inspiration in the great work done by our partners at [Sourcegraph](https://about.sourcegraph.com/)
> and powered by the [LSIF format](https://lsif.dev/),
> GitLab's native Code Intelligence can be added to any project by adding a
> new job to the project's `.gitlab-ci.yml` file, which specifies an LSIF report.
> Once generated, hovering over objects in your code will present the available
> code intelligence actions. No external tools or IDEs required.
>
> Future iterations will include the ability to find references, as well as API support. You can
> follow along in the [Code Intelligence epic](https://gitlab.com/groups/gitlab-org/-/epics/1576).
Source Code Management, Code Review[GitLab Runner 13.1](https://docs.gitlab.com/runner):
> We're also releasing GitLab Runner 13.1 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:
>
> - [Support Windows 1903 for GitLab Runner Windows Docker Executor](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/4396)
> - [Support Windows 1909 for GitLab Runner Windows Docker Executor](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/6212)
> - [Provide packages for RHEL/CentOS 8.](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/21671)
> - [Run any step defined in the job response.](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/6409)
> - [Kubernetes executor supports Docker authorization configuration for private registries.](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/2673)
>
> #### Bug Fixes:
>
> - Fix: [Build occasionally gets "No such file or directory" accessing build directory.](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/1379)
> - Fix: [Long running jobs canceled in GitLab UI, but Runner continues process.](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3376)
> - Fix: [Runners fail to maintain heartbeat with GitLab server while building a job.](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3854)
> - Fix: [Job gets stuck with attach strategy on Kubernetes](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/25346).
> - Fix: [Kubernetes attach invalid log timestamp when parsing logs](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/25377).
> - Fix: [Kubernetes attach issue when build script generates a long line](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/24928).
> - Fix: [End of output from Runner getting lost](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/25718).
> - Fix: [Failing to publish Windows helper images](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/25976).
>
> The list of all changes is in the GitLab Runner [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/v13.1.0/CHANGELOG.md).
Continuous Integration (CI)[Filter pipelines by pipeline status and tag name](https://docs.gitlab.com/ee/ci/pipelines/#view-pipelines):
> You can now filter by pipeline status or by tag name on the pipelines page. With filtering, viewing all pipelines for a specific tag, or narrowing the list of pipelines to a specific pipeline status (such as failed or skipped) is much easier. With these additions to the existing filter options, pinpointing your desired pipeline is easier than ever, and saves time in your day.
Continuous Integration (CI)[Instance-level CI/CD variables](https://docs.gitlab.com/ee/api/instance_level_ci_variables.html):
> GitLab now supports instance-level variables. With this ability to set global variables, you no longer need to manually enter the same credentials repeatedly for all your projects. This MVC introduces access to this feature by API, and the next iteration of this feature will provide the ability to configure instance-level variables directly in the UI.
Continuous Integration (CI)[Templates to simplify initial rules keyword configuration](https://docs.gitlab.com/ee/ci/yaml/#workflowrules-templates):
> It can be hard to figure out how to use the new `rules` keyword, especially if you previously used `only/except`, as the two are fundamentally different. The `rules` keyword creates a merge request pipeline by default, and `only/except` doesn't.
>
> To ease getting started, and getting to your first green pipeline with `rules` more quickly, we've added the two most common `workflow: rules` configurations as bundled templates. These make it much easier to get things working right away, letting you focus on what's important.
Continuous Integration (CI)[Accessibility Testing Merge Request Widget](https://docs.gitlab.com/ee/user/project/merge_requests/accessibility_testing.html#accessibility-merge-request-widget):
> Today, developers who want to ensure their application is accessible to everyone suffer from slow feedback loops, which make it difficult to catch degradations in their code. GitLab's full accessibility report was a start, but using that report to see what has changed in a single Merge Request is a manual and slow process.
>
> In GitLab 13.1, merge requests can have a widget that details accessibility degradations related to the changed pages. This will immediately show developers the impact of their changes, which helps prevent degradations before they are merged and deployed.
Accessibility Testing[Graph code coverage changes over time for a project](https://docs.gitlab.com/ee/ci/pipelines/settings.html#code-coverage-history):
> All too often, a project has a code coverage target but development teams might not have much visibility into which direction that target value is trending over time. There needs to be an easier way to track changes in code coverage over time without that extra hassle.
>
> The Code Coverage graph now provides better visibility into how code coverage is trending over time. It displays a simple graph of the coverage value(s) calculated in pipelines. We are looking forward to [feedback from customers](https://gitlab.com/gitlab-org/gitlab/-/issues/219659) on this feature as we plan improvements and future iterations.
Code Testing and Coverage[Download job artifacts faster and easier](https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#downloading-artifacts):
> GitLab allows you to [define pipeline job artifacts](https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#defining-artifacts-in-gitlab-ciyml), making them easy to [browse](https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#browsing-artifacts) and [download](https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#downloading-artifacts) in the GitLab UI. Previously, you could only download the entire artifact archive for a pipeline or job.
>
> We wanted to make it faster and easier to quickly access any report artifact file directly. This is particularly useful for Security scanning reports and code quality reports which you may want to download for use in other tools.
>
> With GitLab 13.1 we added support for downloading the following types of individual [artifact reports](https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html#artifactsreports):
>
> - accessibility
> - archive
> - cobertura
> - codequality
> - container_scanning
> - dast
> - dependency_scanning
> - dotenv
> - junit
> - license_management
> - license_scanning
> - lsif
> - metrics
> - performance
>
> This feature is available for all GitLab users. However, artifact report types vary across GitLab tiers.
SAST, DAST, Container Scanning, License Compliance, Dependency Scanning[Rails SAST analyzer available for all](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks):
> 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 contributed, and mitigate them proactively. As part of our [community stewardship commitment](/company/stewardship/#promises), we are making our Rails [SAST analyzer](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) (Brakeman) available in every [GitLab tier](/pricing/). This will allow **ALL** GitLab users developing in Rails to leverage [SAST Security Scans](https://docs.gitlab.com/ee/user/application_security/sast/) for their projects.
> We will continue to move other open source (OSS) SAST analyzers to Core. You can follow our [SAST to Core epic](https://gitlab.com/groups/gitlab-org/-/epics/2098) to see when other analyzers will become available, and contribute to this effort.
SAST[Metric dashboard panels display related dashboard links](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#add-related-links-to-custom-dashboards):
> A Metric Dashboard is often related to other dashboards. With Dashboard Links, you can display links to related GitLab Metrics and Grafana dashboards that preserve the time window of the dashboard you're currently viewing.
Metrics[Column sorting for Alert list](https://docs.gitlab.com/ee/operations/incident_management/index.html#alert-management-list-sorting):
> Alerts are often noisy and plentiful. To make it easier for you to find the newest or most severe alerts quickly, you can now sort the alert list by descending and ascending values.
Alert Management[Assign GitLab Alerts to team members](https://docs.gitlab.com/ee/operations/incident_management/index.html#update-an-alerts-assignee):
> In GitLab 13.1, you can assign GitLab alerts to specific users on your team, streamlining triage workflows, delegating problems that require investigation, and ensuring no critical alert gets dropped.
Alert Management[Metrics dashboard configuration validation](https://docs.gitlab.com/ee/operations/metrics/dashboards/yaml.html#dashboard-yaml-syntax-validation):
> Configuring a dashboard YAML file can be complex and error-prone. GitLab 13.1 adds validation to your YAML file to help you diagnose problems with your metrics dashboard by displaying a warning message
> if your dashboard YAML definition is invalid.
Metrics[Create GitLab To-Dos when assigning alerts](https://docs.gitlab.com/ee/operations/incident_management/index.html#update-an-alerts-assignee):
> Responders can now assign alerts to team members to help organize triggered alerts, delegating problems for investigation by a specific team member. Adding a [GitLab To-Do list item](https://docs.gitlab.com/ee/user/todos.html) tells the team member something needs their attention.
Alert Management[Metric dashboard legends in table format](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#getting-metrics-to-display-on-the-metrics-dashboard):
> Understanding charts without appropriate context can be difficult. In GitLab 13.1, we made it easier for you to compare data when inspecting charts by displaying chart legends in a tabular format.
Metrics[Metric dashboard panels display external links](https://docs.gitlab.com/ee/operations/metrics/dashboards/index.html#add-related-links-to-custom-dashboards):
> Metric panels are most useful when they facilitate drill-down. In GitLab 13.1, you can add custom URLs to the **More actions** menu for panels in your metrics dashboard, cross-linking your metrics panel and dashboard with other metrics dashboards and additional troubleshooting tools your team uses.
Metrics[Self monitoring dashboard for Omnibus GitLab users](https://docs.gitlab.com/ee/administration/monitoring/gitlab_self_monitoring_project/):
> In GitLab 13.1, Omnibus GitLab users will have a new out-of-the-box dashboard in their self-monitoring project to monitor the health of their GitLab instance.
Metrics[Collaborate on GitLab Alerts in Slack](https://docs.gitlab.com/ee/user/project/integrations/slack.html):
> We've added commands to our [Slack notifications service](https://docs.gitlab.com/ee/user/project/integrations/slack.html) so you can forward Alerts to Slack, notifying responders of an outage, and enabling responders to begin collaborating without leaving their central communication platform.
Alert Management[Alert assignments logged in system notes](https://docs.gitlab.com/ee/operations/incident_management/index.html#alert-system-notes):
> The ability to audit alerts is important for feedback and improvement, but there's rarely time during a fire-fight to document the details you'll need later. In GitLab 13.1, alert assignments are added to the system notes of an Alert so you can discuss them in your post-incident review.
Alert Management[Metric dashboards now support UTC](https://docs.gitlab.com/ee/operations/metrics/dashboards/settings.html#change-the-dashboard-time-zone):
> GitLab 13.1 now enables metrics dashboards to display time in UTC, enabling distributed team members working together to see the same time-series data, regardless of the team members' physical locations.
Metrics[Manage IT Alerts in GitLab](https://docs.gitlab.com/ee/operations/incident_management/index.html):
> When firefighting, responders must coordinate multiple tools and evaluate different data sources to collect and assess metrics, logs, and traces. Sharing these with a response team involves screen-grabbing, then copying and pasting data into a single ticket, to keep all stakeholders informed. This work is manual, time-consuming, tiring, and stressful. It leads to alert fatigue, increased stress, sinking morale, and - most importantly - missed alerts.
>
> GitLab is excited to introduce Alert Management to aggregate multiple IT service alerts in one interface, helping your team triage alerts and promote them to Incidents. We've added the ability to triage alerts in a [list view](https://gitlab.com/groups/gitlab-org/-/epics/2986), [view alert details](https://gitlab.com/groups/gitlab-org/-/epics/2987), [assign alerts](https://gitlab.com/groups/gitlab-org/-/epics/3349), [update the status of alerts](https://gitlab.com/gitlab-org/gitlab/-/issues/214542), and [create Incident Issues from Alerts](https://gitlab.com/gitlab-org/gitlab/-/issues/213909).
>
> In GitLab 13.2 and beyond, we plan to improve alert and incident response workflows by [integrating with PagerDuty](https://gitlab.com/gitlab-org/gitlab/-/issues/119019), surfacing relevant [metrics](https://gitlab.com/gitlab-org/gitlab/-/issues/217768) and [logs](https://gitlab.com/gitlab-org/gitlab/-/issues/217769) on alerts, [associating runbooks](https://gitlab.com/gitlab-org/monitor/health/-/issues/21), and creating an [Alert Integration Builder](https://gitlab.com/gitlab-org/gitlab/-/issues/217766), so your operators can self-serve and seamlessly integrate GitLab with any monitoring tool. To view our progress and suggest ideas for future improvements, see the [Alert Management epic](https://gitlab.com/groups/gitlab-org/-/epics/3066).
Alert Management