GitLab.org/GitLab: Release v13.2.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 13.2
Released: 2020-07-22
License: MIT
Release Assets:
[Advanced Global Search now available on GitLab.com](https://docs.gitlab.com/ee/user/search/advanced_search.html) (SaaS only):
> Prior to this release, GitLab.com users who wanted to do a cross-project code search would have to clone the repositories and search locally on their machine, a time-consuming and frustrating task.
> With GitLab 13.2, Bronze and higher GitLab.com groups can now perform group-wide code searches directly in the UI, by using [Advanced Global Search](https://docs.gitlab.com/ee/user/search/advanced_search.html). Advanced Global Search adds the ability to search code across all projects in a group, improves search relevancy and performance, allows scoping, and enables [Advanced Search Syntax](https://docs.gitlab.com/ee/user/search/advanced_search.html). This will make the experience of searching for content in GitLab much more powerful, enabling users to more easily find their content.
Global Search[Official GitLab-Figma Plugin](https://docs.gitlab.com/ee/user/project/issues/design_management.html#gitlab-figma-plugin) (SaaS only):
> Recently, the GitLab product design team and our open source [Pajamas Design System](https://design.gitlab.com/) switched over to Figma. We decided to build a new Figma plugin, which allows for easy uploads from Figma to issues on GitLab.com. This makes it quick and easy to collaborate on Designs. Connect your design environment with your source code management in a seamless workflow.
>
> In 13.2 we launched the official plugin on the Figma directory:
>
> - [Download and install the plugin](https://www.figma.com/community/plugin/860845891704482356/GitLab).
> - [Give us feedback](https://gitlab.com/gitlab-org/gitlab-figma-plugin/-/issues/44).
> - Contribute to the [GitLab-Figma project](https://gitlab.com/gitlab-org/gitlab-figma-plugin).
> - View our [GitLab Pajamas UI Kit in Figma](https://www.figma.com/file/qEddyqCrI7kPSBjGmwkZzQ/Pajamas-UI-Kit).
Design Management[Include CI test results in Release Evidence](https://docs.gitlab.com/ee/user/project/releases/#include-report-artifacts-as-release-evidence-ultimate):
> GitLab is expanding our [12.6 Release Evidence](/releases/2019/12/22/gitlab-12-6-released/#automated-release-evidence-collection-to-support-audits) feature by adding CI test results. These job artifacts, generated by the pipeline, are automatically included in the release evidence JSON file. As an Ultimate user, you will be able to effortlessly provide an auditor or compliance process with the relevant changes to production. You can download the evidence JSON and show corresponding test results organically as a part of using GitLab without disrupting your normal workflow.
Release Evidence[Show expired or revoked SSH keys and PATs in the credentials inventory](https://docs.gitlab.com/ee/administration/credentials_inventory.html) (self-managed only):
> Managing user credentials is an important element of any compliance program and requires visibility for the compliance professionals tasked with ensuring policies are being followed. The credentials inventory now highlights any SSH key or Personal Access Token (PAT) which has expired. Additionally, revoked PATs will also be highlighted to provide compliance professionals the necessary insight they need to conduct a review of user credentials.
>
> This change is part of a [larger initiative](https://gitlab.com/groups/gitlab-org/-/epics/3084) to make credential management within GitLab more simple, friendly, and flexible for customers to implement the processes that make the most sense for their users and organization.
Compliance Management[Toggle enforcement of Personal Access Token (PAT) expiration](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#optional-enforcement-of-personal-access-token-expiry) (self-managed only):
> You can now toggle enforcement of PAT credential expiration when a [lifetime limit](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings.html#limiting-lifetime-of-personal-access-tokens) is defined and met or exceeded by a personal access token. This optional enforcement provides flexibility to organizations for how they wish to manage credential rotations. This change is part of a [larger solution](https://gitlab.com/groups/gitlab-org/-/epics/3084) to make credential management in GitLab both effective for organizations and friendly for developers.
Compliance Management[Associate Feature Flags with related issues](https://docs.gitlab.com/ee/operations/feature_flags#feature-flag-related-issues):
> We have added the ability to associate related issues with their respective feature flags. For example, you can link the issue that introduced the feature flag itself. That relationship is visible in the feature flag details and will make it easier to find the reasons why a flag was originally introduced. It will also make it easier to follow the issue's milestone and status directly from the feature flag itself to get better visibility into the feature details.
Feature Flags[Amazon ECS Role authentication for Advanced Global Search](https://docs.gitlab.com/ee/integration/elasticsearch.html#enabling-elasticsearch) (self-managed only):
> Previously, when connecting to Amazon Elasticsearch Service on AWS to enable Advanced Global Search, you could only use static credentials or EC2 IAM roles via `Aws::InstanceProfileCredentials`.
> Now, as an additional authentication option, you can use [IAM roles for Amazon ECS tasks](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/task-iam-roles.html).
>
> Thank you to [Jason Barbier @kusuriya](https://gitlab.com/kusuriya) for this community contribution!
Global Search[Approval group changes in Audit Events](https://docs.gitlab.com/ee/administration/audit_events.html#project-events-starter):
> Audit events already capture changes made to merge request approvals. In 13.2, we're completing the loop by adding details about the changes to approval groups. When changes are made to merge request approval rules, you should now see a more complete view of the changes.
Audit Events[Geo supports replicating GitLab Package Registries](https://docs.gitlab.com/ee/administration/geo/replication/datatypes.html) (self-managed only):
> Geo now supports replicating [Package Registries](https://docs.gitlab.com/ee/user/packages/) to
> secondary nodes, allowing distributed teams to access them from
> the closest Geo node, which reduces latency and improves the overall user experience.
> Additionally, the Package Registry assets can also be restored from a secondary node when
> failing over to that node.
>
> We currently [don't support verification](https://docs.gitlab.com/ee/administration/geo/replication/datatypes.html#limitations-on-replicationverification)
> of these assets but future support is planned.
Geo-replication, Package Registry, Disaster Recovery[Geo supports pausing database replication on a Geo secondary](https://docs.gitlab.com/ee/administration/geo/index.htmlpausing-and-resuming-replication) (self-managed only):
> Geo replicates data from a primary Geo node to one or several Geo
> secondary nodes. While Geo supports pausing replication for
> repositories and files via the administrator interface, it was
> not possible to pause database replication. In 13.2, Geo supports
> pausing and resuming replication of all replicated data, including the
> PostgreSQL database using the new `gitlab-ctl geo:pause` and `gitlab-ctl geo:resume` commands on a secondary Geo node.
>
> This allows systems administrators to pause all replication on a
> secondary Geo node while performing critical maintenance operations on
> the primary Geo node. In the case of a failure on the primary, no
> changes are replicated to the paused secondary node, which can then be
> used to failover to.
Geo-replication, Disaster Recovery[Faster Geo replication performance for Projects](https://docs.gitlab.com/ee/administration/geo/index.html) (self-managed only):
> GitLab Geo makes distributed teams work more efficiently, creating and maintaining a local copy of GitLab that reduces latency so they don't have to wait for files to download over long distances. In this update to Geo, we're improving how the database manages changes. To determine what needs to be replicated from the primary, Geo compares the tracking database to the read-only secondary database. If Geo’s
> database queries time out, data can’t be replicated successfully. In
> GitLab 13.2, we use a [new approach to synchronize Projects](https://gitlab.com/gitlab-org/gitlab/-/issues/212351), thereby
> eliminating the possibility of database statement timeouts. We also
> improved the way we remove data from secondary nodes for all data sources, which increases the overall scalability and performance of GitLab Geo.
>
> These iterations bring us closer to removing Geo’s dependency on [Foreign Data Wrappers](https://wiki.postgresql.org/wiki/Foreign_data_wrappers), which were added for improved performance, but which make Geo more complex and harder to maintain.
Geo-replication, Disaster Recovery[Geo settings forms easier to read and validate input](https://docs.gitlab.com/ee/administration/geo/replication) (self-managed only):
> Systems administrators can adjust Geo settings for individual nodes using
> the administrator interface. Until now, these forms contained some
> outdated user interface elements, displayed too much optional
> information, and some inputs were not properly validated.
>
> In GitLab 13.2, the [individual Geo node
> settings](https://gitlab.com/gitlab-org/gitlab/-/issues/215027) and
> [general Geo
> settings](https://gitlab.com/gitlab-org/gitlab/-/issues/216134) validate
> user input and are divided into different sections (for example,
> "Performance and resource management") to make it easier for systems
> administrators to find related settings.
Geo-replication, Disaster Recovery[Geo's failover preflight-checks command checks replication status](https://docs.gitlab.com/ee/administration/geo/disaster_recovery/planned_failover.html#preflight-checks) (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) using the `gitlab-ctl promotion-preflight-checks` command.
>
> In GitLab 13.2, the `gitlab-ctl promotion-preflight-checks` command now [automatically checks the replication status](https://gitlab.com/gitlab-org/gitlab/-/issues/217465) and informs you of the results, removing a step that used to be performed manually. The `gitlab-ctl promote-to-primary-node` command also supports [a force mode](https://gitlab.com/gitlab-org/gitlab/-/issues/217462), which means a failover will proceed even when some preflight checks fail.
>
> This is an iteration [towards a simpler failover process](https://gitlab.com/groups/gitlab-org/-/epics/3131) and we plan to automate preflight checks further in [future iterations](https://gitlab.com/groups/gitlab-org/-/epics/3279).
Disaster Recovery[Option to delay project removal](https://docs.gitlab.com/ee/user/group/index.html#enabling-delayed-project-removal-premium):
> In GitLab 13.2, we've improved the project removal experience to be consistent across all pricing tiers and introduced a group-level toggle to allow you to enable a deletion delay period before permanent removal. Previously, the default behavior for removing a project was different across Tiers. Projects would be immediately removed in the Free/Core and Bronze/Starter Tiers and delayed by 7 days in the Silver/Premium and Gold/Ultimate Tiers.
>
> Now, this behavior is consistent across the board and removing a project will result in the immediate removal of that project. To ensure you still have flexibility in this workflow, we've introduced a group-level toggle to "Enable delayed project removal" for groups and projects where preventing data loss is a key requirement. Deleting a project should be easy when it needs to be and have safeguards in place for organizations with stricter requirements around preserving their intellectual property.
Compliance Management[Zero downtime reindexing for Advanced Global Search](https://docs.gitlab.com/ee/integration/elasticsearch.html#indexing-through-the-administration-ui):
> With the previous version of Advanced Global Search, if you needed to reindex, you would have to plan for Advanced Global Search to be down. Search results were unavailable while the index was deleted and the new index created.
> In 13.2, we have added index aliases that allow you to reindex without any downtime with a press of a button in the admin settings. Going forward Advanced Global Search can be reindexed without disrupting any of your users' workflow! This is important, because on larger instances it can take some time for the reindex to complete.
Global Search[Assign issues to iterations](https://docs.gitlab.com/ee/user/group/iterations):
> Prior to this release, there was no way to associate an issue with more than one timebox in GitLab. This has been particularly problematic for teams that follow Scrum or XP. Such teams often need to associate issues with iterations/sprints, while also rolling that issue up to longer-running milestones, such as program increments.
>
> Instead of having to decide whether to use milestones for sprints or program increments and track the other in a spreadsheet, you can now assign issues to iterations, milestones, or both.
>
> This is the first MVC towards a [longer term
> vision](https://gitlab.com/groups/gitlab-org/-/epics/2422#mvc-user-flow)
> we have for empowering teams to more effectively use timeboxes to move
> from plan-driven to value-driven development.
>
> We'd love to [get your feedback and
> input](https://gitlab.com/gitlab-org/gitlab/-/issues/221284) on where
> you'd like to see Iterations go next!
Issue Tracking[Organize sensitive work into Confidential Epics](https://docs.gitlab.com/ee/user/group/epics/manage_epics.html#make-an-epic-confidential):
> You can now organize a collection of related confidential issues into a
> confidential epic. For customers working in areas like finance, HR, or security, there is often
> a need to work on items that can't be public or openly viewable. To better support customers
> managing multiple confidential issues that all roll up to a shared goal or project, we have expanded our
> confidential functionality to epics!
Epics[Collapse milestones on the Roadmap](https://docs.gitlab.com/ee/user/group/roadmap/index.html):
> When sharing, reviewing, or presenting your Roadmap, you often need to minimize some sections or tailor
> the information displayed for the right audience. GitLab now allows you to minimize the Milestones
> section of the Roadmap to display more epics or hide unnecessary information.
Roadmaps[View the Epic feed by newest activity first](https://docs.gitlab.com/ee/user/group/epics/index.html#activity-sort-order):
> The default order of oldest-to-newest discussions and systems notes is
> incredibly helpful for some use cases, such as understanding the history
> of a given epic. However, it is much less helpful when teams are in
> triage and firefighting mode, as they have to scroll all of the way to the
> end of the epic to see the latest updates.
>
> Now you can reverse the default order and interact with the activity
> feed with the most recent items at the top. Your preferences for epics
> are saved separately in local storage and are automatically applied to
> every epic that you view.
Epics[Code Owner Sections](https://docs.gitlab.com/ee/user/project/codeowners/#code-owners-sections-premium):
> In large organizations, independent teams may have a common interest in parts of the application,
> for instance, a payment processing company may have development, security, and compliance teams
> looking after common parts of the codebase. All three teams may need to approve changes.
> While Code Owners are applied based on which files are changed, only one `CODEOWNERS`
> pattern can match per file path.
>
> In GitLab 13.2, Code Owner Sections allow each team to configure their own code owners
> independently. The section rules may be used for shared paths so that multiple teams can be added as reviewers,
> ensuring the right groups are reviewing relevant code will help with increased code quality, while
> getting feedback/reviews from the right reviewers will lead to increased efficiency.
Source Code Management[View Jira issue list in GitLab](https://docs.gitlab.com/ee/integration/jira/issues.html#view-jira-issues):
> For organizations using Jira as their primary work tracking tool,
> it can be a challenge for contributors to work across multiple systems
> and maintain a single source of truth.
>
> In this extension of our current Jira integration, project admins can now
> choose to display a list of Jira issues natively inside the GitLab
> project. This allows developers working primarily in GitLab to remain in
> flow, without having to reference a second tool for tracking what work
> needs to get done. Further planned enhancements include commenting, status
> changes (transitions), and more.
Integrations[Load Performance Testing](https://docs.gitlab.com/ee/user/project/merge_requests/load_performance_testing.html):
> It is important to know how the applications you're developing will perform under load. For example, do you know if your API can support 1,000 users concurrently? There wasn't an easy way to test how changes in a Merge Request would impact baseline performance before you merge.
>
> Now, you can make use of Load Performance Testing to run custom load tests. Out of the box Load Performance Testing will report what percentage of the configured Checks pass, the 90th and 95th percentile for Time to First Byte (TTFB) and the average requests per second (RPS). This makes it easy for you to compare the results against a common baseline and see the results directly in the Merge Request before deciding to merge your code.
Load Testing[Notification when system removes MR from merge train](https://docs.gitlab.com/ee/user/todos.html#what-triggers-a-to-do):
> If you add a merge request to a Merge Train, but the system removes it due to an issue, you now receive a notification in the form of a To-Do task. This means you can add an MR to a Merge Train with confidence, knowing that either a merge will happen automatically, or you will receive a notification of failure. If the merge is unsuccessful, you can quickly correct errors and resubmit your MR instead of being surprised later to learn it was never merged.
Continuous Integration (CI)[Manage PHP dependencies with the GitLab Composer Repository](https://docs.gitlab.com/ee/user/packages/composer_repository/):
> PHP developers need a mechanism to share and consume their projects' dependencies. Composer is a dependency manager for PHP that allows you to declare the libraries your project depends on and it will manage them for you.
>
> We are proud to offer a Composer Repository built directly into GitLab. PHP Developers now have an easier way to discover and manage their projects' dependencies. By integrating with Composer, GitLab provides a centralized location to view those packages in the same place as source code and pipelines. PHP dependencies in the Package Registry will be listed under the `All` tab and not under a Composer-specific tab. We will iterate to improve this by [adding a Composer-specific tab](https://gitlab.com/gitlab-org/gitlab/-/issues/222469) in an upcoming milestone.
>
> Special thanks to [@ochorocho](https://gitlab.com/ochorocho), who has been a significant contributor to this feature. We could not have done it without his help and guidance.
Package Registry[Auto-grouping identical alerts to reduce noise](https://docs.gitlab.com/ee/operations/incident_management/integrations.html#automatic-grouping-of-identical-alerts-premium):
> Teams maintaining IT services receive hundreds or thousands of alerts a day. GitLab now de-duplicates and organizes your incoming alerts, providing you counts of alerts while keeping your alert list manageable and useful. Your alerts are linked to the incidents created from the alerts, helping you track which alerts have been addressed and which alerts still need to be triaged.
Alert Management[Access Opsgenie from the GitLab user interface](https://docs.gitlab.com/ee/operations/incident_management/index.html#opsgenie-integration-premium):
> Opsgenie is a popular IT services management tool for operations tasks, including alerts and incident management. In GitLab 13.2, you can start your Opsgenie workflow directly from within GitLab. Want to give us feedback on this integration? Contribute on [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/230746) and tell us how we can make it better!
Alert Management[Bring Fargate support for ECS to Auto DevOps and ECS template](https://docs.gitlab.com/ee/ci/cloud_deployment/#deploy-your-application-to-the-aws-elastic-container-service-ecs):
> We want to make AWS deployments easier. In order to do so, we recently delivered a [CI/CD template](https://gitlab.com/gitlab-org/gitlab/-/blob/master/lib/gitlab/ci/templates/AWS/Deploy-ECS.gitlab-ci.yml) that deploys to AWS ECS:EC2 targets and even [connected it to Auto DevOps](https://docs.gitlab.com/ee/topics/autodevops/#aws-ecs). Scaling container instances in EC2 is a challenge, so many users choose to use AWS Fargate instead of EC2 instances. In this release we added Fargate support to the template, which continues to work with Auto DevOps as well, so more users can benefit from it.
Continuous Delivery[Multiple Kubernetes cluster deployment in Core](https://docs.gitlab.com/ee/user/project/clusters/#multiple-kubernetes-clusters):
> Using GitLab to deploy multiple Kubernetes clusters with GitLab previously required a Premium license. Our community spoke, and we listened: deploying to multiple clusters is useful even for individual contributors. Based on your feedback, starting in GitLab 13.2, you can deploy to multiple [group](https://docs.gitlab.com/ee/user/group/clusters/#multiple-kubernetes-clusters) and [project clusters](https://docs.gitlab.com/ee/user/project/clusters/#multiple-kubernetes-clusters) in Core.
Kubernetes Management[Create releases from .gitlab-ci.yml](https://docs.gitlab.com/ee/ci/yaml/#release):
> In 12.10, we introduced a way for you to automatically create release tags from the `.gitlab-ci.yml` file. Now we've made it easier and more natural to use by exposing the `release` keyword as a step the GitLab Runner can parse. You no longer need to add a script to call the Release API to create a release. Instead, you can simply add the correct parameters to your CI/CD file.
Release OrchestrationBug fixes
> Some of the notable bug fixes in 13.2 are:
>
> - [Fix pre-receive hooks not working with symlinked paths](https://gitlab.com/gitlab-org/gitlab/-/issues/223839)
> - [Fix 500 error after pushing a file starting with :](https://gitlab.com/gitlab-org/gitaly/-/issues/2857)
> - [Fix 500 error when uploading Conan package](https://gitlab.com/gitlab-org/gitlab/-/issues/225860)
> - [Fix 404 errors in repository archive when project contains a period](https://gitlab.com/gitlab-org/gitlab/-/issues/224669)
> - [Fix incorrect display of audit event IP addresses](https://gitlab.com/gitlab-org/gitlab/-/issues/224539)
> - [User/Group sites with mixed case path have incorrect Pages URL](https://gitlab.com/gitlab-org/gitlab/-/issues/224470)
> - [Remove button from environments empty state](https://gitlab.com/gitlab-org/gitlab/-/issues/24324)
> - [Update Git TLS settings to be configured for repo URL, not GitLab URL](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3551)
> - [Fix support for UNC paths in PowerShell executor](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3761)
> - [Search box does not show projects or groups any more](https://gitlab.com/gitlab-org/gitlab/-/issues/223841)
> - [Advanced Search can't search lowerCamelCased tokens after some special characters](https://gitlab.com/gitlab-org/gitlab/-/issues/223044)
> - [Advanced Search can't search around equal sign without space](https://gitlab.com/gitlab-org/gitlab/-/issues/223045)
> - [Advanced Search rake task `gitlab:elastic:index` won't work as designed](https://gitlab.com/gitlab-org/gitlab/-/issues/216275)
> - [Code coverage graph dates ordered newest to oldest](https://gitlab.com/gitlab-org/gitlab/-/issues/222939)
> - [Show error message when adding an issue to epic fails](https://gitlab.com/gitlab-org/gitlab/-/issues/219244)
> - [Display warning when service desk issue gets moved to a project without service desk enabled](https://gitlab.com/gitlab-org/gitlab/-/issues/207497)
> - [Existing child epics cannot be removed from parent after subscription downgrade](https://gitlab.com/gitlab-org/gitlab/-/issues/220221)
> - [Race condition that makes it possible to create duplicated labels](https://gitlab.com/gitlab-org/gitlab/-/issues/30390)
> - [Process stuck Jira import jobs and fail them with an appropriate timeout message](https://gitlab.com/gitlab-org/gitlab/-/issues/217395)
> - [Import from Jira Server not working](https://gitlab.com/gitlab-org/gitlab/-/issues/220232)
> - [Misleading message displays when merge request is first submitted](https://gitlab.com/gitlab-org/gitlab/-/issues/216048)
> - [Change "Could not retrieve pipeline status" error state when the pipeline was just created](https://gitlab.com/gitlab-org/gitlab/-/issues/225913)
> - [Updating an environment variable's scope by using API fails](https://gitlab.com/gitlab-org/gitlab/-/issues/9912)
> - [Auditor users cannot access public and internal projects when files access is limited to project members](https://gitlab.com/gitlab-org/gitlab/-/issues/14731)
> - [Race condition that makes it possible to create duplicate labels.](https://gitlab.com/gitlab-org/gitlab/-/issues/30390#note_370815789)
[GitLab chart improvements](https://docs.gitlab.com/charts) (self-managed only):
> - The culmination of work spread across several releases results in greater than 5x reduction in time to initialize Rails based pods, and a 25% reduction in application process startup. This results in significantly faster scaling of the Webservice and Sidekiq deployments. For more details on the implemented solutions, see multiple associated issues: [gitlab-org/charts/gitlab#1775](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/1775), [gitlab-org/charts/gitlab#1361](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/1361), [gitlab-org/charts/gitlab#1779](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/1779), [gitlab-org/build/CNG!433](https://gitlab.com/gitlab-org/build/CNG/-/merge_requests/433), [gitlab-org/charts/gitlab#2165](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/2165).
> - Kubernetes 1.13 is now the minimum supported version. Support for Kubernetes 1.12 was dropped in this release. For more details, see [the removal notice](#kubernetes-1.12-no-longer-supported).
Cloud Native Installation[Read-only access to Terraform State API](https://docs.gitlab.com/ee/user/infrastructure/index.html#permissions-for-using-terraform):
> GitLab users without Maintainer access currently cannot interact with Terraform commands, including `terraform plan`, which creates an execution plan useful in development workflows. In GitLab 13.2, users with the Developer role gain read-only access to the Terraform state API, enabling more users to contribute without risking improper usage.
Infrastructure as Code[Multiple Terraform plan support in Merge Requests](https://docs.gitlab.com/ee/user/infrastructure/#output-terraform-plan-information-into-a-merge-request):
> During a single Terraform pipeline, several infrastructure environments might be affected. Previously, GitLab enabled a quick overview of the expected changes in a Merge Request only for a single environment. Starting in GitLab 13.2, the Terraform Merge Request widget supports multiple Terraform artifact files.
>
> We're actively looking for feedback about our Terraform features. If you have ideas for improving the Merge Request widget, please share it with us [in the Merge Request widget epic](https://gitlab.com/groups/gitlab-org/-/epics/3441).
Infrastructure as Code[Omnibus improvements](https://docs.gitlab.com/omnibus) (self-managed only):
> - The minimum size for compressing NGINX responses has been lowered from 10,240 bytes to 250 bytes. This reduces the number of requests that need more than one packet, and decreases the time it takes to load web pages. For details, see the [Merge Request](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/4387).
> - The settings to configure object storage have been consolidated so that object storage for all objects can be configured in the same section in `gitlab.rb`. This is a great improvement that makes object storage configuration much more efficient, including the ability to use a single credential for object storage in multiple S3 buckets. It also enables GitLab Workhorse to upload files directly with its own S3 client, eliminating the need for a pre-signed URL. For more details, refer to [the Object Storage documentation](https://docs.gitlab.com/ee/administration/object_storage/#consolidated-object-storage-configuration).
> - An Omnibus install package is [now available](https://about.gitlab.com/install/#ubuntu) for Ubuntu 20.04.
> - An Omnibus install package is [now available](https://about.gitlab.com/install/#opensuse-leap-15-1) for SLES 12.5.
> - The version of Chef that is packaged in GitLab has been updated to Chef 15.
> - GitLab 13.2 includes [Mattermost 5.24](https://mattermost.com/blog/mattermost-release-v5-24/), an [open source Slack-alternative](https://mattermost.com/). This release includes an improved end-user search, an improved session experience, and much more. It also includes [security updates](https://mattermost.com/security-updates/) and upgrade from earlier versions is recommended. When upgrading to Mattermost 5.24, see [the important upgrade notes about enabling the new `ExtendSessionLengthWithActivity` setting](https://docs.mattermost.com/administration/important-upgrade-notes.html). If you have a Mattermost environment that contains a lot of emoji reactions, please also refer to the upgrade note about longer upgrade times.
Omnibus Package[Patroni available as experimental alternative to repmgr](https://docs.gitlab.com/ee/administration/postgresql/replication_and_failover.html#patroni) (self-managed only):
> For self-managed GitLab installations, Patroni is now available as an alternative PostgreSQL replication and failover solution. Patroni brings improvements over repmgr, which it replaces. With Patroni, a failed primary is automatically added back to the cluster as a standby node when it comes back online. The addition of Patroni also unblocks us from adding support for PostgreSQL 12, and supporting PostgreSQL replication and failover on a Geo secondary site. Use of Patroni with Geo is currently being tested and is not yet supported. This switch supports GitLab's goals to dogfood our solutions. Gitlab.com has been using Patroni to [manage failover since 2018](https://about.gitlab.com/blog/2018/12/05/availability-postgres-patroni/), making it a well tested solution. Repmgr will continue to be available in Omnibus GitLab until GitLab 14.0. For instructions on setting up Patroni, which is currently experimental, see GitLab's [Patroni documentation](https://docs.gitlab.com/ee/administration/postgresql/replication_and_failover.html#patroni).
Omnibus PackagePerformance Improvements
> In every release, we continue to make great strides improving GitLab's performance. We're committed to making every GitLab instance faster. This includes GitLab.com, an instance with over 1 million registered users!
>
> In GitLab 13.2, we're shipping performance improvements for issues, projects, milestones, and much more! Some performance improvements in GitLab 13.2 are:
>
> - [Search API: commits scope](https://gitlab.com/gitlab-org/gitlab/-/issues/215708)
> - [Group Search API: merge_requests scope](https://gitlab.com/gitlab-org/gitlab/-/issues/221211)
> - [Speed up display of job logs](https://gitlab.com/gitlab-org/gitlab/-/issues/224919)
> - [File path regex for Advanced Search indexing](https://gitlab.com/gitlab-org/gitlab/-/issues/224459)
> - [Diff tree list](https://gitlab.com/gitlab-org/gitlab/-/issues/223086)
> - [Diff line comment button](https://gitlab.com/gitlab-org/gitlab/-/issues/223077)
> - [Display one file at a time when reviewing code](https://gitlab.com/gitlab-org/gitlab/-/issues/222790)
> - [Max page size limit when querying sub-epics in GraphQL](https://gitlab.com/gitlab-org/gitlab/-/issues/9647)
> - [Enable BulkInsertSafe on Ci::BuildNeed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/36815)
[Annotate non-deployment jobs in .gitlab-ci.yml](https://docs.gitlab.com/ee/ci/environments/#prepare-an-environment):
> Historically, the `environment:action` keyword did not accurately represent environment jobs that didn't result in a deployment, such as in-approval jobs and building images for future deployments. In GitLab 13.2, jobs now contain a `prepare` keyword to make the state of non-deployment environment jobs clearer, keeping them accurate and representative of your deployment activities.
Release Orchestration[REST API support for reordering issues](https://docs.gitlab.com/ee/api/issues.html#reorder-an-issue):
> You can now change the relative order of an issue via the REST API. Prior to this release, there was no way to programmatically reorder issues. This has been particularly problematic for API consumers trying to support custom Board interfaces, as it was not possible to change the relative position of issues.
>
> Thank you [@jjshoe](https://gitlab.com/jjshoe) for adding an endpoint in our public API to support this!
Boards[Map Jira users to GitLab users when importing issues](https://docs.gitlab.com/ee/user/project/import/jira.html#import-your-jira-project-issues-to-gitlab):
> When importing issues from Jira to GitLab, you can now map Jira users to GitLab project members prior to running the import. This enables the importer to set the correct reporter and assignee on the issues you're moving to GitLab.
Issue Tracking, Jira Importer[Service Desk moved to Core](https://docs.gitlab.com/ee/user/project/service_desk.html#service-desk):
> In the 9.1 release, we added [Service Desk](https://about.gitlab.com/releases/2017/04/22/gitlab-9-1-released/#service-desk-eep) to our Premium tier, allowing teams to connect directly with external users through email.
>
> Listening to our customers, we learned that Service Desk is a useful feature for teams of any size. In GitLab 13.2 you can now enable Service Desk regardless of your GitLab tier.
Service Desk[Batch Suggestions](https://docs.gitlab.com/ee/user/discussions/#batch-suggestions):
> [Suggesting changes](https://docs.gitlab.com/ee/user/discussions/#suggest-changes)
> in merge requests makes proposing improvements easy, but if you receive
> many suggestions, applying them one by one is slow.
>
> With Batch Suggestions, you can apply multiple suggestions at once, which is faster and
> easier! It's also beneficial to keep the commit history in a merge request clean and tidy.
> Thanks [Jesse Hall](https://gitlab.com/jessehall3) for your
> [contribution](https://gitlab.com/gitlab-org/gitlab/merge_requests/22439)!
Code Review[Redirect wikis to Confluence Workspace](https://docs.gitlab.com/ee/api/services.html#confluence-service):
> If you’re collaborating as a team with Confluence, it can be hard to keep track of both your Confluence Workspace and the GitLab Projects that you use it on. In 13.2, we’ve added a Confluence integration that links your project's left sidebar directly to a Confluence Workspace in a new tab.
Wiki[Keep track of your activity in Designs](https://docs.gitlab.com/ee/user/project/issues/design_management.html#design-activity-records):
> It’s important you get credit for the work you do on designs in GitLab! We’ve added activity for uploading, revising, and commenting on Designs to your user profile, group page, and project page! Keep track of your design operations at a glance.
Wiki[Make it easier to find Designs on an issue](https://docs.gitlab.com/ee/user/project/issues/design_management.html#the-design-management-section):
> Since designing is such a massive part of the product development process, it’s important that the designs you have created and added to issues are easy to find. Before 13.2, we had the **Design** tab, but we’ve moved designs up, so they are now right under the issue description.
>
> This will encourage more collaboration and ensure that everyone sees the designs right beneath the issue description.
Design Management[Wiki page diffs](https://docs.gitlab.com/ee/user/project/wiki/#viewing-the-changes-between-page-versions):
> Often Git users heavily rely on file diffs to observe, review, and track changes to content.
> In GitLab 13.2, we've added support for viewing diffs on Wiki pages. You can seamlessly see
> line-by-line content changes between two versions through the wiki commit history.
>
> Thanks to [Steve Mokris](https://gitlab.com/smokris) and [Greg](https://gitlab.com/gwhyte) for the contribution!
Wiki[Optional Merge Request Approvals in GitLab Core](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html):
> Code review is an essential practice of every successful project, and giving your
> approval once a merge request is in good shape is an important part of the review
> process, as it clearly communicates the ability to merge the change. For Core users,
> this is usually done by leaving a comment, or giving a thumbs up, but these forms of
> approval are easily lost.
>
> In 13.2, anyone with Developer permissions to a project can approve a merge request in
> GitLab Core. This makes it obvious to reviewers how to give their approval, and makes
> it easy for maintainers to know when a change is ready to merge. Approvals are
> optional in GitLab Core and GitLab.com Free, but users of GitLab Starter and
> GitLab.com Silver and higher tiers can also
> [require approvals](https://docs.gitlab.com/ee/user/project/merge_requests/approvals/rules.html)
> to get code merged into the codebase.
Code Review[Configurable default branch name for new repositories](https://docs.gitlab.com/ee/user/project/repository/branches/default.html) (self-managed only):
> When creating a new Git repository, by default the first branch created
> is named `master`.
> In coordination with the Git project, broader community, and other Git vendors,
> GitLab has been listening to the development community’s feedback on determining
> a more descriptive and inclusive name for the default branch, and offering users
> options to change the name of the default branch name for their repositories.
>
> GitLab now allows instance administrators to configure the default branch name
> for new repositories created through the GitLab interface.
Source Code Management[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[Real-time feedback for .gitlab-ci.yml in Web IDE](https://docs.gitlab.com/ee/user/project/web_ide/index.html#syntax-highlighting):
> GitLab CI is fast and highly configurable, but it can be hard to remember all the [configuration parameters](https://docs.gitlab.com/ee/ci/yaml/), and the wrong typo can make your `.gitlab-ci.yml` file invalid. To make it easier to configure your GitLab CI pipeline, the Web IDE now provides real-time linting and completion when editing `.gitlab-ci.yml` files.
>
> Linting and completion feedback is provided inline in the Web IDE with tooltips to help understand why you're seeing an error. Currently, this feedback is based on a community-contributed [schema](http://json.schemastore.org/gitlab-ci) from [Schemastore](https://www.schemastore.org/json/), but we are continuing to evaluate a [built-in](https://gitlab.com/gitlab-org/gitlab/-/issues/218473) schema as part of GitLab.
Web IDE[Gitaly Cluster TLS support](https://docs.gitlab.com/ee/administration/gitaly/praefect.html#enabling-tls-support) (self-managed only):
> Gitaly Cluster now supports [Transport Layer Security (TLS)](https://en.wikipedia.org/wiki/Transport_Layer_Security), which means all communication between Gitaly and its clients, GitLab and Praefect, are encrypted when TLS is enabled for both Gitaly and Praefect components. This is helpful when deploying GitLab to a network with other internal services that are not trusted.
>
> Previously, communication between GitLab and Gitaly supported TLS encryption, but encryption was not supported when using Praefect, which is a component of Gitaly Cluster.
Gitaly[GitLab Runner support for Linux on IBM Z](https://docs.gitlab.com/runner/install/docker.html#docker-images):
> GitLab customers and contributors that use IBM mainframes are adopting modern DevOps practices and want to be able to run GitLab Runners directly on their hardware. Based on this growing interest to expand platform support for z/OS mainframes, we've included the first version of a GitLab Runner binary Docker and helper image that you can use to run and execute Continuous Integration jobs natively on the s390x architecture under a [Linux on IBM Z](https://www.ibm.com/it-infrastructure/z/os/linux) environment.
GitLab Runner[Dynamically generate Child Pipeline configurations with Jsonnet](https://gitlab.com/gitlab-org/project-templates/jsonnet/#jsonnet-project-template):
> We released [Dynamic Child Pipelines](https://docs.gitlab.com/ee/ci/parent_child_pipelines.html#dynamic-child-pipelines) back in
> GitLab 12.9, which allow you to generate an entire `.gitlab-ci.yml` file at runtime. This is a great solution for monorepos, for
> example, when you want runtime behavior to be even more dynamic.
> We've now made it even easier to create CI/CD YAML at runtime by including a project template that demonstrates how to use Jsonnet to generate
> the YAML. Jsonnet is a data templating language that provides functions, variables, loops, and conditionals that allow for fully
> parameterized YAML configuration.
Continuous Integration (CI)[Code Quality Merge Request widget moved to Core](https://docs.gitlab.com/ee/user/project/merge_requests/code_quality.html#code-quality-widget):
> In the 9.3 release, GitLab added [Code Quality scanning](https://about.gitlab.com/releases/2017/06/22/gitlab-9-3-released/#gitlab-code-quality) to our Starter/Bronze tier, allowing you to see code quality changes directly in your merge requests. Since then, our users have provided feedback that this data is valuable to teams of any size, including individual contributors. In 13.2, you will be able to see Code Quality reports in your Merge Requests regardless of your GitLab tier.
Code Quality[Custom text for coverage badges](https://docs.gitlab.com/ee/ci/pipelines/settings.html#custom-badge-text):
> Projects that use multiple coverage badges, but are calculating different values for each, could only use `coverage` as the text for every badge. This made it cumbersome to figure out what that value means.
>
> Now, as a project maintainer or owner, you can customize the text for coverage badges to better differentiate between multiple coverage badges displaying on your project.
>
> Thank you to [Fabian Schneider](https://gitlab.com/fabsrc) for the contribution!
Code Testing and Coverage[GitLab Runner 13.2](https://docs.gitlab.com/runner):
> We're also releasing GitLab Runner 13.2 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:
>
> - [Enable PowerShell Core support in Shell Executor](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/13134)
> - [Add labels to Docker networks](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/10120)
>
> #### Bug Fixes:
>
> - Fix: [Kubernetes runner timeout when the image name is invalid.](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/26305)
> - Fix: [Support for UNC paths in PowerShell executor.](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3761)
> - Fix: [CI URL used instead of clone URL when setting git TLS configuration.](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3551)
>
> The list of all changes is in the GitLab Runner [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/13-2-stable/CHANGELOG.md).
GitLab Runner[Exclude files in CI artifact paths](https://docs.gitlab.com/ee/ci/yaml/#artifactsexclude):
> With the new `exclude` syntax, you can prevent specific files from being added to artifacts. This eliminates the need to explicitly reference the path of every folder that should be added to the artifact (to avoid including too much). Support for wildcards (globs and double star globs) makes it easy to exclude entire subdirectories.
Continuous Integration (CI)[Visual correlation of trigger job to downstream pipeline](https://docs.gitlab.com/ee/ci/yaml/#trigger):
> If you've looked at a complex pipeline graph wishing there was an easy way to know which job triggered a specific downstream pipeline, then wish no more. Now you can simply hover over a downstream pipeline to see a tooltip that names the job which triggered the pipeline. And there's no need to skim all the job names to find "the one" because the hover action also highlights the trigger job in the upstream pipeline.
Continuous Integration (CI)[View and manage group Runners](https://docs.gitlab.com/ee/ci/runners/runners_scope.html#view-and-manage-group-runners):
> You can now take advantage of 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[Validation for tag Cleanup policy regex](https://docs.gitlab.com/ee/user/packages/container_registry/#troubleshooting-cleanup-policies):
> You can regularly remove older tags from the Container Registry by creating a per-project tag cleanup policy. These policies are based on user-created regular expressions. Unfortunately the `container_repository:cleanup_container_repository` job that runs against these expressions has been experiencing error rates of 25%. The `Gitlab::UntrustedRegexp` job considers the regex to be invalid, and when a policy fails to run, no one is notified.
>
> We have taken the first step in resolving this issue. GitLab now validates the regex with the [re2](https://github.com/google/re2/wiki/Syntax) library, so you can't save an invalid pattern. We also added [some common regex patterns to the documentation](https://docs.gitlab.com/ee/user/packages/container_registry/#regex-pattern-examples). You can find more details and our plan for adding future enhancements to this feature based on our roadmap in the [epic](https://gitlab.com/groups/gitlab-org/-/epics/2270).
Container Registry[JavaScript & TypeScript 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 to mitigate proactively. As part of our [community stewardship commitment](/company/stewardship/#promises) we are making our JavaScript & TypeScript [SAST analyzer](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) (ESLint) available in every [GitLab tier](/pricing/). This will allow **ALL** GitLab users developing in JavaScript or TypeScript to leverage [SAST security Scans](https://docs.gitlab.com/ee/user/application_security/sast/) for their projects.
> As part of this move, we have deprecated our existing TSLint Analyzer, as its functionality is now present in ESLint. You can learn more about this in our [deprecation notice](#deprecation-and-planned-removal-of-tslint-secure-analyzers).
> 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 even contribute to this effort.
SAST[Container Host Monitoring and Blocking](https://docs.gitlab.com/ee/user/clusters/applications.html#install-falco-using-gitlab-cicd):
> We're pleased to announce the first release of [Container Host Security](https://about.gitlab.com/direction/govern/).
> This initial feature, container host monitoring and blocking, allows security administrators
> to secure their running containers at the host level by monitoring and optionally
> blocking unexpected activity. Such activity includes process starts, file changes,
> or opened network ports. This feature uses [Falco](https://falco.org/) to provide the monitoring functionality
> and [AppArmor](https://www.kernel.org/doc/html/v4.15/admin-guide/LSM/apparmor.html) and
> [Pod Security Policies](https://kubernetes.io/docs/concepts/policy/pod-security-policy/) for the blocking functionality.
Container Host Security[Cluster health monitoring now available in Core](https://docs.gitlab.com/ee/user/project/clusters/#visualizing-cluster-health):
> To understand system performance, your development team must monitor the health and performance of the underlying infrastructure. We want our metrics solution to be available to all GitLab users, so as part of our [2020 gift](https://about.gitlab.com/blog/2019/12/16/observability/), we've moved cluster health in the Monitor stage from GitLab Ultimate to GitLab Core. Beginning with GitLab 13.2, all users can connect a cluster and monitor its health in the GitLab user interface.
Metrics[Managed application logs available in GitLab UI](https://docs.gitlab.com/ee/user/clusters/applications.html#browse-applications-logs):
> When triaging an incident or validating the status of your service, you must be able to explore Kubernetes pod logs from across your entire application stack. Previously, the GitLab user interface displayed only the deployed application logs (logs that originate from the application you deployed to a cluster using CI/CD). In GitLab 13.2, you can now also search across your [managed application](https://docs.gitlab.com/ee/user/clusters/applications.html) logs directly from the GitLab user interface.
Metrics[OAuth for manually configured Prometheus servers](https://docs.gitlab.com/ee/user/project/integrations/prometheus.html#configuration-in-gitlab):
> To use a manually configured (external) Prometheus server, it can be problematic to authenticate users from GitLab. In Gitlab 13.2, you can now use OAuth so that authentication is secure and easy to administer.
Metrics[Alert detail pages display system notes](https://docs.gitlab.com/ee/operations/incident_management/index.html#alert-system-notes):
> When you change the status of an alert, assign it to a team member, or create an issue from the alert, GitLab tracks these events and displays them as notes on alert detail pages. Notes provide helpful context to responders, enabling your team to better collaborate when triaging alerts, and preventing unnecessary duplication of work.
Alert Management[Keyboard shortcuts for panels in metrics dashboard](https://docs.gitlab.com/ee/operations/metrics/#keyboard-shortcuts-for-charts):
> You can now use keyboard shortcuts to interact with your metrics dashboards in GitLab 13.2. With keyboard shortcuts, you can quickly navigate through a dashboard while triaging an incident, speeding up the response workflow.
Metrics[Search for plain text in the Alerts list](https://docs.gitlab.com/ee/operations/incident_management/index.html#searching-alerts):
> Alerts are often noisy and plentiful. To help you find relevant alerts you need to triage, and refine the list of displayed alerts, you can now conduct plain-text searches in the Alerts list.
Alert Management[Trigger tests for your alert integrations](https://docs.gitlab.com/ee/operations/incident_management/integrations.html#triggering-test-alerts):
> After you configure your alerting systems to route alerts to your GitLab REST endpoint, you can now trigger test alerts to ensure you've configured your systems properly, giving you extra peace of mind.
Alert Management[Vanity URL for Metrics Dashboards](https://docs.gitlab.com/ee/operations/metrics/dashboards/#navigating-to-a-custom-dashboard):
> GitLab 13.2 introduces vanity metrics dashboard URLs to help you to quickly navigate between different dashboards and projects.
Metrics[Set metrics dashboard variables with PromQL](https://docs.gitlab.com/ee/operations/metrics/dashboards/templating_variables.html):
> You can now set variables in your metrics dashboard using PromQL. Your PromQL queries can return a list of values to use as dynamic variables in a [metrics dashboard](https://about.gitlab.com/releases/2020/05/22/gitlab-13-0-released/#use-variables-to-power-metric-dashboards).
Metrics