GitLab 13.0 Release

Added admin impersonation audit events

Added admin impersonation audit events

Auditability and traceability are critical components of an organization’s compliance program. Previously, actions taken by an administrator, who impersonated another user, would be captured in the audit events table as if the impersonated user was taking those actions. Now, audit events will show you when specific actions were the result of an administrator’s impersonation activity.

This important addition to audit events corrects a gap in nonrepudiation for your compliance program and adds to the reliability and comprehensiveness of your GitLab audit events data.

Enable group-level default branch protection

Enable group-level default branch protection

Previously, the translation of instance-level default branch protection settings down into projects was confusing because, in certain scenarios, it created an unintuitive experience: developers could not push new commits to projects they could create. This made it difficult for organizations to strike a balance between mitigating risk and allowing carte blanche access to projects for all developers since the workaround required promoting them to Maintainer.

Now, default branch protection can be set at the group level to provide better flexibility for administrators and group owners. Using a combination of default branch protection and default project creation settings, organizations can find the right mix of autonomy and control, such as using custom default branch protection and allowing only maintainers to create new projects. This would allow developers to push new commits (not force push or delete a branch) to new projects, but allow maintainers to control project creation.

This group-level configuration of default branch protection can be disabled for organizations requiring more strict controls in place. By disabling the group-level setting for default branch protection, maintainers can apply more stringent controls on developer access and permissions.

Filtered search for instance-level audit events

Filtered search for instance-level audit events

When you need to find a specific event, either for audit reporting or to investigate incidents, it should be easy. It shouldn’t require a lot of time to manually dig through a large data set.

Now, you can perform filtered searches on a single object, e.g., a user, group, or project in the instance-level audit events table to make this process much easier. This feature is available for self-managed customers only, but will be extended to groups and projects as part of a the larger epic to make the instance, group, and project-level audit events experiences uniform and much friendlier to use.

Okta SCIM Integration Application for GitLab.com

Okta SCIM Integration Application for GitLab.com

We now offer an Okta SCIM integration application for Gitlab.com groups! When Okta SCIM is provisioned for a GitLab group, membership of that group is synchronized between GitLab and Okta. This reduces group administrator time spent to onboard and offboard users.

Value Stream Analytics

Tasks by Type

Value Stream Analytics

Tasks by Type

This powerful new chart allows teams to see how delivery is distributed across different types of work. Use labels to see how many features are delivered vs. bugs from release to release, or how many items a given team ships vs. another. By reflecting on the distribution of work delivered through the value stream, teams can tune their processes to better align with strategic objectives or better balance resources across teams.

Assign an issue to a different Epic via drag and drop in the Epic Tree

Assign an issue to a different Epic via drag and drop in the Epic Tree

Often when organizing or curating an epic, you need to move an existing issue to another epic in the tree. You can now move an issue to a different epic via drag and drop, instead of having to click through multiple tabs.

View Milestones on the Roadmap

View Milestones on the Roadmap

Accurately tracking the status of work in flight is a must to help keep teams on track. Now, when viewing your roadmap, you can view how your epics line up with your various milestones helping you better understand when work will land, and identify if projects are ahead or behind expectations.

Commit navigation buttons in merge requests

Commit navigation buttons in merge requests

Easily navigating commits in large merge requests allows reviewers to be more efficient while reviewing on a commit-per-commit basis.

The new commit navigation buttons allows users to seamlessly navigate between the current commit to the previous or next commit, making it more efficient to review merge request with a large number of changes.

Improved Snippets editor

Improved Snippets editor

With the release of Versioned Snippets in GitLab 13.0, we’ve upgraded the Snippets editor to a lighter-weight version of the editor found in our Web IDE. With this editor, users will benefit from basic code completion and linting for some languages. We’ve also improved source code language detection for better syntax highlighting, and added support for all our syntax highlighting themes. These improvements will make it easier to edit and collaborate on Snippets.

We’re excited to bring consistency to the editors in Snippets and the Web IDE. In a future release we’ll expand this functionality to our single file editor and in our .gitlab-ci.yml editing experiences.

Support parent/ancestor groups and users in CODEOWNERS file

Support parent/ancestor groups and users in CODEOWNERS file

Groups can be used for organizing users in GitLab. This makes it easy to share projects, mention in comments, or assign as merge request approvers without selecting them one at a time.

Groups and users can be assigned as code owners, but ancestor groups could not be used. This meant assigning a parent group from the project hierarchy as a code owner had no effect.

GitLab 13.0 introduces the ability to include users and groups from a parent or ancestor group in a project’s CODEOWNERS file, providing more flexibility when specifying Code Owners’ rules.

Use emojis in design comments to enhance feedback 👍

Use emojis in design comments to enhance feedback 👍

In 13.0, Design discussions are one step closer to the commenting experience in GitLab. We’ve added emoji support so you can convey your feedback in a more fun and imaginative way! 😼

WYSIWYG for the Static Site Editor

WYSIWYG for the Static Site Editor

Markdown is a powerful and efficient syntax for authoring web content, but even seasoned authors of Markdown content can struggle to remember some of the less-frequently used formatting options or write even moderately-complex tables from scratch. There are some jobs better accomplished with a rich text, “What You See Is What You Get” (WYSIWYG) editor.

GitLab 13.0 brings a WYSIWYG Markdown authoring experience to the Static Site Editor with formatting options for common formatting options like headers, bold, italics, links, lists, blockquotes, and code blocks. The WYSIWYG editor also removes the onerous task of editing tables in Markdown by letting you visually edit table rows, columns and cells in the same way you would edit a spreadsheet. For those more comfortable writing in raw Markdown, there’s even a tab for switching between WYSIWYG and plain text editing modes.

Filter pipelines by trigger author and branch name

Filter pipelines by trigger author and branch name

Searching for pipelines triggered by a specific user or that ran on a particular branch is now easier than ever before. With a new filter feature on the pipelines page, it is now possible to filter by trigger author and/or by branch name. Being able to refine the pipelines view by applying these filters will help to stay informed of pipeline activities that matter most to you.

Inherit environment variables from other jobs

Inherit environment variables from other jobs

Passing environment variables (or other data) between CI jobs is now possible. By using the dependencies keyword (or needs keyword for DAG pipelines), a job can inherit variables from other jobs if they are sourced with dotenv report artifacts. This offers a more graceful approach for updating variables between jobs compared to artifacts or passing files.

Runner now supports downloading artifacts directly from Object Storage

Runner now supports downloading artifacts directly from Object Storage

GitLab Runner 13.0 now supports downloading artifacts directly from object storage. When this option is enabled the GitLab server will redirect the Runner directly to object storage, rather than proxying the traffic. This can result in significant cost savings on network transfer costs, as well as reduced load on the GitLab server.

To enable set the FF_USE_DIRECT_DOWNLOAD feature flag to true via an environment variable.

Package versions are now nested under their parents

Package versions are now nested under their parents

The GitLab Package Registry has been treating each new version of a package as a new package. This has made it difficult to find the package you are looking for or to understand what has changed from version to version.

In GitLab 13.0, we are excited to announce that each version of a package will now be nested under its uniquely-named parent. This will make it easier to find the package you are looking for in the UI and to better understand what has changed from version to version. This change applies to both the group and project-level views of the Package Registry. In addition, when using the Packages API, versions will now be returned as an array within the parent package.

Use search to quickly find and discover images hosted in the GitLab Container Registry

Use search to quickly find and discover images hosted in the GitLab Container Registry

When you or someone on your team publishes an image to the GitLab Container Registry, you need a way to quickly find it and ensure the image was built properly. If you’re using GitLab CI/CD to publish images with each build, it’s been very difficult to find an image efficiently within the current user interface. Instead, you’ve relied on the command line or the API.

We are excited to announce that in 13.0, we’ve added search functionality to the GitLab Container Registry. Simply navigate to your project or group’s registry and enter an image name to see a list of all your images.

View more robust data in the list view Package Registry user interface

View more robust data in the list view Package Registry user interface

Before this release, the Package Registry list view showed a limited amount of information related to the packages in the UI. While this information is important, it lacked key metadata such as version, branch, and commit.

In 13.0, we’ve updated the design of this page to include additional metadata to help you find the package you are looking for and verify it was built properly. In addition to the package name, you can now see version, type, and more. Check out the video for an example or start using the feature today.

Implement a deployment freeze with the Freeze Period API

Implement a deployment freeze with the Freeze Period API

In this milestone, GitLab introduces more controls for environments. With the Freeze Period API, you can easily prevent an unintended production release during a period of time specified by you, whether it is a large company event or holiday. You can now rely on the enforcement of policies that are typically outside the scope of GitLab to reduce uncertainty and risk while automating deployments.

Use Cloud Native Buildpacks for Auto DevOps (beta)

Use Cloud Native Buildpacks for Auto DevOps (beta)

Cloud Native Buildpacks are the next iteration of buildpacks. While GitLab currently defaults to Herokuish buildpacks, we intend to move Auto DevOps to Cloud Native Buildpacks when the project matures, to provide a future-proof and well-maintained solution to our users. With this release, you can opt in to use the beta for Cloud Native Buildpacks in Auto DevOps pipelines by setting the AUTO_DEVOPS_BUILD_IMAGE_CNB_ENABLED CI variable.

Add frequently used dashboards to favorites

Add frequently used dashboards to favorites

In GitLab 13.0, you can now add your frequently-used dashboards to your favorites by clicking the Star button. Starring a dashboard displays it first in the dashboard search bar results to save you time.

Display charts in full screen mode

Display charts in full screen mode

In GitLab 13.0, you can now display metrics charts in full screen mode, helping you see chart information in more detail when triaging incidents.

Status pages anonymized

Status pages anonymized

When an incident response team shares incident updates and status changes, the incident description is published publicly, but all user and group names in issue descriptions are anonymized to protect the privacy of individuals and teams.

View payload and annotations of external IT alerts in GitLab

View payload and annotations of external IT alerts in GitLab

The alert list view is helpful for triaging problems at a high-level, but it does not provide enough space for all alert attributes and the payload. The new alert detail page is dedicated to displaying and organizing the alert payload and annotations so that responders can quickly find critical information during an investigation.

Geo secondaries automatically forward SSH requests for unsynchronized repositories

Geo secondaries automatically forward SSH requests for unsynchronized repositories

Geo supports selective synchronization of projects, which allows systems administrators to choose a subset of data that is replicated to a secondary Geo node. Geo already supports redirecting HTTP(S) requests to the primary when trying to access these unsynchronized repositories. However, users trying to access unsynchronized repositories on a secondary node via SSH would receive an error that the repository was not available. This was confusing for users and forced them to either wait for the repository to synchronize or do extra work to connect to the right repository.

In GitLab 13.0, any Git requests made via SSH to an unsynchronized secondary Geo node will be forwarded to the primary node. This results in a much more seamless user experience because users won’t need to know what is or isn’t replicated to this node - Geo will fulfill the request both via HTTP(S) and SSH without any additional configuration.

Improved Geo replication performance for Job Artifacts, Uploads and LFS files

Improved Geo replication performance for Job Artifacts, Uploads and LFS files

To determine what needs to be replicated from the primary, Geo compares the tracking database to the read-only secondary database. If Geo’s database queries time out, data can’t be replicated successfully. In GitLab 13.0, we use a new approach to synchronize Job Artifacts and Uploads, thereby eliminating the possibility of database statement timeouts. We also improved the database query performance to retrieve Job Artifacts, LFS Objects, and Uploads when these files are stored locally, which increases the overall scalability and performance of GitLab Geo.

These iterations bring us closer to removing Geo’s dependency on Foreign Data Wrappers, which were added for improved performance, but makes Geo more complex and harder to maintain.

PostgreSQL 11 is now the minimum required version to install GitLab

PostgreSQL 11 is now the minimum required version to install GitLab

The minimal required version of PostgreSQL for all self-managed installations is now PostgreSQL 11. PostgreSQL versions 9.6 and 10 have been removed in GitLab 13.0. This update allows us to start introducing performance improvements based on the partitioning features that were added in PostgreSQL 11. We plan to support PostgreSQL 11 for the entire duration of the GitLab 13.x series of releases. Support for PostgreSQL 12 will be added in the near future. See Important notes on upgrading for PostgreSQL-related upgrade guidelines.

Container Network Policies SIEM Integration

Container Network Policies SIEM Integration

We’re pleased to announce a new SIEM integration for Container Network Policies! The integration allows users to export their Cilium logs to a SIEM or central logging solution so they can review any anomalies detected by their Network Policies. This visibility into the logs also helps users to test and tune their Network Policies to reduce false positive rates. The SIEM integration can be configured on the Operations > Kubernetes page.

Live Information about Vulnerability Database

Live Information about Vulnerability Database

We know that understanding what GitLab scans for is important to ensure that you feel safe. With this release, we are introducing a new page to give you more information about the vulnerability database our scanners use.

From this page, you can get information about what we are scanning for, when we last updated our database, and also look up specific vulnerabilities you are concerned about.

Secret Detection for the Full History of a Repository

Secret Detection for the Full History of a Repository

GitLab 13.0 updates our Secret Detection Security Scanning to support a new configuration variable (SAST_GITLEAKS_HISTORIC_SCAN) to allow scanning the full history of a repository. This allows you to identify historical secrets that might be hiding in your older git commit history. Since introduction in GitLab 11.9, Secret Detection scanned the commit history of changes in a merge request. This would detect new secrets but would not identify secrets in the repository’s older git history. This new functionality is particularly useful when you are enabling Secret Detection in a repository for the first time and you want to perform a full secret scan.

We have created a short video walkthrough showcasing how you can perform a historical secret scan via scheduled pipeline or with a manual pipeline.

Web Application Firewall (WAF) SIEM Integration

Web Application Firewall (WAF) SIEM Integration

We’re pleased to announce a new SIEM integration for the Web Application Firewall (WAF)! The integration allows users to export their WAF logs to a SIEM or central logging solution so they can review any anomalies detected by their WAF. This visibility into the logs also helps users to test and tune their WAF rules to reduce false positive rates. The SIEM integration can be configured by enabling Fluentd on the Operations -> Kubernetes page.

Email notification for unknown sign-ins

Email notification for unknown sign-ins

Users will now receive an email notification when a sign-in using their credentials occurs from a new IP address or device. This new functionality helps users quickly identify potential malicious activity related to their accounts.

Export and Import Groups in the UI

Export and Import Groups in the UI

Previously, users could only migrate groups by using the Export/Import API to create an Export file, then using the API a second time to upload the file to the target instance.

As a first step toward a more frictionless solution, we have enabled Group Export in the GitLab UI. We plan to introduce similar Import functionality to the UI within the next few weeks.

Group-level push rules

Group-level push rules

Push rules provide additional control over what can and can’t be pushed to your repository. They allow you to create custom operational standards that align with your organizational policies.

Previously, push rules could only be set at the instance or project level, forcing admins to manage large numbers of people and projects independently. New group-level push rules will allow group owners a way to govern policy in a central location, while still providing individual project owners with flexibility.

Value Stream Analytics

Lead time, cycle time metrics

Value Stream Analytics

Lead time, cycle time metrics

Two key value stream metrics now give teams a baseline against which process improvement efforts may be measured so that they may more easily see the impact of process changes. Lead time measures the elasped time between a requested item and its delivery. Cycle time measures the length of the development cycle itself. By optimizing flow across the entire value stream, teams avoid moving a problem from one place to another and ship faster.

Add Epics or issues via the Epic Tree more easily

Add Epics or issues via the Epic Tree more easily

Creating and adding issues and epics in the Epic tree used to be split across multiple buttons and drop down menus, and was somewhat cumbersome to use. We have consolidated the “add” and “create” actions into a single button and menu to make it easier and faster to add new issues and epics!

Raise warning when closing an issue with open blockers

Raise warning when closing an issue with open blockers

In GitLab 12.8, we introduced the ability to create dependencies between issues, where one issue can block another related issue. This means that the downstream issue should not be closed until the predecessor is completed and closed. This required you to check to see if an issue is blocked before you closed it.

Having to check if an issue is blocked prior to closing the issue is an additional step that is unnecessary and easy to forget.

We’ve eliminated that step by showing you a warning if you attempt to close an issue with unresolved blockers. We also provide links to the blocking issues so you can verify that your issue is safe to close.

This level of increased dependency alerts helps keep projects running smoothly, and ensures that sequencing of issues can be maintained!

Approved-by filter for merge requests

Approved-by filter for merge requests

Merge Request Approvals require specific people to approve changes before they can be merged. When searching the merge request list, you can quickly find which merge requests need your approval using the Approvers filter. In GitLab 13.0, you can now also find any merge requests you previously approved using the new Approved-By filter.

Design Management moved to Core

Design Management moved to Core

In the 12.2 release, Design Management debuted with Design Uploads and Point of Interest Discussions as a GitLab Premium feature. Since then, we’ve considered our users who are designing products as individual contributors and, in 13.0, we’re excited to announce we’ve moved these two features down to GitLab Core! This aligns with our Individual Contributor Buying Model and we expect to add other great team features in the future, like approvals, as we progress towards category maturity.

So now, all users can upload and participate in design feedback on issues in GitLab! As a refresher, you’ll find the Design tab next to the Discussion tab on any issue. Try a drag-and-drop upload of a screenshot to get started!

New comparison mode for Merge Requests

New comparison mode for Merge Requests

Merge Requests, particularly the Changes tab, is where source code is reviewed and discussed. In circumstances where the target branch was merged into the source branch of the merge request, the changes in the source and target branch can be shown mixed together making it hard to understand which changes are being added and which already exist in the target branch.

In GitLab 13.0, we are adding an experimental comparison mode, which will show a diff calculated by simulating a merge - a more accurate representation of the change than using the merge base of the two branches. The new mode is available from the comparison target drop down by selecting master (HEAD). In the future it will replace the current default comparison.

Syntax Highlighting Themes for the Web IDE

Syntax Highlighting Themes for the Web IDE

GitLab supports six syntax highlighting preferences when viewing code. Themes are important to developers when viewing and editing code on GitLab since it’s imperative that they work comfortably throughout the day. We’ve now released support for all six syntax highlighting preferences in the Web IDE. This includes Solarized Dark, Solarized Light, Monokai and a no highlighting option.

Over the last few releases (for example, 12.8 and 12.9) we’ve been steadily adding and improving support for syntax highlighting preferences in the Web IDE. These updates follow this effort and help to lay the foundation for our Dark Theme in the Web IDE, also launching in 13.0. We’re excited to continue to expand on developer experience and making the Web IDE feel more like home.

Visually highlight design comment pins so you can follow the discussion

Visually highlight design comment pins so you can follow the discussion

When there are a lot of discussion threads on a design it can be hard to identify which thread relates to which comment pin on the design without scanning for the correct comment number.

In 13.0, we added a mechanism to highlight the relevant design discussion comment pin when you click on the comment. We also added the reverse where you can click on the comment pin and have the relevent comment scroll into view. This reduces manual scrolling and sifting through the noise when you have lots of comment pins.

Configurable browser performance testing threshold

Configurable browser performance testing threshold

Browser Performance Testing allows users to easily detect when there is a degradation in their web app before merging to master. In many cases this causes extra noise and clutters up the Merge Request page unnecessarily, even for minor changes. In this milestone, you can now set an optional degradation threshold as a requirement that must be met before the Performance report will be displayed.

GitLab Runner 13.0

GitLab Runner 13.0

We’re also releasing GitLab Runner 13.0 today! GitLab Runner is the lightweight, highly scalable, cross-platform software agent agent that runs your build jobs and sends the results back to a GitLab instance. GitLab Runner works in conjunction with GitLab CI/CD, the open-source continuous integration service included with GitLab.

What’s new:

• ARM64 Docker image is now available
• Support more glob patterns for artifact/cache such as wildcard patterns
• Make docker+machine autoscaling configuration more elastic

Make JUnit Reports available through the GitLab API

Make JUnit Reports available through the GitLab API

A JUnit report can contain a wealth of information that can be used to update test plans, test execution history, and other artifacts which teams use to track the quality of their code. Updating those artifacts can be a painful, manual, process made worse by the fact that JUnit reports are only available to download from the GitLab UI. Starting in GitLab 13.0 users of the GitLab API will be able to access JUnit reports directly. This will enable users to parse JUnit data to create new issues or update test execution history.

Define policies to ensure important images are never deleted

Define policies to ensure important images are never deleted

When using GitLab’s Image Expiration Policy, there is no way to express something such as “no matter what, don’t delete this tag”. This introduces risk into the deletion process, as it’s possible to delete release or master images, which should be immutable.

In 13.0 we are excited to announce that you can now update your project’s expiration policy to identify images you never want deleted. Simply enable the policy and use regex to identify the image you want to preserve.

Setting to allow Deploy tokens to read and write to the GitLab Package Registry

Setting to allow Deploy tokens to read and write to the GitLab Package Registry

Deploy Tokens allow you to access your group’s repositories, project’s repositories, and container registries. Historically, the defined scopes of read_repository, read_registry, and write_registry have not allowed you to grant access to the GitLab Package Registry. As a result, DevOps teams have used insecure or expensive user-based workarounds.

In GitLab 13.0, we are excited to announce more granular permissions for GitLab Deploy Tokens. You can now set read or write access for the Package Registry. You can also create and manage Deploy Tokens from within the GitLab application or by using the API.

View all of your Python packages in one place with the GitLab Package Registry

View all of your Python packages in one place with the GitLab Package Registry

The GitLab Package Registry user interface allows you to confirm that your packages have been built properly and troubleshoot when something has gone wrong. However, the MVC of the new PyPI Repository that launched in 12.10 did not include this functionality.

In 13.0, we’ve added the PyPI Repository to the Package Registry UI. Now, you can view and download your project or group’s PyPI packages and reference metadata to validate that the package was built properly. You can also quickly copy setup and install commands for more efficient sharing and coding. If the package was built using a GitLab pipeline, you’ll be able to view and link it to the pipeline, as well as the commit that was used to publish the package.

API support for Feature Flag lists

API support for Feature Flag lists

As part of our support for Feature Flag lists, we have added API support to enable creating, editing, and deleting them. This will make it easier to automate the management and synchronization of these lists between different systems.

Update Release’s milestone in Web UI

Update Release’s milestone in Web UI

GitLab’s Release Management team is working on expanding the Release Page to include all the Release API’s functionality. In 13.0, it is now easier to add a single or multiple milestones to your Releases. With this addition, you no longer have to manually call the Release API to take advantage of planning features, such as the Release Progress View, which was introduced in 12.9.

Add annotations to a Metrics Dashboard

Add annotations to a Metrics Dashboard

Sometimes your metric charts can be hard to understand. Starting in GitLab 13.0, you can now add annotations to your metrics charts which appear as dotted horizontal lines overlaid on your graphs and charts, to help you interpret and understand the data.

Aggregate IT alerts from external tools in GitLab

Aggregate IT alerts from external tools in GitLab

When responding to alerts, responders need a single interface that aggregates IT alerts originating from multiple sources. The new alerts list enables you to sort through alerts quickly and intuitively to help you find and triage the most critical problems first. You can access the alerts list at Operations » Alerts.

Emojis render on status page

Emojis render on status page

GitLab issues support emojis in the issue title and all Markdown fields. When you publish a Gitlab issue to a public URL as a status page, the status page now supports and renders emojis used in issue titles, descriptions, and comments.

Toggle Metrics Dashboards visibility

Toggle Metrics Dashboards visibility

Previously, project administrators couldn’t control permission to view a project’s metrics dashboards. As part of GitLab 13.0, admins can now toggle metric dashboard visibility to either project members, or to everyone with access.

Geo improvements to the administrator interface

Geo improvements to the administrator interface

As GitLab grows, Geo continues to support replication for additional resources. This in turn increases the number of status pages that are shown in the sidebar. This approach does not scale well and makes it harder for systems administrators to find what they need. In GitLab 13.0, we merged the sub-pages for Projects, Uploads and Designs into a single view that can be accessed via a single sidebar entry “Replication”. This change groups all the information in one place and helps systems administrators access the replication status of individual items.

Additionally, we’ve made a few other user experience improvements to the administrator interface:

• Made selective-sync settings more visible on the index page
• Display the last data update as part of the health status to make it more prominent
• Added empty state illustrations and help texts to guide users
• Modified the width of the Geo settings to conform with our design system

GitLab Helm chart improvements

GitLab Helm chart improvements

• The Helm chart now supports configuration of multiple Redis instances. This allows you to have different Redis instances for different storage types, for use with our 10,000 users Reference Architecture. For details on specific changes, refer to the issue.
• Now that Puma is the default web application server, with the option to still switch back to using Unicorn, the name of the Unicorn chart has changed from unicorn to webservice. For configuration details, see the Charts documentation.
• The ConfigMap entries for puma.rb and unicorn.rb files have been removed in favor of environment variables. Please note that if you have modified the unicorn.rb from the ConfigMap (via Helm + Kustomize) in the past, you will be impacted by this change. We are doing this to eliminate maintaining two copies of these files. Until now, the puma.rb and unicorn.rb files were static within the gitlab-webservice container and overwritten by ConfigMap items from the gitlab/unicorn chart. For details on the new environment variables, refer to the associated merge request.
• The version of Ruby used by the GitLab Helm chart has been updated to 2.6.6.

Omnibus improvements

Omnibus improvements

• The minimum required version of PostgreSQL is now PostgreSQL 11. See the PostgreSQL 11 announcement for more details.
• In Redis 5, the terminology for slave was changed to replica. In GitLab 13.0, this change was made in the Redis configuration in Omnibus. See Important notes on upgrading for upgrade instructions.
• GitLab 13.0 includes Mattermost 5.22, an open source Slack-alternative. This release includes team switch shortcuts, ability to unarchive channels from the user interface, experimental channel sidebar features, and much more. This version also includes security updates. If you have a Mattermost environment that contains a lot of emoji reactions, please refer to Important notes on upgrading for information on longer upgrade times.
• The version of Ruby packaged in Omnibus GitLab has been updated to 2.6.6.

Bug fixes

Bug fixes

Some of the notable bug fixes in GitLab 13.0 are:

• Let’s Encrypt integration doesn’t scale and does not give any feedback to user on errors
• Environments page returns error 500
• Adding pages domain with any validation error result in 500
• Text for future Release date grammatically incorrect
• Skipped tests are included in success percentage calculation
• JUnit parsing errors are not visible to users
• Tags can be deleted again when a branch with the same name exists
• Only Code Owners are allowed to merge
• Fix permissions of docker volumes created by Runner
• Fix removal of build volume when disable_cache set to true
• Fix err checks from volume manager
• Fix duplicate volume check with trailing slash
• ActionView::Template::Error: undefined method `can?’ for nil:NilClass
• Scala GitLab CI template does not work
• Make it possible to set weight of board scope to None or 0
• Fix subgroup milestone links in group milestones view
• Fix error when attempting to promote some issues to epics
• Fix counts in some GraphQL pagination responses
• Author issues imported from Jira as the user running the import
• Make issues API and Web UI display same results
• Roadmap showing Closed Epics, when display “Open Epics” is selected
• Search API scoped to blobs does not honor per_page
• Elasticsearch: wiki is not correctly indexed on import
• Clicking on search results does not follow link
• Wiki search doesn’t work with project repository disabled
• Indexer may eventually panic with repeatedly requests failure

Export vulnerabilities list from Instance and Project Security Dashboards

Export vulnerabilities list from Instance and Project Security Dashboards

We’re pleased to announce the initial release of exportable vulnerability lists from the Instance Security Dashboard and Project Security Dashboard. While the Security Dashboards let users manage vulnerabilities as part of the GitLab workflow, it hasn’t been as easy to get a list of this information for external use.

You can now download a CSV file containing the detected vulnerabilities for a given project or all projects configured on the Instance Security Dashboard. This export list can then be used for things such as creating compliance reports or as a data source for external dashboards. Simply go to the instance Security Dashboard or any project’s Security Dashboard and click the new Export button in the upper-right or go to the Security option under the More menu in the top navigation bar, then click the new Export button in the upper-right. Your browser will automatically start the download.

Performance Improvements

Performance Improvements

We are continuing to make great strides improving the performance of GitLab in every release. We’re committed to not only making individual instances of GitLab even faster, but also to greatly improving the performance of GitLab.com, an instance that has over 1 million users!

In GitLab 13.0 we are shipping performance improvements for issues, projects, milestones, and a lot more! Some of the improvements in GitLab 13.0 are:

• A comprehensive list of performance improvements to atomic processing of pipelines
• Use NDJSON for Group and Project Exports and Imports to improve memory usage
• Make Elasticsearch enabled check in Redis more efficient
• Speed up NOT (!=) filters
• Switch ThreadMemoryCache to ProcessMemoryCache
• Reorder email handlers for better performance

View DAST Scanned Resources List

View DAST Scanned Resources List

DAST analyzes your running web application for known runtime vulnerabilities, starting with each merge request. DAST scans many resources, but knowing precisely which ones was not possible before.

GitLab 13.0 presents a full list of the resources that DAST scanned. You can now evaluate DAST scans to ensure all necessary application surfaces are covered. For further ease of analysis, you can download scan lists directly from the results screen.