Audit event on webhook creation
Audit events make a record of important actions that are performed in GitLab. Until now, no audit event was created when a system, group, or
project webhook was added by a user.
In this release, we’ve added an audit event for when a user creates a system, group, or project webhook.
Re-import a chosen project relation by using the API
When importing projects from export files with many items of the same type (for example, merge requests or pipelines), sometimes some of those items aren’t imported.
In this release, we’ve added an API endpoint that re-imports a named relation, skipping items that have already been imported. The API requires both:
- A project export archive.
- A type. Either issues, merge requests, pipelines, or milestones.
Use REST API to cancel a running direct transfer migration
Until now cancelling a running direct transfer migration
required access to a Rails console.
In this release, we’ve added the ability for Administrators to cancel a migration by using the REST API.
Downscale pasted images on image upload
GitLab 17.1 enhances the handling of high-resolution images, enabling them to be downscaled during upload. Previously, images displayed in their original size, resulting in suboptimal display quality. This improvement ensures large images don’t break the visual flow of the pages they are included in.
Pages support for mutual TLS in GitLab API calls
GitLab can be configured to enforce client authentication with SSL certificates. However, the GitLab Pages service was incompatible with that feature, because it couldn’t be configured to use client certificates, and calls to the internal API were rejected.
From GitLab 17.1, you can configure a client certificate for GitLab Pages. This allows you to enable client authentication with the GitLab API, strengthening the security of your GitLab instance.
Redirect wiki pages to new URL when renamed
GitLab 17.1 introduces a significant enhancement to wiki page redirects. When you rename a wiki page, anyone trying to access the old page is automatically redirected to the new page, ensuring all existing links remain functional. This improvement streamlines the workflow for managing page name changes and enhances the overall knowledge management experience.
Understand an epic’s progress percentage
You can now easily see the overall progress of an epic based on the weight completion of its child items. This new progress rollup in the hierarchy widget makes it easier to understand the full scope of work for an epic and track progress as you go.
Disable diff previews in code review emails
When you review code in a merge request and comment on a line of code, GitLab includes a few lines of the diff in the email notification to participants. Some organizational policies treat email as a less secure system, or might not control their own infrastructure for email. This can present risks to IP or access control of source code.
New settings are available in groups and projects to enable organizations to remove diff previews from merge request emails. This can help ensure that sensitive information isn’t available outside of GitLab.
A gigantic thank you to Joe Snyder for contributing this!
GitLab Runner 17.1 released
Today we’re releasing GitLab Runner 17.1! 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:
The list of all changes is in the GitLab Runner change log.
Sort container registry tags by publish date
You use the GitLab container registry to view, push, and pull Docker or OCI images alongside your source code as well as pipelines. After a container image has been built, you often need to find and validate that it has been built correctly. For many customers, finding the correct container image using the user interface can be challenging.
You can now sort the container registry tags list by publish date. You can use this feature to quickly find and validate the most recently published container image.
This improvement is generally available only on GitLab.com. Self-managed support is in Beta because it requires the next-generation container registry, which is also in Beta. To learn more, see the container registry metadata database documentation.
API Security Testing analyzer updates
GitLab 17.1 adds the following configuration variables for API Security Testing:
APISEC_SUCCESS_STATUS_CODES creates a comma-separated list of HTTP success status codes that define whether an API security testing scanning job has passed.APISEC_TARGET_CHECK_DISABLED disables waiting for the target API to become available before scanning begins.APISEC_TARGET_CHECK_STATUS_CODE specifies the expected status code for the API target availability check. If not provided, any non-500 status code is acceptable to the scanner.
These new variables provide greater customization and flexibility to ensure scans run successfully.
DAST API was renamed API Security Testing in 16.10. Variable names now begin with the prefix APISEC. Previously, they began with DAST_API. Variables prefixed with DAST_API will be supported until 18.0 (May 2025). To ensure your configurations work as expected, you should update your variable names as soon as possible.
Fuzz Testing analyzer updates
GitLab 17.1 adds the following configuration variables for Fuzz Testing:
FUZZAPI_SUCCESS_STATUS_CODES creates a comma-separated list of HTTP success status codes that define whether a Fuzz Testing job has passed.FUZZAPI_TARGET_CHECK_SKIP disables waiting for the target API to become available before scanning begins.FUZZAPI_TARGET_CHECK_STATUS_CODE specifies the expected status code for the API target availability check. If not provided, any non-500 status code is acceptable to the scanner.
These new variables provide greater customization and flexibility for ensuring scans run.
Merge request approval policies fail open/closed (Policy editor)
Building on the previous iteration, we are introducing a new option within the policy editor allowing users to toggle security policies to fail open or fail closed. This enhancement extends the YAML support to allow for simpler configuration within the policy editor view.
For example, a merge request policy configured to fail open allows a merge request to merge if there is not enough evidence to evaluate the criteria. The lack of evidence might be because an analyzer is not enabled for the project, or the analyzer failed to produce results for the policy to evaluate. This approach allows for progressive rollout of policies as teams work to ensure proper scan execution and enforcement.
Project Owners receive expiring access token notifications
Both project Owners and Maintainers with direct membership now receive email notifications when their project access tokens are close to expiring. Previously, only project Maintainers received this notification. This helps keep more people informed about upcoming token expiration.
Thank you Jacob Henner for your contribution!
Add members by username with the Members API
Previously, when using the Members API, you could add members to groups and projects only by their user ID. With this release, you can now add members also by their username.
Thank you @imskr for this community contribution!
Filter projects by marked_for_deletion_on date with the Projects API
You can now filter responses in the Projects API using the attribute marked_for_deletion_on, which returns projects that were marked for deletion at a specific date.
Thank you @imskr for this community contribution!
List contributed projects of a user with GraphQL API
You can now use the new GraphQL API field User.contributedProjects to list the projects a user has contributed to.
Thank you @yasuk for this community contribution!
New %{latest_tag} placeholder for badges
You can now create badge links and image URLs using a %{latest_tag} placeholder. This placeholder references the latest tag that was published for a repository.
Thank you @TamsilAmani for this community contribution!
Keep inherited membership structure when importing by direct transfer
Until now, inherited memberships were not imported reliably when migrating
by direct transfer. This meant that inherited members of projects were imported as direct members.
From this release, GitLab now first migrates group membership before migrating project memberships. This replicates the inherited memberships on
the source GitLab instance.
Test group hooks with the REST API
Previously, you could test only project hooks with the REST API. With this release, you can also trigger test hooks for specified groups.
This endpoint has a special rate limit of three requests per minute per group hook. To disable this limit on self-managed GitLab and GitLab Dedicated, an administrator can disable the web_hook_test_api_endpoint_rate_limit feature flag.
Thanks to Phawin for this community contribution!
Draggable media in the rich text editor
Previously, moving media in the rich text editor required you to copy and paste each item manually. This often slowed down the inclusion of media in issues, epics, and wikis. In GitLab 17.1, you can now drag and drop media in the rich text editor, significantly enhancing efficiency during editing.
Real-time board updates for a smoother workflow
You’ll now notice a smoother experience when updating issues on boards! Changes you make in the sidebar will instantly appear on the board itself, no more refreshing required. This reactive boards experience streamlines your workflow, allowing you to quickly make updates while seeing them reflected in real-time.
Track time on tasks
With this release, you can now set time estimates and record time spent on tasks with a quick action or in the time tracking widget in the task’s sidebar. Time spent on a task can be viewed with the task’s time tracking report.
Updated Pages UI
In GitLab 17.1 we’ve improved the Pages user interface. Improvements include more efficient use of screen space. These UI improvements are focused on improving user experience and efficiency when managing Pages.
Enhanced control over who can override user-defined variables
To better control who can override user-defined variables, we are introducing the ci_pipeline_variables_minimum_role project setting. This new setting provides greater flexibility than the existing restrict_user_defined_variables setting. You can now restrict override permissions to no users, or only users with at least the Developer, Maintainer, or Owner roles.
Display the last published date for container images
Previously, the published timestamp was often incorrect in the container registry user interface. This meant that you couldn’t rely on this important data to find and validate your container images.
In GitLab 17.1, we’ve updated the UI to include accurate last_published_at timestamps. You can find this information by navigating to Deploy > Container Registry and selecting a tag to view more details. The last published date is available at the top of the page.
This improvement is generally available only on GitLab.com. Self-managed support is in beta and available only on instances that have enabled the beta next-generation container registry.
Show Release RSS icon on Releases page
Do you need to be notified when a new release is posted? GitLab now provides an RSS feed for releases. You can subscribe to a release feed with the RSS icon on the project release page.
Thanks to Martin Schurz for the contribution!
Container Scanning for Registry
GitLab Composition Analysis now supports Container Scanning for Registry.
If Container Scanning for Registry has been enabled on a project, and a container image is pushed to the container registry in your project, GitLab checks its tag and scan limit.
If the tag is latest, and the number of scans is under the limit (50 scans/day), then GitLab creates a new pipeline that runs a container_scanning job on the image. The pipeline is associated with the user who pushed the image to the registry.
The scan job generates a CycloneDX SBOM that is uploaded to GitLab. The Continuous Vulnerability Scanning features are activated and scan the packages detected in the SBOM.
Note: a vulnerability scan is only perfomed when a new advisory is published. This occurs when the package metadata is synchronized.
As always, we appreciate feedback on our newly released features. To provide feedback, please comment on this feedback issue.
Administrators can search users by partial email address
Administrators can now search users by partial email address in the User overview of the Admin Area. For instance, you can filter users by a specific email domain to find all users from a distinct institution. This feature is limited to administrators to prevent unprivileged users from accessing email addresses of other accounts.
Thanks @zzaakiirr for this community contribution!
New permissions for custom roles
In GitLab 17.1, you can create custom roles with the following new permissions:
With custom roles, you can reduce the number of users with the Owner role by creating users with equivalent permissions. This helps you define roles that are tailored specifically to the needs of your group, and prevents unnecessary privilege escalation.
Filter groups by marked_for_deletion_on date with the Groups API
You can now filter responses in the Groups API using the attribute marked_for_deletion_on, which returns groups that were marked for deletion at a specific date.
Thank you @imskr for this community contribution!
Improved visibility level selection
Previously, a group’s or project’s general settings displayed only permitted visibility levels. This view often confused users who tried to understand why the other options were not available, and could lead to information being displayed incorrectly. The new view shows all visibility levels, greying out the options that are not available for selection. In addition, a popover gives further context about why an option is not available. For example, a visibility level could be unavailable because an administrator restricted it, or it would cause a conflict with a project’s or parent group’s visibility setting.
We hope these changes help you resolve the conflicts in selecting your desired visibility option. Thank you @gerardo-navarro for this community contribution!
New GraphQL API argument markedForDeletionOn for groups and projects
You can now use the new GraphQL API argument markedForDeletionOn to list the groups or projects that were marked for deletion at a specific date.
Thank you @imskr for this community contribution!
New placeholders for group and project badges
You can now create badge links and image URLs using four new placeholders:
%{project_namespace} - referencing the full path of a project namespace%{group_name} - referencing the group name%{gitlab_server} - referencing the group’s or project’s server name%{gitlab_pages_domain} - referencing the group’s or project’s domain name
Thank you @TamsilAmani for this community contribution!
Updated sorting and filtering functionality in Explore
We have updated the sorting and filtering functionality of the group and project Explore pages. The filtering bar is now wider for better readability.
In the Explore page for projects, you can now use standardized sorting options that include Name, Created date, Updated date, and Stars, and a navigation element to sort in ascending or descending order. The language filter has moved to the filter menu. A new Inactive tab displays archived projects for a more focused search. Additionally, you can use a Role filter to search for projects you are the Owner of.
In the Explore page for groups, we have standardized the sorting options to include Name, Created date, and Updated date, and added a navigation element to sort in ascending or descending order.
We welcome feedback about these changes in issue 438322.
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