GitLab 17.2 Release

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!

Today, we are excited to announce the release of GitLab 17.2 with vulnerability explanations becoming generally available and integrated with GitLab Duo to help understand SAST vulnerabilities, log streaming support for Kubernetes to help troubleshoot workloads without leaving GitLab, a new pipeline execution security policy type to enforce the execution of CI/CD jobs in pipelines, Duo Chat and Code Suggestions support in GitLab workspaces for a productivity boost in the remote development environment, and much more! 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 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.

GitLab MVP badge

MVP This month's Most Valuable Person (MVP) is awarded to Phawin Khongkhasawan

Everyone can nominate GitLab’s community contributors! Show your support for our active candidates or add a new nomination! 🙌

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.

Phawin was first nominated by Magdalena Frankiewicz, Product Manager at GitLab, for improving Webhook related features like the request to Allow triggering of project test webhooks via the API. GitLab engineers Marc Shaw and Jose Ivan Vargas, and GitLab Product Manager Rutvik Shah, highlighted Phawin’s patience in collaboration and iteration, two of GitLab’s core values.

“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.

17.2 Key improvements released in GitLab 17.2

Log streaming for Kubernetes pods and containers

Log streaming for Kubernetes pods and containers

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.

Log streaming for Kubernetes pods and containers

Gitlab Duo disabling input and output logging by default.

Gitlab Duo disabling input and output logging by default.

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.

Gitlab Duo disabling input and output logging by default.

Block a merge request by requesting changes

Block a merge request by requesting changes

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.

Block a merge request by requesting changes

Vulnerability Explanation

Vulnerability Explanation

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.

Vulnerability Explanation

OAuth 2.0 device authorization grant support

OAuth 2.0 device authorization grant support

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!

Pipeline execution policy type

Pipeline execution policy type

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 type enables security and compliance teams to enforce customized GitLab security scanning templates, GitLab or partner-supported CI templates, 3rd party security scanning templates, custom reporting rules through CI jobs, or custom scripts/rules through GitLab CI.

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.

As with all GitLab policies, enforcement can be managed centrally by designated security and compliance team members who create and manage the policies. Learn how to get started by creating your first pipeline execution policy!

Pipeline execution policy type

Expanded support of custom rulesets in pipeline secret detection

Expanded support of custom rulesets in pipeline secret detection

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.
  • Including environment variables in passthroughs.
  • Setting a timeout when loading a passthrough.
  • Validating TOML syntax in ruleset configuration.
Expanded support of custom rulesets in pipeline secret detection

GitLab Duo Chat and Code Suggestions available in workspaces

GitLab Duo Chat and Code Suggestions available in workspaces

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.

GitLab Duo Chat and Code Suggestions available in workspaces

17.2 Other improvements in GitLab 17.2

Deleted branches are removed from Jira development panel

Deleted branches are removed from Jira development panel

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.

Indicate imported items in UI

Indicate imported items in UI

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.

Add type attribute to issues events webhook

Add type attribute to issues events webhook

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.

Separate wiki page title and path fields

Separate wiki page title and path fields

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.

Merge commit message generation now GA

Merge commit message generation now GA

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.

Pure SSH transfer protocol for LFS

Pure SSH transfer protocol for LFS

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.

Thank you to Kyle Edwards and Joe Snyder for this contribution!

Sort options for pipeline schedules

Sort options for pipeline schedules

You can now sort the pipeline schedules list by description, ref, next run, created date, and updated date.

Deployments and approvals to protected environments trigger an audit event

Deployments and approvals to protected environments trigger an audit event

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.

List groups that a group was invited to using the Groups API

List groups that a group was invited to using the Groups API

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.

Thank you @imskr for this community contribution!

API Security Testing now supports signed authentication requests

API Security Testing now supports signed authentication requests

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.

Container Scanning: Continuous Vulnerability Scanning OS support

Container Scanning: Continuous Vulnerability Scanning OS support

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.

Expand “Scan Execution Policies” to run latest templates for each GitLab analyzer

Expand “Scan Execution Policies” to run latest templates for each GitLab analyzer

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!

Expand "Scan Execution Policies" to run `latest` templates for each GitLab analyzer

Identify dates when multiple access tokens expire

Identify dates when multiple access tokens expire

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.

Secret push protection now available for Self-Managed, and improved warnings of potential leaks

Secret push protection now available for Self-Managed, and improved warnings of potential leaks

During the 17.2 release milestone, we published the following updates:

Streamlined instance administrator setup

Streamlined instance administrator setup

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.

Streamlined instance administrator setup

rules:changes:compare_to now supports CI/CD variables

rules:changes:compare_to now supports CI/CD variables

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.

Find project settings by using the command palette

Find project settings by using the command palette

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.

Find project settings by using the command palette

Resolve to-do items, one discussion at a time

Resolve to-do items, one discussion at a time

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.

Improvements to the wiki sidebar

Improvements to the wiki sidebar

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 now GA

GitLab Duo for the CLI now GA

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.

New agent authorization strategy for workspaces

New agent authorization strategy for workspaces

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.

GitLab Runner 17.2

GitLab Runner 17.2

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.

What’s new:

Bug Fixes:

For a list of all changes, see the GitLab Runner CHANGELOG.

Document modules in the Terraform module registry

Document modules in the Terraform module registry

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.

Improved sorting and filtering in group overview

Improved sorting and filtering in group overview

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.

API Fuzz Testing now supports signed authentication requests

API Fuzz Testing now supports signed authentication requests

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.

Assigning frameworks at subgroup compliance center

Assigning frameworks at subgroup compliance center

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.

DAST analyzer updates

DAST analyzer updates

During the 17.2 release milestone, we published the following updates.

  1. 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.
  1. 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.
  1. 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.

GitLab Advanced SAST available in Beta for Go, Java, and Python

GitLab Advanced SAST available in Beta for Go, Java, and Python

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.

OAuth authorization screen improvements

OAuth authorization screen improvements

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.

OAuth authorization screen improvements

Simplified setup for Google Cloud integration

Simplified setup for Google Cloud integration

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.

User API added to the Snowflake Data Connector

User API added to the Snowflake Data Connector

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.

Bug fixes, performance improvements, and UI improvements

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.

Deprecations Deprecations

New deprecations and the complete list of all features that are currently deprecated can be viewed in the GitLab documentation. To be notified of upcoming breaking changes, subscribe to our Breaking Changes RSS feed.

Removals and breaking changes Removals and breaking changes

The complete list of all removed features can be viewed in the GitLab documentation. To be notified of upcoming breaking changes, subscribe to our Breaking Changes RSS feed.

Important notes on upgrading to GitLab Important notes on upgrading to GitLab 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.


Changelog Changelog

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

Installing Installing

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

Updating Updating

Check out our update page.

Questions? Questions?

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

GitLab Subscription Plans GitLab Subscription Plans

  • Free

    Free-forever features for individual users

  • Premium

    Enhance team productivity and coordination

  • Ultimate

    Organization wide security, compliance, and planning

Try all GitLab features - free for 30 days

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

Take GitLab for a spin

See what your team could do with The DevSecOps Platform.

Get free trial

Have a question? We're here to help.

Talk to an expert
Edit this page View source