Dec 22, 2021 - Viktor Nagy  
14.6

GitLab 14.6 adds seamless Geo experience and supports .NET 6 in SAST

GitLab 14.6 adds seamless Geo experience and supports .NET 6 in SAST

Today, we are thrilled to announce the release of GitLab 14.6, the last release for 2021. This release brings simplified Geo configuration that helps globally distributed teams accelerate Git clone or Git pull commands by automatically using the geo site closest to them, an activity list for GitLab's Agent that logs real-time events such as connection and token status, and various SAST improvements including SAST execution policies and support for .NET 6.

These are just a few highlights from the 30+ improvements in this release. Read on to check out all of the great updates below.

To preview what's coming in next month’s release, check out our Upcoming Releases page, which includes our 14.7 release kickoff video.

Join us for an upcoming event

GitLab MVP badge

This month's Most Valuable Person (MVP) is Kev

Kev has worked over the 14.6 milestones to find and fix over a dozen User Experience issues around the platform. While many contributions were in the Verify stage of the platform, they also added contributions to the Geo, Release, and Create stages.

They have been contributing to the GitLab platform for quite some time with over 240 merged MRs since the 13.1 release. Thank you Kev! 🙌

Key improvements released in GitLab 14.6

Seamless worldwide performance with Geo

Organizations with geographically distributed teams use Geo to provide a fast and efficient experience across the globe. Before GitLab 14.6, you could set up Geo with a single, unified URL for all Git operations. However, Geo replicas each had their own URL for web UI and API access, so users had to know the URL to the specific Geo replicas they wanted to use. The web UI of the Geo replicas was also read-only, limiting users to viewing pages and requiring them to perform changes on the primary site.

In GitLab 14.6, Geo secondary sites transparently proxy write requests to the primary site while accelerating most read requests. Systems administrators can provide all GitLab users across their organization with a single URL that automatically uses the Geo site closest to them. Users no longer need to use different configuration to benefit from Geo, or worry about what operations won’t work on Geo secondary sites. Globally distributed teams now benefit from accelerated git clone or git pull commands, and a seamless worldwide experience.

Secondary proxying and unified URL support is enabled by default for new Geo installations. You can also set up a unified URL on an existing Geo installation and enable secondary proxying.

Seamless worldwide performance with Geo

GitLab Agent’s activity information

Being able to monitor your cluster’s activity helps you detect and troubleshoot faulty events, and rest assured when they succeed.

GitLab now ships with an activity list for the GitLab Agent that logs real-time events. This first implementation logs connection and token statuses and will be followed with more events in future releases. We also plan to provide a similar solution to track CI/CD Tunnel events, for which your early feedback is more than welcome.

GitLab Agent's activity information

Toggle wiki editors seamlessly

Editing wiki pages with the new rich Markdown editor makes it easier for everyone to contribute regardless of how well they know Markdown syntax. You may also prefer to write raw Markdown in some situations, but use the WYSIWYG interface for more complex or tedious formatting tasks, like creating tables.

Previous versions of GitLab required you to save changes before switching between the rich Markdown editor and the Markdown source, adding more steps and friction to your edits. In GitLab 14.6 you can now seamlessly switch between the two editing experiences without committing your changes, choosing the editor that suits your needs at any given moment.


Other improvements in GitLab 14.6

Private contributions visible in the contribution calendar graph

In this release, we changed how the contribution calendar graph in the user profile shows contributions. Private contributions were shown in the contribution list but not in the contribution calendar graph, which meant the user profile didn’t fully represent user contributions. Thanks to Dustin Eckhardt’s contribution, private contributions now appear in the contribution calendar graph.

Use the API to transfer a group to a parent group

In this release we’ve added the ability for you to transfer a group to a new parent group with the Groups API. Previously, this was only possible through the UI.

You can now use the Groups API to move subgroups to a different parent group and make a subgroup into a top-level group.

This new functionality is available to administrators and users with:

  • Owner role for the group to transfer.
  • Permission to create a subgroup in the new parent group if transferring a group.
  • Permission to create a top-level group if turning a subgroup into a top-level group.
Use the API to transfer a group to a parent group

Copy code blocks in Markdown with a single click

Instead of selecting all the code within a block and using your keyboard to copy it to your clipboard, you can now copy code blocks in Markdown with a single click.

Copy code blocks in Markdown with a single click

Squash commit message template

Squashing commits is a great way to clean up the commit history of a merge request by combining all commits when merging. Branch history becomes easier to read and follow, while the story behind the changes remains intact. GitLab previously used the merge request title as the default squash commit message. If you didn’t edit the message before merging, important details about the change could be lost.

Project maintainers can now customize the default squash commit message according to the project needs. Include details about each merge request, like the source and target branches, with helpful variables. With more complete squash commit messages, everyone can now better understand the context of the changes.

Thanks to Piotr for this amazing contribution!

Squash commit message template

GitLab Runner 14.6

We’re also releasing GitLab Runner 14.6 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:

Bug Fixes:

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

Job failure reason returned in API response

It can be hard to use the API to gather data about why a job failed. For example, you might want exact failure reasons to make better use of the retry:when keyword.

Now, the failure_reason is exposed in responses from the Jobs API, and it is much easier to gather job failure data. Thanks to @albert.vacacintora for this contribution!

Webhook triggered for pending jobs

Previously, using job event webhooks for CI/CD monitoring was challenging because it was difficult to track the number of pending jobs that may exist within a project.

Now the webhook triggers an event when a job state changes to pending, so you no longer need to implement workarounds or custom integrations to keep track of all job statuses.

Publish Conan packages with only name and version

You use the GitLab Conan repository to publish and share your C/C++ packages. When creating a Conan package, there are four fields to consider: name, version, user, and channel. These fields uniquely identify a package. The user and channel fields are optional in Conan 2.0, but GitLab required you to continue using them. Customizing your naming conventions to match the requirements in GitLab instead of the standards set by Conan is inefficient and impractical.

We’ve updated the GitLab Conan repository to align with Conan. Now you can publish and download your Conan packages with or without the user and channel fields. This improvement helps you to be more efficient and makes it easier to find and validate packages in the user interface. This change is the first step in a broader set of planned improvements to the Conan repository to help move the feature from Beta to GA.

Custom ruleset composability for SAST and Secret Detection

We’re making improvements to our Custom Rulesets capabilities for SAST and Secret Detection which were introduced in GitLab 13.5. Custom Rulesets let users tailor the behavior of SAST and Secret Detection analyzers to their organization’s preferences. To improve this capability, we’re introducing the ability to add rules from multiple sources, like Git repositories, local files, and raw source changes. This change makes it easier to synthesize and manage multiple custom rulesets from different locations, which organizations can use to inherit rules across repositories and sources for greater flexibility. We showcase the new features in this blog post. Initially, this change is available for our SAST Semgrep, Nodejs, and Gosec analyzers and Secret Detection. We will expand this capability to our other analyzers in future releases.

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.

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 template, you need to update your CI 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 require you to manually bump your analyzer version in your CI template.

Variable DS_EXCLUDED_PATHS behaviour changed to pre-filter

For users of the Dependency Scanning variable DS_EXCLUDED_PATHS, it will now pre-filter. Dependency Scanning now considers DS_EXCLUDED_PATHS when searching for supported projects and will pre-filter out those that match. Pre-filtering prevents the analyzer from logging warnings or failing when processing dependency files that have been explicitly excluded using DS_EXCLUDED_PATHS. This enables users to skip dependency files and build files if desired, and can lead to a performance increase in some cases.

This change was made December 2, 2021 for gemnasium, December 6, 2021 for gemnasium-python and December 7, 2021 for gemnasium-maven. This change applies to all versions as the change is backported.

You should not need to take any action, however if you were expecting this post-filtering behavior, and wrote custom tooling to handle that, you will need to adjust your custom tools. For example, before this change you may have needed to manually or, through the use of a script, delete specific files to avoid a warning or error occurring.

The previous behavior was causing failures and unexpected errors for users and after discussions we found that this, pre-filter as opposed to post-filter, was the more expected and desired behaviour.

Quick action to promote an issue to an incident

After investing time and effort in an issue, sometimes participants realize that the problem is actually an incident. Leveraging the quick action /promote_to_incident, users can now promote an issue to an incident. All existing context (title, description, labels, assignees, comments, and more) remain a part of the incident when the issue is promoted.

Customize deduplication of container scanning vulnerabilities

When scanning images, container scanning by default assumes that the image naming convention stores any branch-specific identifiers in the image tag rather than the image name. For customers who follow a naming convention where the branch name is part of the image name, this default setting makes the scanner unable to properly deduplicate identical vulnerabilities. You can now customize the default setting by specifying a new CS_DEFAULT_BRANCH_IMAGE variable in the container scanning job. This variable is set by default for projects that use Auto DevOps. This allows security checks in merge requests to properly identify new vs. pre-existing vulnerabilities, by de-duplicating any vulnerabilities that already exist in the default branch.

Project owners can now unlink security policy projects from development projects. To do this, first navigate to Security & Compliance > Policies and select the Edit Policy Project button. Then select the trash can icon to unlink a previously-associated security policy project.

Unlink security policy projects

GitLab chart improvements

Lighter stroke-width for icons

Product icons in GitLab have been updated to:

  • Be more balanced with other UI elements.
  • Better align with the brand.
  • Be constructed to be more future-proof by allowing easier iteration and introduction of new icons.
  • Work well in both light and dark UI.
  • Better convey abstract concepts and metaphors.

For more details, see this blog post by Staff Product Designer, Jeremy Elder.

Lighter stroke-width for icons

Set maximum SSH key lifetime

Administrators can now set a maximum number of days that an SSH key can remain valid. This is especially useful for organizations that are required to enforce SSH key expiration after a given interval for compliance reasons. GitLab already had the ability
to set a maximum number of days that Personal Access Tokens (PATs) can remain valid and this feature works in a similar way.

To set this new limit, administrators can navigate to the Admin Area and select Settings > General. Find the new setting by expanding Account and limit to set Maximum allowed lifetime for SSH keys (in days).

Set maximum SSH key lifetime

WebAuthn enabled by default

WebAuthn (supported, but disabled by default, since GitLab 13.4) is now enabled by default. Users can now use Touch ID on Apple devices as a second authentication factor, as long as their browser supports it. This also eliminates error messages seen in browsers that are deprecating U2F in favor of WebAuthn.

Render the title of a referenced issue within markdown

When referencing issues, epics, or merge requests within markdown fields, there was previously no way to surface and display additional context other than the ID. You can now append + to an issue, epic, or merge request reference to render the title.

Render the title of a referenced issue within markdown

View inline the change that outdated a merge request thread

When addressing review feedback in merge requests, you often change lines your reviewers have commented on. In those comment threads, GitLab indicates that new changes were made. However, to understand if those new changes address the feedback, reviewers would have to navigate away from the context of the discussion.

Now, when viewing threads related to old changes, you can view the new changes directly in the thread. This improved context helps you review faster and more accurately.

View inline the change that outdated a merge request thread

GitLab Runner Pod Cleanup

If you have leftover Kubernetes Runner pods, you can now use GitLab Runner Pod Cleanup to clean them up. This open-source utility is installed in the Kubernetes cluster alongside the GitLab Runner Manager, and when configured, deletes orphaned runner pods in the cluster. This new utility reduces maintenance overhead when using the Kubernetes executor for GitLab Runner to execute your CI/CD jobs at scale.

Support job:when and rules at the same time in CI/CD configuration

Previously, it was impossible to configure a GitLab CI/CD job to have both the rules and when keywords defined at the job level. You had to add the when inside every rules section, which could cause long or repeated CI/CD configuration.

In this release we’ve dropped that limitation and you can now use when at the job level along with rules. This makes when more flexible, and helps create job configurations that are much simpler.

Enable Dependency Proxy cleanup policies from the UI

You can use the GitLab Dependency Proxy to proxy and cache container images from Docker Hub for faster, more reliable builds. Over time, your team may add many items to the cache, resulting in higher storage costs.

You’ve been able to work around this by using the API to purge the entire cache. But that’s inefficient because you only want to remove old, stale items that are no longer in use. That’s why we added cleanup policies for the Dependency Proxy. You can programmatically delete from the cache image tags that your team hasn’t recently used. However, this feature required you to use GraphQL, which is inefficient if you don’t use it regularly.

Now you can enable an automatic time-to-live (TTL) policy for the Dependency Proxy from the user interface. Do this by navigating to your group’s Settings > Packages & Registries > Dependency Proxy and enabling the setting to automatically clear items from the cache after 90 days.

Enable Dependency Proxy cleanup policies from the UI

Use Deploy Tokens to download Composer dependencies

You can now use deploy tokens to authenticate users who interact with the Composer repository. Previously, personal access tokens and job tokens were used to authenticate users that published and downloaded composer dependencies from the GitLab Composer repository. These tokens are tied to a specific user. Deploy tokens provide an authentication method that isn’t tied to specific users, ensuring that your production workflows are even more efficient and secure.

SAST Support for .NET 6

Microsoft’s release of .NET 6.0 is the next major release of .NET Core, which contains both massive performance gains and new compute options, and should enable simplified .NET code. We have updated our .NET SAST analyzer, Security Code Scan, to support this new version, which is also now supported with our SAST language detection, allowing GitLab SAST to automatically detect .NET 6 projects. This change was part of a community contribution by @vasyl11 at Clay Solutions, who we thank for their efforts.

Due to backwards compatibility concerns, if you want to leverage this new .NET 6 SAST scanning, you will need to update your .gitlab-ci.yml file to pin to the new major version of Security Code Scan. You can add this code snippet to your .gitlab-ci.yml file to try these new scanning capabilities. In a future release, we will announce the upcoming deprecation and removal in GitLab 15.0 of any version of .NET before 3.0 for SAST scanning, due to its end of Life and last support date status with Microsoft. In GitLab 15.0, we will promote this new version of Security Code Scan to run by default, which will enable .NET 5 and 6 SAST scanning without the need for the experimental flag.

Support HTTPS proxy settings of RetireJS

Thanks to community contributor Ankur Sethi and their patience, Dependency Scanning now supports proxy settings in Retire.js by respecting the HTTPS_PROXY environment variable. If HTTPS_PROXY is set, it will be passed to the retire command line as a CLI option. Thank you!

Auto deletion of old deployment git references

As projects continue to be deployed, the number of deployments can increase substantially. To maintain high performance for Git commands, we have added automated deleting of Git references for old deployments. GitLab will keep the recent 50,000 deployments per project and automatically delete the Git references for the others.

Container Scanning results in the Dependency List

Security teams, compliance teams, and developers must have a complete picture of all dependencies used by a project. Container Scanning jobs now add any identified system dependencies to the dependency list by default. This list of system dependencies appears together with any application dependencies identified by a Dependency Scanning job. Users can now view this complete list of project dependencies in one centralized location on the Security & Compliance > Dependency List page.

Container Scanning results in the Dependency List

SAST scan execution policies

Users can now require SAST scans to run on a regular schedule or as part of project CI pipelines, independent of the .gitlab-ci.yml file’s contents. This allows security teams to separately manage these scan requirements without allowing developers to change the configuration. You can get started with security policies on the Security & Compliance > Policies page. To specify SAST scans, set the scan field to sast.

SAST scan execution policies

Geo verifies four additional data types

GitLab stores data such as uploads, LFS objects, Pages deployments, and external merge request diffs in the file system or object storage. Geo replicates these data to one or many secondary sites, either to improve the productivity of distributed teams or as part of a disaster recovery strategy. Geo now also automatically verifies the data integrity of replicated uploads, LFS objects, Pages deployments, and external MR diffs when stored in the file system. This ensures that they are not corrupted in transfer or at rest. If you’re using Geo as part of a disaster recovery strategy, this provides additional protection against data loss.

Omnibus improvements

  • GitLab 14.6 includes Mattermost 6.1, whose newest release includes a single view of recent mentions and saved posts across your teams, quick access to recently used reactions, timed do not disturb, Playbooks and Boards previews, Playbooks and Boards improved notifications and Boards calculations. This version also includes security updates and upgrade from earlier versions is recommended.
  • GitLab 14.6 ships with packages for Debian 11 Bullseye for both amd64 and arm64 architectures.

Bug fixes

Some of the notable bug fixes in 14.6 are:

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 users!

In GitLab 14.6, we’re shipping performance improvements for issues, projects, milestones, and much more! Some improvements in GitLab 14.6 are:

Usability improvements

In every release, we make great strides in improving the overall effectiveness and usefulness of our product.

We also have a UI Polish gallery to track important updates to our interfaces. These updates, while often small, improve your user experience.

In GitLab 14.6, we’re shipping usability improvements for issues, projects, milestones, and much more! We highlight the following changes in GitLab 14.6:

Deprecations

New deprecations and the complete list of all features that are currently deprecated can be viewed in the GitLab documentation.

Removals

Limit the number of triggered pipeline to 25K in free tier

A large amount of triggered pipelines in a single project impacts the performance of GitLab.com. In GitLab 14.6, we are limiting the number of triggered pipelines in a single project on GitLab.com at any given moment to 25,000. This change applies to projects in the free tier only, Premium and Ultimate are not affected by this change.

Removal date: Dec 22, 2021

Release CLI distributed as a generic package

The release-cli will be released as a generic package starting in GitLab 14.2. We will continue to deploy it as a binary to S3 until GitLab 14.5 and stop distributing it in S3 in GitLab 14.6.

Removal date: Dec 22, 2021

Important notes on upgrading to GitLab 14.6

  • GitLab 14.6 includes a feature flag (ci_destroy_all_expired_service) to stop removal of expired artifacts. This is Disabled by default which changes the current default behavior of the feature. This will be re-enabled in 14.7.
  • GitLab 14.6 includes all the migrations for Mattermost 6.0 as well as 6.1, and has longer migrations than typical for most Mattermost upgrades. Large instances should consult the upgrade documentation for both 6.0 and 6.1. The upgrade does not require any manual steps, but there are some suggestions in the upgrades notes on ways to reduce downtime of the Mattermost server during the upgrade.

Changelog

Please check out the changelog to see all the named changes:

Installing

If you are setting up a new GitLab installation please see the download GitLab page.

Updating

Check out our update page.

Questions?

We'd love to hear your thoughts! Visit the GitLab Forum GitLab Forum and let us know if you have questions about the release.

GitLab Subscription Plans

GitLab is available in self-managed and cloud SaaS options.

Self-managed: Deploy on-premises or on your favorite cloud platform.

  • Free: For small teams, personal projects, or GitLab trials with unlimited time.
  • Premium: For distributed teams who need advanced features, high availability, and 24/7 support.
  • Ultimate: For enterprises that want to align strategy and execution with enhanced security and compliance.

Cloud SaaS - GitLab.com: hosted, managed, and administered by GitLab with free and paid subscriptions for individuals and teams.

  • Free: Unlimited private repositories and unlimited collaborators on a project.
  • Premium: For teams that need more robust DevOps capabilities, compliance and faster support.
  • Ultimate: Great with many CI/CD jobs. Every public project gets the features of Ultimate for free irrespective of their plan.

Cover image licensed under Unsplash License

Try all GitLab features - free for 30 days

GitLab is more than just source code management or CI/CD. It is a full software development lifecycle & DevOps tool in a single application.

Try GitLab Free
Git is a trademark of Software Freedom Conservancy and our use of 'GitLab' is under license