GitLab 17.1 released with Model registry available in beta and multiple GitLab Duo Code Suggestions in VS Code
GitLab 17.1 released with Model registry available in beta, multiple GitLab Duo Code Suggestions in VS Code, Secret Push Protection available in beta, GitLab Runner Autoscaler is generally available, and much more!
These are just a few highlights from the 45+ improvements in this release. Read on to check out all of the great updates below.
To the wider GitLab community, thank you for the 340+ contributions you provided to GitLab 17.1!
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.2 release kickoff video.
Shubham Kumar completed 7 issues during 17.1
and has been consistently contributing to GitLab since 2021.
He has now reached over 50 merged contributions!
Shubham is a GitLab Hero and a former Google Summer of Code contributor.
Shubham was nominated by Christina Lohr, Senior Product Manager at GitLab.
“Shubham has helped with a lot of issues over the past weeks and months, specifically with closing gaps in our API offering,” says Christina.
“I cannot write release posts fast enough for all the additions that Shubham is pushing through!”
“The open-source community is amazing,” says Shubham.
“I am grateful for the opportunity and recognition, and I look forward to continuing my contributions to the GitLab platform.”
Joe Snyder was nominated by Kai Armstrong, Principal Product Manager at GitLab,
for building a much requested feature for restricting diffs from being included in emails.
This contribution took more than 10 merge requests going back to GitLab 15.3.
“This is a massive feature that’s taken many milestones, complicated migrations, and changes to the product to enable it’s support,” says Kai.
“Joe worked tirelessly with many maintainers and collaborators over the milestones to get this work done.”
Jocelyn Eillis, Product Manager at GitLab, supported Joe’s nomination
by highlighting additional work to fix a bug where nested variables in build:resource_group are not expanded.
“This bug had 23 upvotes in addition to documented customer demand in the issue itself,” says Jocelyn.
“The quick turnaround on reviewer feedback means we were able to get this into GitLab 17.1!”
This is Joe’s second GitLab MVP after previously being awarded in GitLab 16.6.
Joe is a Senior R&D Engineer at Kitware and has been contributing to GitLab since 2021.
GitLab now officially supports model registry in beta as a first-class concept. You can add and edit models directly via the UI, or use the MLflow integration to use GitLab as a model registry backend.
A model registry is a hub that helps data science teams manage machine learning models and their related metadata. It serves as a centralized location for organizations to store, version, document, and discover trained machine learning models. It ensures better collaboration, reproducibility, and governance over the entire model lifecycle.
We think of the model registry as a cornerstone concept that enables teams to collaborate, deploy, monitor, and continuously train models, and are very interested in your feedback. Please feel free to drop us a note in our feedback issue and we’ll get back in touch!
GitLab Duo Code Suggestions in VS Code will now show you if there are multiple suggestions available. Simply hover over the suggestion and use the arrows or keyboard shortcut to cycle through the suggestions.
If a secret, like a key or an API token, is accidentally committed to a Git repository, anyone with repository access can impersonate the user of the secret for malicious purposes. To address this risk, most organizations require exposed secrets to be revoked and replaced, but you can save remediation time and reduce risk by preventing secrets from being pushed in the first place.
Secret push protection checks the content of each commit pushed to GitLab. If any secrets are detected, the push is blocked and displays information about the commit, including:
The commit ID that contains the secret.
The filename and line number that contains the secret.
The type of secret.
Need to bypass secret push protection for testing? When you skip secret push detection, GitLab logs an audit event so you can investigate.
Secret push protection is available on GitLab.com and for Dedicated customers as a Beta feature and can be enabled on a per project basis. You can help us improve secret push protection by providing feedback in issue 467408.
In earlier versions of GitLab, some customers needed an autoscaling solution for GitLab Runner on virtual machine instances on public cloud platforms. These customers had to rely on the legacy Docker Machine executor or custom solutions stitched together by using cloud provider technologies.
Today, we’re pleased to announce the general availability of the GitLab Runner Autoscaler. The GitLab Runner Autoscaler is composed of GitLab-developed taskscaler and fleeting technologies and the cloud provider plugin for Google Compute Engine.
Audit events are created and stored in GitLab. Before this release, audit events could only be accessed from in GitLab, with results reviewed using the GitLab UI or set a streaming destination to receive all audit events as structured JSON.
However, customers also wanted the ability to have audit events in third-party destinations (such as SIEM solutions like Snowflake) to make it easier to:
See, combine, manipulate, and report on all of the audit event data from an organization’s multiple systems, including GitLab.
Look only at specific audit events that they care about so that they can quickly answer the questions they are interested in.
Have a full picture of what goes on inside GitLab, and be able to review it after the fact.
To help customers with these tasks, we have created a GitLab connector application for the Snowflake Marketplace, which uses the Audit events API.
To make use of this functionality, customers must deploy and manage the application using the Snowflake Marketplace.
The wiki feature in GitLab 17.1 provides a more unified and efficient workflow:
Easier and quicker cloning with a new repository clone button. This improves collaboration, and speeds up access to the wiki content for editing or viewing.
A more obvious delete option in a more discoverable location. This reduces the time spent searching for it, and minimizes potential errors or confusion when managing wiki pages.
Allowing empty pages to be valid, improving flexibility. Create empty placeholders when you need them. Focus on better planning and organization of wiki content, and fill in the empty pages later.
These enhancements improve ease of use, discoverability, and content management in your wiki’s workflow. We want your wiki experience to be efficient and user-friendly. By making cloning repositories more accessible, relocating key options for better visibility, and allowing for the creation of empty placeholders, we’re refining our platform to better meet your users’ needs.
With the addition of the new Reports Generation Tool for Value Stream Management, we empower decision-makers to be more efficient and effective in the software development life cycle (SDLC) optimization.
You can now schedule DevSecOps comparison metrics reports or the AI Impact analytics report to be delivered automatically, proactively, and with relevant information in GitLab issues. With scheduled reports, managers can focus on analyzing insights and making informed decisions, rather than spending time manually searching for the right dashboard with the required data.
You can access the scheduled reports tool using the CI/CD Catalog.
The GitLab container registry now associates signed container images with their signatures. With this improvement, users can more easily:
Identify which images are signed and which are not.
Find and validate the signatures that are associated with a container image.
This improvement is generally available only on GitLab.com. Self-managed support is in beta and requires users to enable the
next-generation container registry, which is also in beta.
Manual jobs can be used to trigger highly critical operations in your CI pipeline, such as deploying to production. With this release, you can now configure a manual job to require confirmation before it runs. Use manual_confirmation with when: manual to display a confirmation dialog in the UI when a job is run manually. Requiring confirmation for manual jobs provides an additional layer of security and control.
Special thanks to Phawin for this community contribution!
Operators of self-managed runner fleets at the group level need observability and the ability to quickly answer critical questions about their runner fleet infrastructure at a glance. With the runner fleet dashboard for groups, you directly have runner fleet observability and actionable insights in the GitLab UI. You can now quickly determine the runner health, and gain insights into runner usage metrics as well as CI/CD job queue service capabilities, in your organization’s target service-level objectives.
Customers on GitLab.com can use all of the fleet dashboard metrics available for groups today. Self-managed customers can use most of the fleet dashboard metrics, but must configure the ClickHouse analytics database to use the Runner usage and Wait time to pick a job metrics.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
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!
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 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!
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.
The gitlab-backup tool now supports backing up external merge request diffs stored on local disk. Note, the gitlab-backup tool does not backup files stored on object storage. Therefore, if external merge diffs are stored on object storage they will need to be backed up manually.
The backup-utility for Cloud Native Hybrid environments already supported backing up external merge request diffs and this functionality remains unchanged.
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.
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.
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!
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.
Stacked diff workflows are a way of creating small changes that build upon each other to ultimately deliver a feature. These workflows can be used to accelerate development time by continuing to build upon your changes, while earlier changes in the stack are reviewed and updated based on feedback.
The 1.42.0 release of the GitLab CLI introduces a new stack command, which enables you to create and manage a stack of changes. After you’ve created your stack, you can continue to make changes, sync those changes, navigate to different changes within the stack, and amend previous changes.
Stacked diffs are managed completely in the GitLab CLI, so you can start using them as soon as you install the latest version of the CLI. You can watch this video to see the new stack command in action and learn more about how the feature works.
Feedback on stacked diffs via the GitLab CLI can be left in issue 7473.
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.1.
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