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.
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! 🙌
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
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!
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. 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.
- Spotbugs updated to v2.28.11 - MR, Changelog
- Updates Log4j library to patched version (v4.5.2). See blog post for more information
- Fix custom CA cert support
- PMD updated to v2.12.10 - MR, Changelog
- Proactive removal of Log4j library. See blog post for more information
- Semgrep updated to v0.76.2 - MR, Changelog
- Gosec updated to v2.9.5 - 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 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.
Unlink security policy projects
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.
GitLab chart improvements
- In GitLab 14.6, the bundled NGINX Ingress Controller has been upgraded to
v1.0.4. GitLab is working towards support for Kubernetes 1.22 and a requirement of that isv1.0.0or higher of nginx-ingress. - 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.
Bug fixes
Some of the notable bug fixes in 14.6 are:
- Original variables when running a manual job are not reused on job retry.
- user_failed_login webhook causes infinite loop when a blocked SAML user tries to login.
- Special characters not supported in Elasticsearch password.
- Fix occasional incorrect values for GITLAB_USER_LOGIN.
- Fix CI minutes usage chart showing time in reverse.
- Service Desk custom mailbox should check additional headers.
- Hide Dependency Proxy page when it is disabled for the group.
- Disable Upload Purger if the Container Registry started in read-only mode.
- Fix Container Registry push failures due to validation error.
- Fix panic if Container Registry database credentials are wrong.
- Sort months of the CI minutes chart app .
- Fix CI/CD settings available when CI/CD is off .
- Fix broken Segmented control in the pipeline page.
- Fix errors in coverage approval rule sync when either pipeline does not have a coverage report.
- Setting labels in issue board produces garbled results..
- Filter by iteration in MR search does not work.
- Creating an Issue on an Issue Board scoped to Iteration does not assign it to currently active Iteration.
- Issue export to CSV ignores negative label filter.
- YAML errors cause security policy to fail executing.
- Add vulnerability check fields to the API docs.
- Get release by tag name with $CI_JOB_TOKEN returns 404 Project Not Found.
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:
- Add “Last Activity” column to CSV export in /admin/users.
- Filter and display stale runners in the UI.
- Relocate the number of online runners text in toolbar.
- Version field overflow IP address at the runner’s admin page.
- Add space between columns in runner table.
- pages:deploy job has switched columns in job table.
- Provide link to the the failed pipelines from Analytics»CI/CD in projects.
- Update dependency proxy copy and labels.
- Align the upstream and downstream pipelines vertically in the mini pipeline graph.
- Packages list: update the pipeline metadata.
- Improved UX for bulk deleting container image tags.
- New setting for TTL for the dependency proxy.
- Fix resizing the file browser in merge requests.
- More than 13 text improvements in merge requests.
- Users want more information related to when a code search result was last modified.
- Address color contrast of code line numbers when highlighted.
- VSA: Create and Delete options should remain visible in VS dropdown.
- Allow user to set the rule name to be displayed in the MR widget.
- Vulnerability Report: Replace admin icon.
- Job running time always titled as “Elapsed time”
- Support not filters in Epics API
- Add parent_iid and parent link to Epics API
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 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 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.
from GitLab https://ift.tt/3jxQhRj #GitLab #DevSecOps
Comments
Post a Comment