GitLab 17.2 released with log streaming, a new pipeline execution security policy, and vulnerability explanations now generally available
GitLab 17.2 released with log streaming, a new pipeline execution policy, vulnerability explanation now generally available and Duo Chat and Code Suggestions integrations in workspaces and much more!
To the wider GitLab community, thank you for the 160+ contributions you provided to GitLab 17.2!
At GitLab, everyone can contribute, and we couldn't have done it without you!
To preview what's coming in next month's release, check out our Upcoming Releases page, which includes our 17.3 release kickoff video.
Phawin Khongkhasawan is a Tech Lead at Jitta and started contributing
to GitLab in February of 2024.
In just a few months, Phawin has merged over 20 contributions and his contributions have also been
featured in 16.11,
17.0,
and 17.1.
“I really appreciate Phawin’s work, patience and perseverance on pushing the feature to Add order by merged_at
to the finish line,” says Patrick Bajao, Staff Backend Engineer at GitLab.
“It took a couple of milestones before it got merged and deployed, but he didn’t stop and he continued
to collaborate with us.”
A big thank you to Phawin for showing how new contributors can make an immediate impact and help
co-create GitLab.
In GitLab 16.1, we introduced the Kubernetes pod list and detail views. However, you still had to use third-party tools for an in-depth analysis of your workloads.
GitLab now ships with a log streaming view for pods and containers, so you can quickly check and troubleshoot issues across your environments without leaving your application delivery tool.
GitLab is now disabling AI input and output logging for GitLab Duo by default.
At GitLab, we aim to ensure that customers have sovereignty over their data.
We’ve now disabled input and output logging by default and will only log inputs and outputs with customers’ explicit
consent via a GitLab Support ticket.
When you perform a review, you can complete it by choosing whether to approve, comment, or request changes (released in GitLab 16.9). While reviewing, you might find changes that should prevent a merge request from merging until they’re resolved, and so you complete your review with request changes.
When requesting changes, GitLab now adds a merge check that prevents merging until the request for changes has been resolved. The request for changes can be resolved when the original user who requested changes re-reviews the merge request and subsequently approves the merge request. If the user who originally requested changes is unable to approve, the request for changes can be Bypassed by anyone with merge permissions, so development can continue.
Leave us feedback about this new feature in issue 455339.
Vulnerability Explanation is now a part of GitLab Duo Chat and is generally available. With Vulnerability Explanation, you can open chat from any SAST vulnerability to better understand the vulnerability, see how it could be exploited, and review a potential fix.
GitLab now supports the OAuth 2.0 device authorization grant flow. This flow makes it possible to securely authenticate your GitLab identity from input constrained devices where browser interactions are not an option.
This makes the device authorization grant flow ideal for users attempting to use GitLab services from headless servers or other devices with no, or limited, UI.
Thank you John Parent for your contribution!
The pipeline execution policy type is a new type of security policy that allows users to support enforcement of generic CI jobs, scripts, and instructions.
The pipeline execution policy has two modes: inject and override. The inject mode injects jobs into the project’s CI/CD pipeline. The override mode replaces the project’s CI/CD pipeline configuration.
We have expanded support of custom rulesets in pipeline secret detection.
You can use two new types of passthroughs, git and url, to configure remote rulesets. This makes it easier to manage workflows such as sharing ruleset configurations across multiple projects.
You can also extend the default configuration with a remote ruleset by using one of those new types of passthroughs.
The analyzer also now supports:
Chaining up to 20 passthroughs into a single configuration to replace predefined rules.
GitLab Duo Chat and Code Suggestions are now available in workspaces! Whether you’re seeking quick answers or efficient code improvements, Duo Chat and Code Suggestions are designed to boost productivity and streamline your workflow, making remote development in workspaces more efficient and effective than ever.
Previously, when using GitLab for Jira Cloud app, if you deleted a branch in GitLab, that branch still
appeared in Jira development panel. Selecting that branch caused a 404 error on GitLab.
From this release, branches deleted in GitLab are removed from the Jira development panel.
You can import projects to GitLab from other SCM solutions. However, it was difficult to know
if project items were imported or created on the GitLab instance.
With this release, we’ve added visual indicators to items imported from GitHub, Gitea, Bitbucket Server, and Bitbucket Cloud where the creator is identified as a specific
user. For example, merge requests, issues, and notes.
Issues, tasks, incidents, requirements, objectives, and key results
all trigger payloads under the Issues Events webhook category. Until now, there has been no way to quickly determine the type of object that triggered the webhook within the event payload. This release introduces an object_attributes.type attribute available on payloads within the Issues events, Comments, Confidential issues events, and Emoji events triggers.
In GitLab 17.2, wiki page titles are separate from their paths. In previous releases, if a page title changed, the path would also change, which could cause links to the page to break. Now, if a wiki page’s title changes, the path remains unchanged. Even if a wiki page path changes, an automatic redirect is set up to prevent broken links.
Crafting commit messages is an important part of ensuring that future users understand what and why changes were made to the codebase. It’s challenging to come up with a message that communicates your changes effectively and takes into account everything you might have changed.
Generation of merge commits with GitLab Duo is now Generally Available to help ensure every merge request has quality commit messages. Before you merge, select Edit commit message in the merge widget, then use the Generate commit message option to have a commit message drafted.
This new GitLab Duo capability is a great way to make sure your project’s commit history is a valuable resource for future developers.
Back in September 2021, git-lfs 3.0.0
released support for using SSH as the transfer protocol instead of HTTP.
Prior to git-lfs 3.0.0, HTTP was the only supported transfer protocol
which meant using git-lfs at GitLab was not possible for some users.
With this release, we’re very excited to offer the ability to
enable support for SSH over HTTP as the transfer protocol for git-lfs.
An accessible record of deployment events, like deployment approvals, is essential for compliance management. Until now, GitLab did not provide deployment-related audit events, so compliance managers had to use custom tooling or search for this data in GitLab directly. GitLab now provides three audit events:
deployment_started records who started a deployment job, and when it was started.
deployment_approved records who approved a deployment job, and when it was approved.
deployment_rejected records who rejected a deployment job, and when it was rejected.
API Security already has support for “overrides” which can modify the requests sent by the scanner. However these overrides must be set ahead of time and cannot change based on the request itself. GitLab 17.2 adds a “per-request script” (APISEC_PER_REQUEST_SCRIPT), which allows a user to provide a C# script that is called prior to sending each request. This provides support for “signing” the request with a secret as a form of authentication.
During the 17.2 release milestone, we published the following updates.
We added three new checks:
Check 506.1 is a passive check that identifies request URLs that are likely compromised by the Polyfill.io CDN takeover.
Check 384.1 is a passive check that identifies session fixation weaknesses, which could allow a valid session identifier to be reused by malicious actors.
Check 16.11 is an active check that identifies when the TRACE HTTP debugging method is enabled on a production server, which could inadvertently expose sensitive information.
We addressed the following bugs to reduce false positives:
DAST checks 614.1 (Sensitive cookie without Secure attribute) and 1004.1 (Sensitive cookie without HttpOnly attribute) no longer create findings when a site has cleared a cookie by setting an expiry date in the past.
DAST check 1336.1 (Server-Side Template Injection) no longer relies on a 500 HTTP response status code to determine attack success.
We added the following enhancements:
All response headers are now presented as evidence in a DAST vulnerability finding. This additional context reduces time spent on triaging findings.
Sitemap.xml files are now crawled for additional URLs, leading to better coverage of target websites.
Warnings for potential leaks in text content have been enriched with more detail, making it easier to understand which type of secret is about to be leaked in a description or comment in either an issue, epic, or MR.
Scan execution policies have been expanded to allow you to choose between default and latest GitLab templates when defining the policy rules. While default reflects the current behavior, you may update your policy to latest to use features available only in the latest template of the given security analyzer.
By utilizing the latest template, you may now ensure scans are enforced on merge request pipelines, along with any other rules enabled in the latest template. Previously this was limited to branch pipelines or a specified schedule.
Note: Be sure to review all changes between default and latest templates before modifying the policy to ensure this suits your needs!
The OAuth authorization screen now more clearly describes the authorization you are granting. It also includes a “verified by GitLab” section for applications that are provided by GitLab. Previously, the user experience was the same, regardless of whether an application was provided by GitLab or not. This new functionality provides an extra layer of trust.
The administrator setup experience for a new install of GitLab has been streamlined and made more secure. The initial administrator root email address is now randomzied, and administrators are forced to change this email address to an account that they can access. Previously, this step could have been delayed, and an administrator might forget to change the email address.
In GitLab 15.3 we introduced the compare_to keyword for rules:change. This made it possible to define the exact ref to compare against. Beginning in GitLab 17.2, you can now use CI/CD variables with this keyword, making it easier to define and reuse compare_to values in multiple jobs.
We added a new endpoint to the Groups API to list the groups a group has been invited to.
This functionality complements the endpoint to list the projects that a group has been invited to, so you can now get a complete overview of all the groups and projects that your group has been added to.
The endpoint is rate-limited to 60 requests per minute per user.
GitLab offers many settings across projects, groups, the instance, and for yourself personally. To find the setting you’re looking for, you often have to spend time clicking through many different areas of the UI.
With this release, you can now search for project settings from the command palette. Try it out by visiting a project, selecting Search or go to…, entering command mode with >, and typing the name of a settings section, like Protected tags. Select a result to jump right to the setting itself.
Discussions on GitLab issues can get busy. GitLab helps you manage these conversations by raising a to-do item for comments that are relevant to you, and automatically resolves the item when you take an action on the issue.
Previously, when you took action on a thread in the issue, all to-do items were resolved, even if you were mentioned in several different threads. Now, GitLab resolves only the to-do item for the thread you interacted with.
GitLab 17.2 adds several enhancements to how wikis display the sidebar. Now, a wiki displays all pages in the sidebar (up to 5000 pages), displays a table of contents (TOC), and provides a search bar to quickly find pages.
Previously, the sidebar lacked a TOC, making it challenging to navigate to sections of a page. The new TOC feature helps to see the page structure clearly, as well as navigate quickly to different sections, greatly improving usability.
The addition of a search bar makes discovering content easier. And because the sidebar now displays all pages, you can seamlessly browse an entire wiki.
GitLab Duo for the CLI is now generally available for all users. You can now ask GitLab Duo to help you with finding the right git command for your need.
Use glab duo ask <git question> to have GitLab Duo provide you with formatted git commands to achieve your goals. The GitLab CLI then provides additional details on the commands and what they will do, including information on any flags being passed. You’re then able to run the commands and get their output directly in your workflow.
The ask command for the GitLab CLI is a great way to speed up your workflow with git commands you need a little extra help remembering.
With this release, we’ve implemented a new authorization strategy for workspaces to address the limitations of the legacy strategy while providing group owners and administrators more control and flexibility. With the new authorization strategy, group owners and administrators can control which cluster agents to use for hosting workspaces.
To ensure a smooth transition, users on the legacy authorization strategy are migrated automatically to the new strategy. Existing agents that support workspaces are allowed automatically in the root group where these agents are located. This migration also occurs even if these agents have been allowed in different groups in a root group.
We’re releasing GitLab Runner 17.2 today! GitLab Runner is the lightweight, highly scalable agent that runs your CI/CD 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.
The Terraform module registry now displays Readme files! With this highly requested feature, you can transparently document the purpose, configuration, and requirements of each module.
Previously, you had to search other sources for this critical information, which made it difficult to properly evaluate and use modules. Now, with the module documentation readily available, you can quickly understand a module’s capabilities before you use it. This accessibility empowers you to confidently share and reuse Terraform code across your organization.
API Fuzzing already has support for “overrides” which can modify the requests sent by the scanner. However these overrides must be set ahead of time and cannot change based on the request itself. GitLab 17.2 adds a “per-request script” (FUZZAPI_PER_REQUEST_SCRIPT), which allows a user to provide a C# script that is called prior to sending each request. This provides support for “signing” the request with a secret as a form of authentication.
As a follow up to the Continuous Vulnerability Scanning for Container scanning MVC, during 17.2 we added support for APK and RPM operating system package versions.
This enhancement allows our analyzer to fully support Continuous Vulnerability Scans for Container Scanning advisories by comparing the package versions for APK and RPM operating system purl types.
As a note, RPM versions containing a caret (^) are not supported. Work to support these versions is being tracked in this issue.
GitLab Advanced SAST is now available as a Beta feature for Ultimate customers.
Advanced SAST uses cross-file, cross-function analysis to deliver higher-quality results.
It now supports Go, Java, and Python.
During the Beta phase, we recommend running Advanced SAST in test projects, not replacing existing SAST analyzers.
To enable Advanced SAST, see the instructions.
Starting in GitLab 17.2, Advanced SAST is included in the SAST.latest CI/CD template.
This is part of our iterative integration of Oxeye technology.
In upcoming releases, we plan to move Advanced SAST to General Availability, add support for other languages, and introduce new UI elements to trace how vulnerabilities flow.
We welcome any testing feedback in issue 466322.
The compliance center is the central location for compliance teams to
manage their compliance standards adherence reporting, violations reporting,
and compliance frameworks for their group.
Previously, all of the associated features of the compliance center were only available for top-level groups.
This meant that for subgroups, owners didn’t have access to any of the functionality provided by the compliance center on the top-level group.
To help address these key pain points, we’ve added the ability to assign and unassign compliance frameworks for subgroups. Now, group owners can
visualize their compliance posture at the subgroup level in addition to the full top-group-level compliance centre dashboard that was already available.
Administrators can now run a script that identifies dates when multiple access tokens expire. You can use this script in combination with other scripts on the token troubleshooting page to identify and extend large batches of tokens that might be approaching their expiration date, if token rotation has not yet been implemented.
Google Cloud CLI commands are now natively available when setting up workload identity federation for the Google Cloud IAM integration. Previously, the guided setup used a script downloaded through cURL commands. Also, help text has been added to better describe the setup process. These improvements help group owners set up the Google Cloud IAM integration more quickly.
In GitLab 17.2, we’ve added support for the Users API to the GitLab Data Connector,
which is available in the Snowflake Marketplace app. You can now stream user data from self-managed GitLab instances to Snowflake using the Users API.
We have updated the sorting and filtering functionality of the group overview page. The search element now stretches across the whole page, allowing you to see your search strings better. We have standardized the sorting options to Name, Created date, Updated date, and Stars.
We welcome feedback about these changes in issue 438322.
Bug fixes, performance improvements, and UI improvements
At GitLab, we’re dedicated to providing the best possible experience for our users. With every release, we work tirelessly to fix bugs, improve performance, and enhance UI. Whether you’re one of the over 1 million users on GitLab.com or using our platform elsewhere, we’re committed to making sure your time with us is smooth and seamless.
Click the links below to see all the bug fixes, performance enhancements, and UI improvements we’ve delivered in 17.2.
Starting with GitLab 17.2, Geo installations begin the primary site’s checksum process when the primary site is defined using the gitlab-ctl set-geo-primary-node command. Previously, the checksum process was started after a secondary site was configured. This means that you will see an increase in resource usage on the primary site a bit earlier in your Geo setup as the primary site begins generating checksums for data after the gitlab-ctl set-geo-primary-node command is run.
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