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.
MVP
This month's Most Valuable Person (MVP) is awarded to
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! 🙌
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.
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.
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.
Note: This feature is defaulted to off for self-managed instances. To turn it on, enable the wiki_switch_between_content_editor_raw_markdown feature flag. In GitLab 14.8, self-managed instances will have this feature flag enabled by default.
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).
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.
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.
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.
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.
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.
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.
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.
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.
For users using the in-chart NGINX Ingress Controller, the new minimum version of Kubernetes is 1.19. This is a requirement towards GitLab supporting Kubernetes 1.22.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
In every release, we continue to make great strides improving GitLab’s performance. We’re committed to making every GitLab instance faster. This includes GitLab.com, an instance with over 1 million registered users!
In GitLab 14.6, we’re shipping performance improvements for issues, projects, milestones, and much more! Some improvements in GitLab 14.6 are:
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:
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.
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 a future milestone. For more details, follow this issue.
We want to hear from you
Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.
Share your feedback