GitLab 13.3 Release

Compliance Dashboard shows more information

Compliance Dashboard shows more information

Organizations need visibility into the compliance status of their groups and projects. A major component of compliance is the merge request; it is often the primary gating mechanism to ensure the appropriate policy and process has been followed. As such, one of the most important details of a merge request to highlight is to indicate the separation of duties between author and approver.

Now, within the Compliance Dashboard, you can view both the merge request author and the approver(s), enabling you to more quickly hone in on the projects that may not have maintained separation of duties.

Merge Request Analytics

Merge Request Analytics

Many organizations, including GitLab, use throughput as a way of measuring how fast a team can do work. We’re now introducing a first iteration of Merge Request Analytics to help your team better understand the rate of merged MRs in your projects.

Available at the project level, Merge Request Analytics can help an engineering team quickly understand MR activity at a glance. Users interested in a more detailed look—for example, a team lead interested in MRs with a specific label—are also able to filter and see a detailed list of relevant MRs.

Prevent forking outside a group

Prevent forking outside a group

Group administrators can now prevent the projects within their group from having new forks created outside of the current top-level group. This new setting gives group administrators additional mechanisms to protect their group’s intellectual property.

Display a single file when reviewing merge requests

Display a single file when reviewing merge requests

Reviewing merge requests diffs is an essential task when reviewing code contributions, as this is where most of the communication between author and reviewer takes place. However, as merge requests become larger and more files are involved, navigation and performance of merge request diffs can become difficult.

To resolve this, GitLab 13.3 introduces an option to see one file at a time on the Changes tab of merge requests. It provides a cleaner workspace and enhances the reviewer focus on one single file. At the bottom, you can navigate between the files changed by clicking the Prev and Next buttons. It can be optionally enabled through user preferences.

Thanks to GitLab user Osher for contributing to the initial iteration.

Concurrent Git repository backups

Concurrent Git repository backups

Backups protect against data loss events and should be run regularly, and before maintenance and upgrades. For this reason, GitLab has a gitlab-backup script so that system administrators can back up everything. As the number and size of repositories increases, backing up repository data using the script becomes impossibly slow.

A significant reason why the script is slow is that repositories are backed up one by one. This underutilizes the available CPU and memory resources, particularly when there are multiple Gitaly nodes. Adding concurrency allows multiple repositories to be backed up at the same time, significantly reducing backup time.

Drag and drop to reorder designs

Drag and drop to reorder designs

If you are using GitLab to design a product with screens or a user flow, you’ll want to place your designs in a specific sequence to present the full concept to your team.

Previously, designs were only displayed in the order in which they were uploaded, complicating reviews and leading to frustration.

As of 13.3, you can now drag and drop your designs into any order! The order is saved so that anyone who views your designs will see the order you intended. Go forth and create the flows you imagine or re-order to match your frames in Figma or Sketch!

Find references added to Code Intelligence

Find references added to Code Intelligence

Code review is an important process that requires an understanding of the proposed change and surrounding code to know if it has been made in a maintainable way. GitLab’s native Code Intelligence helps developers navigate code and understand changes introduced in merge requests. This is important to understand existing code as well to ensure new code is added in a responsible way.

GitLab 13.3 introduces the ability to display references for projects using GitLab’s native Code Intelligence. Clicking on an object in your code will display the definition and offer the ability to browse references on the second tab, displaying the full path and line number where the object is being used.

Future iterations will include API support and displaying the code for references in the popover. You can follow along in the Code Intelligence epic.

Gitaly Cluster reference transactions

Gitaly Cluster reference transactions

Gitaly Cluster allows Git repositories to be replicated on multiple warm Gitaly nodes. This improves fault tolerance by removing single points of failure. Write operations are currently replicated asynchronously however, which means that the GitLab server only has one copy of the change from when the write is accepted, until replication is complete.

Transactional write operations to Git repositories in GitLab 13.3 causes changes to be broadcast to all Gitaly nodes. Only the Gitaly nodes that vote in agreement with the primary node persist the changes to disk. Dissenting nodes are brought in sync by asynchronous replication. This means the change will typically be written to all Gitaly nodes when the write is accepted. This is not guaranteed, however, because all replica nodes could vote against the primary. Quorum-based voting (beta) can be enabled to prevent this.

Note: Gitaly Clusters can be created using GitLab Core and higher tiers. However, technical support is limited to GitLab Premium and Ultimate customers only.

Transactional writes for Gitaly Cluster (beta)

Transactional writes for Gitaly Cluster (beta)

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.

Audit logs for CI/CD group variables

Audit logs for CI/CD group variables

When you can’t track changes to CI/CD variables, it’s difficult to understand what might have caused your pipeline to fail. Now, in our first iteration of variable audit logs, you can track changes to group-level CI/CD variables. This new audit log captures three events: group variable additions, removals, and protected state changes.

CI linter now can provide warnings in addition to errors

CI linter now can provide warnings in addition to errors

The CI linter can now provide warnings in addition to error messages when validating your .gitlab-ci.yml file. This gives us the opportunity to provide more guidance when evaluating your pipelines, thereby making it easier to avoid more kinds of mistakes by catching them earlier.

Our initial iteration is to provide a warning when the when:always rule is used without workflow:rules; this scenario causes duplicate pipelines when an MR is created and has also been a source of confusion. And in addition to displaying this new warning message on the linter page, it will also appear on the pipeline view and run pipeline page to help you improve your CI configurations.

Configure a job artifact to never expire

Configure a job artifact to never expire

As a developer, you have the ability to specify a job artifact’s exact expiration date, but there are scenarios where you may need to retain an artifact forever. Now, you can set an artifact to never expire by setting the value of expire_in to never in your CI configuration.

Improve Fail Fast Testing Template

Improve Fail Fast Testing Template

We introduced the Fail Fast Testing template in GitLab 13.1 and gathered feedback from internal stakeholders. We found that if the default image was being overridden in a .gitlab-ci.yml file, the template would not work. We’ve since improved the Fail Fast template so you can now trust the Fail Fast Template to work out of the box, even if you specify a different image.

View and manage group Runners

View and manage group Runners

We’ve added a new group management user interface (UI) for managing your organization’s Runners. In this new UI, you can view, edit, pause, and stop any Runner that’s associated with your group in GitLab. This makes it easier to troubleshoot potential issues with Runners for multiple projects at once.

Use CI job token to publish NuGet packages

Use CI job token to publish NuGet packages

You can use the GitLab NuGet Repository to build, publish, and share .NET packages, right alongside your source code and CI/CD Pipelines. However, previously you couldn’t authenticate with the repository by using the pre-defined environment variable CI_JOB_TOKEN. As a result, you were forced to use your personal credentials for making updates to the NuGet Repository, or you may have decided not to use the repository at all.

Now it is easier than ever for you to use GitLab CI/CD to publish and install NuGet packages using the pre-defined CI_JOB_TOKEN environment variable.

Rename Feature Flag user strategies

Rename Feature Flag user strategies

In an effort to simplify the Feature Flag strategies and prevent confusion we have renamed them. Percent rollout (logged in users) has been changed to Percent of users and List has been changed to User List.

Set a deploy freeze in the UI

Set a deploy freeze in the UI

This feature expands on the API capability of setting a deploy freeze window, which we introduced in 13.0. Now, from the GitLab UI, you can easily set a time period when deployments can’t occur. You no longer have to use the API to script your deploy freeze or use .gitlab-ci.yml. Instead, you can easily go to the UI settings to create a recurring or one-time deploy freeze.

Use API to source Pages domain configuration

Use API to source Pages domain configuration

You can now configure GitLab Pages to source a project’s configuration through the GitLab internal API, and take advantage of the API for quicker GitLab Pages daemon booting times.

Create GitLab issues from PagerDuty Incidents

Create GitLab issues from PagerDuty Incidents

You can now generate GitLab issues from PagerDuty incidents, automatically notifying your responders when alerts are triggered, and centralizing your responses within GitLab.

Display metrics in alerts from externally-managed Prometheus

Display metrics in alerts from externally-managed Prometheus

When you receive alerts, GitLab helps you reduce investigation time by including the relevant metrics chart in the alert, helping you visualize what went wrong. In GitLab 13.3, we are introducing including metrics from an externally managed Prometheus instance within the alert.

Manually create Incidents from the Incidents List

Manually create Incidents from the Incidents List

When maintaining the availability and reliability of a service, you don’t always learn of problems from your alerting systems: customers report outages, or team members spot anomalies. Regardless of the source, you can now manually create Incidents from the Incident List to mobilize your response teams when you learn of a problem.

Simpler, streamlined Metrics dashboard control bar

Simpler, streamlined Metrics dashboard control bar

Previously, dashboard actions such as creating, editing, duplicating, and adding metrics were scattered across the metrics dashboard. GitLab 13.3 organizes these items into a single actions menu, simplifying access to dashboard management features.

GitLab chart improvements

GitLab chart improvements

• It is now possible to configure a dependency proxy for upstream images/packages in the GitLab Helm chart. Note that backup and restore, and migration from Omnibus are not currently supported. To learn more about dependency proxy, see Dependency Proxy. For configuration instructions, see Configure Charts using Globals.
• The settings to configure object storage have been consolidated so that object storage for all objects can be configured by one section in values.yml. This is a great improvement that makes object storage configuration much more efficient, including the ability to use a single credential for multiple S3 buckets. It also enables GitLab Workhorse to upload files directly with its own S3 client, eliminating the need for pre-signed URLs. For more details, refer to the Object Storage documentation.
• For improved aggregation, the Workhorse log is now output in JSON rather than as unstructured data. For more details, see the related issue.

PostgreSQL 12 is now available

PostgreSQL 12 is now available

PostgreSQL 12 is now supported as an opt-in PostgreSQL version for self-managed installations of GitLab. PostgreSQL 12 includes a number of performance improvements such as improved query performance for large data sets. For a full list of improvements, see the PostgreSQL release page. Support for using PostgreSQL 12 with a PostgreSQL cluster and Geo sites will be coming soon. For more details on support for PostgreSQL 12 in GitLab, see the PostgreSQL 12 epic. PostgreSQL 12 is scheduled to become the default version of PostgreSQL in GitLab 13.6, but it will still be possible to opt out of this version.

Faster rendering of rich content

Faster rendering of rich content

One of the common tasks users perform in the GitLab UI is viewing rich content, for example rendered markdown in an issue, a merge request, or just viewing a file. For large content, this can take a long time to complete, resulting in a lengthy wait.

In GitLab 13.3, we have optimized how this content is generated, improving user experience and reducing load on the server. The GitLab changelog, a 14,000 line markdown file, now takes 20 seconds to view instead of 35, for a 40% improvement!

Links to search results now unfurl in tools like Slack

Links to search results now unfurl in tools like Slack

Unfurling a URL in tools like Slack provides useful context for other team members. In GitLab 13.3, search result pages have updated meta headers to provide a better description when unfurled.

Bug fixes

Bug fixes

Some of the notable bug fixes in 13.3 are:

• Release asset link type and filepath are not saved when creating a new Release through the API
• Access Control for GitLab Pages leads to 503 error
• Cannot cancel creation of new release
• Pages access control doesn’t pick-up custom CA certs on authentication
• Error loading Vulnerability List when linked issue has been moved
• Mirrored projects don’t replicate tags to secondary nodes
• Sign in doesn’t work on a secondary with relative URL
• Geo: Redownloading repositories via snapshot does not work
• Jira issue importer limits project selection to 100 results
• Markdown not rendering in new iteration or iteration report
• Iteration issue list doesn’t include subgroup issues
• Search results page is changing the sort order incorrectly/arbitrarily
• Generated Blob ID was too long to be handled by Elasticsearch
• Efficient Counters
• Child pipelines and their jobs are not found by API endpoints
• Remove public issues from suggestions when adding issue to confidential epic

DAST vulnerability evidence

DAST vulnerability evidence

Vulnerabilities that have been found by a DAST scan can be difficult to reproduce, since the vulnerability might be reproduced only under certain circumstances. It can also be difficult to pinpoint what code is responsible for the issue when attempting to fix it. Evidence of the vulnerability discovered by the DAST scan is now included in the vulnerability details, making reproduction and remediation easier.

Performance Improvements

Performance Improvements

In every release, we continue to make great strides improving GitLab’s performance. We’re committed to making every GitLab instance faster. This includes GitLab.com, an instance with over 1 million registered users!

Some notable performance improvements in GitLab 13.3 are:

• Investigate and reduce amount of ‘CACHE’ SQL for Projects::NotesController#create
• Rollout update nodes optimization feature for banzai reference filter
• Wasteful extra project ID filtering in project scoped search
• Prevent N+1 in board list issue service via strong memoize

Create multiple custom value streams

Create multiple custom value streams

In this release, we’re making customizable Value Stream Analytics (VSA) even better by allowing teams to create multiple custom value streams. Customizability in VSA allows teams to have detailed understanding of a group’s activity, and you’re now able to create and reuse your customized stages in this feature without needing to re-create them each time.

This is ideal for projects and groups collaborating across multiple departments, where each department may measure value differently. A project manager may want to see a value stream defined by issue labels, but an engineering team may want to understand merge request activity and time to deploy. With multiple value streams, you’re now able to create and customize separate value streams for both.

Option to disable unknown sign-in email notifications

Option to disable unknown sign-in email notifications

We have improved the logic for unknown sign-in email notifications so that users receive fewer emails. We recommend leaving unknown sign-in email notifications enabled, but GitLab administrators will now also have the option to disable unknown sign-in email notifications for their instance. This option can be used in cases where users cannot accept cookies in their browser and users’ IPs change often.

Set default role for SAML SSO users

Set default role for SAML SSO users

To simplify the group member onboarding flow, GitLab 13.3 introduces the ability for group owners to set any role as the ‘Default membership role’ for users added to the group by SSO or SCIM. Previously all group members added to the group by SSO or SCIM were assigned the ‘Guest’ role by default.

Toggle epic confidentiality

Toggle epic confidentiality

As confidential work becomes ready to be shared on a more public level, it can be difficult to share a collection of issues and their parent epic. You can now toggle the confidentiality of your epics, enabling or disabling visibility for those with the proper access.

Display non-Markdown content in the WYSIWYG Static Site Editor

Display non-Markdown content in the WYSIWYG Static Site Editor

Static site generators often rely on Markdown to organize content and the Static Site Editor offers an intuitive WYSIWYG Markdown editing experience for those documents. However, their content isn’t always written in Markdown. Many generators support additional markup embedded in the Markdown to extend the author’s capabilities. It is also valid to write HTML alongside markdown content.

The Static Side Editor’s WYSIWYG mode now separates non-Markdown content into uneditable content blocks, displayed inline with your content. This prevents unexpected formatting errors that can arise when the editor attempts to convert non-Markdown content to HTML. The non-Markdown content is still editable in the raw source mode of the Static Site Editor and future iterations will enable safely editing this kind of content within the WYSIWYG mode.

Enhanced Web Editor

Enhanced Web Editor

We’ve upgraded the web editor to a lighter-weight version of the editor found in our Web IDE. This adds basic code completion and linting for some languages. We’ve also improved source code language detection for better syntax highlighting, and added support for all our syntax highlighting themes. These improvements make it easier to edit and collaborate on files in projects.

Gitaly Cluster read distribution

Gitaly Cluster read distribution

Repositories with many contributors combined with highly parallelized CI pipelines, or highly variable project access patterns can cause high CPU and memory usage, decreasing availability. Mitigating these performance problems by sharding generally results in over-provisioning to handle peak load.

Gitaly Cluster allows Git repositories to be replicated on multiple warm Gitaly nodes, and can be used to scale performance by distributing read operations between up-to-date replicas. From GitLab 13.3, when using Gitaly Cluster, read operations will automatically be distributed between up-to-date replicas. This better utilizes the available CPU and memory resources, and scales better in comparison to sharding. Read the Cluster or Shard documentation to learn more about the benefits of Gitaly Cluster.

Note: Gitaly Clusters can be created using GitLab Core and higher tiers. However, technical support is limited to GitLab Premium and Ultimate customers only.

Squash Commits Options

Squash Commits Options

Squashing commits in Git is a great way to combine several commits into a single one. It’s great for grouping several commits, which by themselves may provide little historical value, into a single large commit before pushing upstream. Pushing a single commit allows for a more meaningful commit message, as well as ensuring the group of commits provides a “green” continuous integration pipeline.

In GitLab 13.3 we are adding configurable defaults for squashing commits, allowing project maintainers to configure the option to suit their preferred workflow. Because changing squash configuration may introduce unwanted behavior, configuration has not been changed for new or existing projects. With 314 upvotes 👍, this is one of the most highly requested improvements by the community and we hope it allows more users to use this powerful feature.

WIP merge requests renamed Draft merge requests

WIP merge requests renamed Draft merge requests

WIP (work in progress) status for merge requests provide a clear signal to reviewers that the merge request in question is not yet ready to be merged.

In order to use a more inclusive and self-explanatory term, the WIP (work in progress) feature for Merge Requests has been renamed to “Draft”. This term clearly communicates the MR in question is not ready for review as well as not making any assumptions about the progress being made towards it. Additionally, it reduces the cognitive load for new users, non-English speakers, and anyone not familiar with the WIP acronym.

WIP merge requests are now deprecated in favor of draft merge requests, however both terms will be supported until the next major GitLab release (14.0), after which it will be removed.

Better linting for .gitlab-ci.yml files

Better linting for .gitlab-ci.yml files

When reviewing your CI definitions, you can now use our CI linter to go deeper into pipeline processing to validate the correctness of your .gitlab-ci.yml. The CI linter provides feedback not only for syntax validation, but it also validates other kinds of logical errors and invalid configurations by simulating the pipeline as if you were running on master (without actually running anything). This helps you produce a properly configured pipeline faster and helps you avoid situations where a pipeline passed the linter but still could not run.

CI/CD rules:if support logical expressions with parentheses

CI/CD rules:if support logical expressions with parentheses

If you use the rules keyword with if clauses, it’s now even more powerful, with support for bracketed expressions evaluated by the pipeline processor. You can use more complex and efficient AND (&&) / OR (||) expressions, making your pipelines rules more logical, powerful, and easier to manage.

GitLab Runner 13.3

GitLab Runner 13.3

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

What’s new:

• Add an ENTRYPOINT script to the GitLab Runner helper image
• Update installed Git version for Windows helper images
• Update Ubuntu Docker container to Ubuntu 20.04

Bug Fixes:

• Fix: Register with the --run-untagged option not working with rpm/deb latest in gitlab-runner-13.2.0-1
• Fix: SELinux alerts: SELinux is preventing gitlab-runner from name_connect access on the tcp_socket port 443
• Fix: PowerShell error when running job
• Fix: Network per build: health check for services time out

The list of all changes is in the GitLab Runner CHANGELOG.

JUnit Report Improvements

JUnit Report Improvements

We introduced the JUnit report in GitLab 12.5 which provides a view of all JUnit tests that run in a pipeline. The wider community helped identify some readability and usability issues in the report interface that made it hard to use, especially when the names of tests or suites exceeded a specific number of characters. Additionally, performance of the page could be slow when parsing very large files or a large quantity of junit.xml files. Now, you’re presented with a JUnit report that’s easier to read and you can take confidence in the fact that the pipeline page will load quickly even when loading thousands of tests. This feature is no longer behind a feature flag by default and is enabled for all users on GitLab.com.

Improved presentation of package metadata and activity

Improved presentation of package metadata and activity

The GitLab Package Registry is where you store and share a variety of package formats. When you navigate to the user interface, you want to quickly understand how the package was built and how to install it. We’ve redesigned the package details page to prioritize recent activity, code snippets, and additional metadata. We removed the two-column table that had data that was duplicated or not useful.

The main section of the package detail UI now includes:

• A new “History” feed that shares the time-based metadata related to a package.
• The installation commands and registry setup instructions.
• A way to add “Additional Metadata” to capture any metadata not related to time. This additional metadata section offers the flexibility of including a variety of details specific to different package formats.

This change is a clear sign that the Package Registry capabilities with GitLab are maturing. The ‘ugly’ table that we removed was a carry-over from the original Maven Repository. Back then, we only presented basic metadata like name and created_date. Now you can see how a package was built and trace back to which pipeline and which commit was responsible. We look forward to the continued evolution of this product. Enjoy and let us know what you think!

Confirmation dialog before regenerating Feature Flag instance ID

Confirmation dialog before regenerating Feature Flag instance ID

It is too easy to accidentally regenerate an instance ID for a feature flag when you actually intend to copy the instance ID. If the instance id gets regenerated, you need to update it in your application and then restart the application in all environments. Now there is a confirmation step that requires you to type the name of the project before regenerating the ID. This will greatly reduce the risk of unintentional ID regeneration.

Review App links accessible for any user

Review App links accessible for any user

Until now, you weren’t able to see Review App links on a Merge Request if you weren’t a member of the respective project where the MR was originally created. In 13.3, we have made review apps accessible to any user, allowing you to get feedback on your code changes from anyone, even your customers. By allowing everyone to contribute, you can better collaborate and shorten your feedback loop.

Track deployment events in GitLab with webhooks

Track deployment events in GitLab with webhooks

GitLab has made it easier for you to build deployment automation with a webhook that supports successful, failed, and canceled deployments.

Add runbooks to GitLab Alerts

Add runbooks to GitLab Alerts

When an incident occurs, knowing how to respond can be difficult if the on-call engineers didn’t write the code causing an incident. Having access to runbooks, or knowledge about a metric causing alerts, is critical to identifying the root cause of a problem and solving it quickly. You can now add runbooks to the alerts you configure in GitLab so that triggered alerts provide your on-call team the steps needed to resolve the issue.

Display metrics dashboard data in gauge format

Display metrics dashboard data in gauge format

We’ve introduced gauge charts as a new visualization option on your monitoring dashboard to show progressive values for a single metric.

Link alerts from GitLab-managed Prometheus to logs

Link alerts from GitLab-managed Prometheus to logs

When triaging alerts, there’s no time to lose: you must investigate quickly without context-switching. GitLab 13.3 saves you time by linking from the chart, located in the Metrics tab of an alert, to the logs for a metric.

Organize Incidents by status in list view

Organize Incidents by status in list view

When coordinating response teams across multiple incidents, it’s extremely important to know which Incidents are open - and require immediate attention - and which ones are resolved and closed. GitLab 13.3 now separates Incidents by status and organizes them into tabs, helping you to focus on the relevant, open Incidents.

Geo is faster and easier to maintain

Geo is faster and easier to maintain

Geo replicates data from a primary Geo node to one or several Geo secondary nodes. Backfilling data to secondary nodes as quickly as possible is critical to ensure that secondary nodes don’t fall too far behind.

After a number of iterations (51 MRs!), Geo no longer requires PostgreSQL Foreign Data Wrappers (FDW). This eliminates the possibility of some database timeouts and increases the overall performance of backfill operations. Additionally, this change reduces a step when configuring Geo and makes it easier to maintain a Geo deployment. To give an idea of the reduction in complexity, this change resulted in 3,823 net lines of code being removed.

Omnibus improvements

Omnibus improvements

• To prevent PostgreSQL upgrade failures due to insufficient space, and to make the upgrade experience smoother, GitLab now checks to make sure you have sufficient free space before performing a PostgreSQL upgrade with the pg-upgrade command.
• It is now easier to specify a timeout value for PostgreSQL upgrades. Previously, the timeout value for pg-upgrade could only be specified in units of milliseconds. It is now also possible to specify the value in days, hours, minutes, seconds, or milliseconds, or some combination of these. For example, 1d2h3m4s5ms.
  • GitLab 13.3 includes Mattermost 5.25, an open source Slack-alternative whose newest release includes a Jitsi integration for video conferencing and screen sharing, an enhanced Welcomebot plugin, and more. This version also includes security updates. Upgrading from earlier versions is recommended.

Faster loading of content with many references

Faster loading of content with many references

One of the benefits of GitLab being a single application for DevOps, is that it is really easy to link content together. We support referencing labels, milestones, snippets, commits, merge requests, issues, and epics in all parts of GitLab. It is not uncommon for a single piece of content to reference tens or even hundreds of other items. This connectedness however can cause delays in rendering the content to users, as the GitLab server needs to look up each reference to present additional context.

In GitLab 13.3, the performance of reference lookups has been improved significantly. For a sample piece of content with 165 references, it was generated 75% faster with half the memory footprint, resulting in a significantly faster user experience with less load on the GitLab server.

Improve code search matching for Advanced Search

Improve code search matching for Advanced Search

The current code analyzer for the Elasticsearch integration doesn’t take all code cases into account. For example, if you have a file with a.b.c=one_two_three and you search for one_two_three, you wouldn’t get the file returned in the search. In GitLab 13.3, we have improved the code analyzer in Elasticsearch, and it is now more robust at matching searches with special characters.

Additional details on Project Security Dashboard

Additional details on Project Security Dashboard

The Project Security Dashboard is getting even more useful with the addition of new data fields to the vulnerability list. Putting more details on the main dashboard provides an even better overview of a project’s vulnerabilities without having to open the individual vulnerability pages.

For scanners that run against source code, you can now see the line number in the vulnerable file. We’re also including the scanner type (SAST, DAST, etc.) which you can filter by. This makes it easy to quickly drill into a specific subset of vulnerabilities.

We’ve also improved the display of vulnerability identifiers. Many scanners can include more than one identifier for a given vulnerability such as a CVE, CWE, or a proprietary ID. Previously, we picked the first identifier provided to display on the vulnerability list. Now, we always show the CVE if one is available. We also indicate the total number of other identifiers.

Container Network Policies Controls

Container Network Policies Controls

Container Network Policy Controls provide an easily discoverable way to find the documentation on how to install and uninstall Container Network Policies for a Kubernetes cluster. You can access these controls, along with a visual indicator of the current Container Network Policies status, in the Operations > Kubernetes > Applications page’s new GitLab Container Network Policies section.

Link existing Issues to a Vulnerability

Link existing Issues to a Vulnerability

We’re enhancing the Vulnerability Management workflow by enabling users to link existing issues to vulnerabilities. Previously, you could only associate a single issue with a vulnerability by creating a new issue from the vulnerability record. These issues were automatically created in the same project as the vulnerability record.

With this new functionality, you can link one or more existing issues to a vulnerability. It is also possible to link issues from other projects. This provides security and development teams greater flexibility and visibility when managing vulnerabilities, especially across projects.