GitLab UI identifies to administrators that a user is locked

In previous versions of GitLab, administrators could not see in the UI that a user was locked. Now, the GitLab UI identifies locked users to administrators, which helps confirm they are locked.

Setting to enable personalization questions during group creation

In previous releases, we added personalization questions to the group creation process. This information might be helpful for our SaaS users on gitlab.com, but less helpful for self-managed instances. We found out that these additional questions confuse the users and complicate the group creation process. In this release, thanks to Jonas Wälter’s contribution, we’ve added the ability for GitLab administrators to disable these questions.

Sort Docker tags in the Container Registry browser

You can now sort the list of tags in the Container Registry tag details page by name. Previously, there was no sort functionality. This sometimes required you to scroll through many pages to find a specific tag. By default, the tags list is now sorted by name in ascending order. You may also change the sort order to descending. See this issue to track any further work on tag sorting.

Static Analysis analyzer updates

GitLab Static Analysis is comprised of a set of many security analyzers that the GitLab Static Analysis team actively manages, maintains, and updates. Below are the analyzer updates released during 14.6. These updates bring additional coverage, bug fixes, and improvements.

• Spotbugs updated to v2.28.12 - MR, Changelog
  • Updates Log4j library to patched version (v4.5.3). See our updated blog post for more information.
• Code Climate updated to v0.85.26 - MR, Changelog

If you include the GitLab managed vendored SAST template (SAST.gitlab-ci.yml) you do not need to do anything to receive these updates. However, if you override or customize your own CI/CD template, you need to update your CI/CD configurations. To remain on a specific version of any analyzer, you can pin to a minor version of an analyzer. Pinning to a previous version prevents you from receiving automatic analyzer updates and requires you to manually bump your analyzer version in your CI/CD template.

Backup and restore supports Terraform state files

The GitLab-managed Terraform state backend can store your Terraform state securely, sparing you the need to set up additional remote resources. Before GitLab 14.7, our backup and restore rake tasks did not support Terraform state files. GitLab now includes Terraform state files in backups created with the command gitlab-backup create. Administrators no longer need to have a separate backup strategy for these files to protect against data loss. Note that this only applies to items stored in the file system. If you are storing Terraform state files using object storage, enable backups with your object storage provider.

Go to Git blame from code search results

Users often want to understand more about code search results, such as when was a file changed or by whom. Now users can easily answer these questions with fewer clicks by using the View blame link in Global Search results. This change adds an additional link next to lines of code when hovering over results from a code search.

LDAP failover support

You can now specify multiple hosts (using hosts) in your GitLab LDAP configuration. GitLab will use the first reachable host. This ensures continuity of access to GitLab should one of your LDAP hosts become unresponsive.

Thanks to Mathieu Parent for the contribution!

Runner status badges in Admin view

You can now easily visualize the state of all the runners on your instance. The Admin Area for runners now includes status badges and big, bold numbers, so you can see critical data at a glance, improving your runner fleet management experience.

Major Gitleaks performance improvements

Building on the large rule expansion included in GitLab 14.5, we are updating our GitLab Secret Detection analyzer, Gitleaks, to the next major version: (v8). This new, major version includes massive performance updates and a complete rewrite of its core detection engine. Secret Detection historical scans should now run much faster, with a large reduction in memory usage. This means both faster detection and shorter (and more efficient) pipelines. This change also sets us up to make more performance improvements that will improve all non-historical Secret Detection job runs in the future.

Here’s some real world performance data showcasing the speed and memory decreases of v8:

• Large repo (~82K commits) https://github.com/rails/rails
  • memory: 800 MB -> 120 MB (6.67x reduction)
  • scan time: 28 minutes -> 1 minute 24 seconds (21x speedup)
• Medium Repo (~600 commits) https://github.com/zricethezav/gitleaks
  • memory: 300 MB -> 30 MB (10x reduction)
  • scan time: 27 seconds -> 8.9 seconds (3x speedup)
• Small Repo (~36 commits) - https://gitlab.com/gitlab-org/security-products/tests/secrets
  • memory: 26 MB -> 8.4 MB (3x reduction)
  • scan time: 315 ms -> 277 ms

We want to give Zachary Rice a special shoutout, as not only is he a member of the GitLab team, but he’s the creator and maintainer of the open source Gitleaks project, which has helped many organizations, both public and private, search their codebases for leaked secrets. We are thrilled to support his work with Gitleaks, as well as his contributions to the wider open source community.

Delete an agent from the UI

The GitLab Agent for Kubernetes is tested and adopted by hundreds of GitLab customers each month, a few users noticed that it is not straightforward to remove a registered Agent from GitLab. Until now, the agent could be removed only through the GraphQL API. Introduced in GitLab 14.7, you can delete an agent directly from the GitLab UI.

When you delete the agent, GitLab revokes its tokens and the given connection stops working immediately.

Backup and restore supports package registry files

With the GitLab Package Registry, you can use GitLab as a private or public registry for a variety of supported package managers. Before GitLab 14.7, our backup and restore Rake tasks did not support package registry files. GitLab now includes package registry files in backups created with the command gitlab-backup create. Administrators no longer need to have a separate backup strategy for these files to protect against data loss. Note that this only applies to items stored in the file system. If you are storing package registry files using object storage, enable backups with your object storage provider.