The following features were added in this release.
In addition, we want to thank all of our contributors, including this month's notable contributor.
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.
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.
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!
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:
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.
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!
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.
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.
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.
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.
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.
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.
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!
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.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.
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!
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.
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.
object_attributes.type attribute available on payloads within the Issues events, Comments, Confidential issues events, and Emoji events triggers.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.
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.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.
During the 17.2 release milestone, we published the following updates.
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.During the 17.2 release milestone, we published the following updates:
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’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.
livenessProbe and readinessProbeumask 0000 command for the Kubernetes executorFor a list of all changes, see the GitLab Runner CHANGELOG.
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.