GitLab 17.5 released with Duo Quick Chat AI code assistance.
GitLab 17.5 released with code assistance in IDEs from GitLab Duo Quick Chat, self-hosted models for GitLab Duo Code Suggestions, export code suggestion usage events, MR conversations with GitLab Duo Chat and much more!
These are just a few highlights from the 125+ improvements in this release. Read on to check out all of the great updates below.
To the wider GitLab community, thank you for the 200 contributions you provided to GitLab 17.5!
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.6 release kickoff video.
Jim was recognized for leading an effort to close nearly 100 backlog issues
on GitLab.
He is active in many of our weekly community pairing sessions that dive into some interesting discussions.
Jim also supports people across the GitLab Community Discord,
troubleshooting GitLab support requests and guiding new contributors.
Jim works for an industrial technology company writing software for Critical Infrastructure and ERP systems.
“Even small contributions add up to make projects better,” says Jim.
“Something as small as documentation contributions helps others out. You don’t have to champion a full new feature.”
Jim was nominated by Lee Tickett, Staff FullStack Engineer, Contributor Success at GitLab.
“Issue triage/curation has been toward the top of my list to get the wider community involved in and Jim is paving the way here,” says Lee.
Daniel Murphy, Senior Program Manager, Contributor Success at GitLab, added to the nomination.
“Jim’s outstanding support for new contributors and guidance in getting them started helps us grow as a community to co-create GitLab.”
“Impressive work on the merge request I reviewed!” says Vanessa Otto, Senior Frontend Engineer at GitLab.
“Jim responded quickly, understood the suggestions immediately, and implemented them seamlessly.
It was great to see such efficiency and clarity in Jim’s approach.”
We are so grateful to Jim and all of our open source community for contributing to GitLab!
Introducing Duo Quick Chat, an AI-powered chat designed to work exactly where you are in your code. Duo Quick Chat operates directly on the lines you’re editing, offering real-time assistance without ever moving you away from your code. Whether you’re refactoring, fixing bugs, or writing tests, Duo Quick Chat provides suggestions and explanations on the spot, ensuring that you stay fully focused without switching context.
You can now host selected large language models (LLMs) in your own infrastructure and configure those models as the source for Code Suggestions. This feature is in beta and available with an Ultimate and Duo Enterprise subscription on self-managed GitLab environments.
With self-hosted models, you can use models hosted either on-premise or in a private cloud to enable GitLab Duo Code Suggestions. We currently support open-source Mistral models on vLLM or AWS Bedrock. By enabling self-hosted models, you can leverage the power of generative AI while maintaining complete data sovereignty and privacy.
Previously, AI impact analytics were available only on GitLab.com to GitLab Duo Enterprise customers, and on GitLab self-managed with a ClickHouse integration. Additionally, the default metrics were aggregated.
Now, you can export raw code suggestion events from the GraphQL API. This way you can import the data into your data analysis tool to get deeper insights into acceptance rates across more dimensions, such as suggestion size, language, and user. The raw events are not stored in ClickHouse, so some AI Impact Analytics metrics become available to all GitLab deployments, including GitLab Dedicated and self-managed.
In response to your feedback, GitLab Duo Chat is now aware of merge requests. Whether you are a reviewer or an author, you can now converse with Chat about a merge request to quickly dig into it, or learn what to do next. Simply open your merge request and open Duo Chat, then start the conversation.
This new feature complements our existing feature, where you can quickly populate the description of a merge request by asking GitLab Duo to summarize code changes, so that reviewers can get a general understanding of what the merge request is about.
Building on this feature, you can now directly modify specific branch rules in this view, including branch protections, approval rules, and external status check configurations. These new capabilities lay the foundation for continued improvements in branch configuration that will allow for greater flexibility in the future.
We encourage you to explore these new capabilities and to provide feedback. You can do this by contributing to our dedicated feedback issue.
Switchboard’s new Tenant Overview now provides a single place to quickly access essential information about your GitLab Dedicated instance.
With this first release, you can now view your current GitLab version, instance URL, and the date and time of your upcoming and past maintenance windows all on the Tenant Overview page.
We’re excited to announce that Secret Push Protection is now generally available for all GitLab Ultimate customers.
If a secret, like a key or an API token, is accidentally committed to a Git repository, anyone with access to the repository can impersonate the user of the secret for malicious purposes. A leaked secret costs time and money, and potentially damages a company’s reputation. Secret push protection helps reduce the remediation time and reduce risk by protecting secrets from being pushed in the first place.
Secret push protection has been improved since the beta release. When commits are pushed by using the Git CLI, now only the changes (diff) are scanned for secrets. We’ve also added experimental support for excluding paths, rules, or specific values to avoid false positives.
The Credentials Inventory is now available for top-level group Owners on GitLab.com. In the Credentials Inventory, you can view your enterprise user’s personal access tokens and SSH keys across your group. You can also revoke, delete, and view additional information about the credentials. Previously, this was only available for administrators on GitLab self-managed.
Group Owners can use the Credentials Inventory to understand the credentials that exist in their purview, and provide increased visibility and control.
Now, in GitLab, you can filter for specific dependency components quickly to identify whether or not they are used in your group or project.
It is time consuming and inconvenient to manually go through the entire list just to verify whether or not a particular package and version is present.
With the new filter by component on the dependency list, you isolate vulnerable dependencies so that you can assess open risks in your application.
Empower your development workflow with Duo Chat, now seamlessly integrated into Visual Studio for Windows. Duo Chat enhances your coding experience by providing AI-powered capabilities to explain, refine, debug code, or write tests all in real-time. This integration allows you to leverage Duo Chat’s advanced AI tools directly within your familiar development environment, improving productivity and enabling faster, more efficient problem-solving.
We’re excited to announce a significant improvement to our Container Registry API for self-managed GitLab instances. With the release of GitLab 17.5, we’ve implemented keyset pagination for the :id/registry/repositories/:repository_id/tags endpoint, bringing it in line with the functionality already available on GitLab.com. This enhancement is part of our ongoing efforts to improve API performance and provide a consistent experience across all GitLab deployments.
Keyset pagination offers a more efficient method for handling large datasets, resulting in improved performance and a better user experience. This update is particularly useful when managing large container registries, as it allows for smoother navigation through repository tags. In order to use this feature, self-managed instances must upgrade to the next-generation container registry.
You can check the status of your pods and Flux reconciliation from the GitLab environments UI.
However, this approach is hard to scale because the required settings are exposed only through GraphQL or the UI.
Now, GitLab ships with REST API support for configuring an agent for Kubernetes, as well as setting the namespace and Flux resource per environment.
To further improve support for dynamic environments, issue 467912 proposes adding support for configuring these settings in CI/CD pipelines.
Until now, the agent for Kubernetes could be used only if the Kubernetes cluster could connect to the GitLab instance.
This issue meant that some customers couldn’t use the agent if, for example, they ran GitLab on a private network or behind a firewall.
From GitLab 17.5, you can initiate the cluster-GitLab connection from GitLab, assuming that a properly configured agentk instance is already waiting for a connection initialization.
Once the initial connection is established, all the features of the agent are available. Initializing from a cluster is not changed with this development.
As a Flux user, have you ever needed to quickly stop an automatic reconciliation or drift remediation? Have you wanted to trigger a HelmRelease to synchronize manually removed resources? These actions are best achieved with the Flux suspend and resume functions. Until now, your best option was to use the Flux CLI, which required a context switch and several commands to ensure the right resource was affected. In GitLab 17.5, you can suspend or resume a reconciliation from the built-in dashboard for Kubernetes.
Previously, the compliance center was available only for top-level groups and subgroups.
With this release, we’ve added the compliance center to projects. At this level, compliance center provides
view-only capabilities for checks and violations that pertain to a particular project.
To add or edit a framework, you should access the compliance center on top-level groups instead.
Enterprise users can authenticate using a local account with username and password. Now, group Owners can disable password authentication for the group’s enterprise users. If password authentication is disabled, enterprise users can use either the group’s SAML identity provider to authenticate with GitLab web UI, or a personal access token to authenticate with GitLab API and Git using HTTP Basic Authentication.
In GitLab 17.3, we announced the deprecation of compliance pipelines and its eventual removal by the 18.0 release.
Instead of compliance pipelines, you should use the pipeline execution policy type instead, which was released in GitLab 17.2.
To help you migrate your existing compliance pipelines over to the pipeline execution policy type, this release includes a
warning banner that:
Notifies users about the deprecation of compliance pipelines.
Provides a prompted and guided workflow to migrate existing compliance pipelines to the pipeline execution policy type.
You can now view which groups, subgroups, and projects a token is associated with. This makes it easier to determine the impact of token expirations or revocations, and to understand where a token is able to be used.
GitLab 17.5 includes an update to our version of the NGINX Ingress Controller. The nginx-controller container image is now version 1.11.2. Please
note this includes new RBAC requirements because the new controller now uses endpointslices and requires an RBAC rule to access them.
GitLab 17.5 includes support for upgrading PostgreSQL from version 14.x to 16.x for single node installations. Automatic upgrades are not enabled and
so PostgreSQL upgrades must be triggered manually.
We’re also releasing GitLab Runner 17.5 today! GitLab Runner is the highly-scalable build 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.
We’re thrilled to introduce support for protected npm packages, a new feature designed to enhance the security and stability of your GitLab package registry. In the fast-paced world of software development, accidental modification or deletion of packages can disrupt entire development processes. Protected packages address this issue by allowing you to safeguard your most important dependencies against unintended changes.
From GitLab 17.5, you can protect npm packages by creating protection rules. If a package is matched by a protection rule, only specified users can update or delete the package. With this feature, you can prevent accidental changes, improve compliance with regulatory requirements, and streamline your workflows by reducing the need for manual oversight.
GitLab offers flexible, reliable, and secure GitOps support with the agent for Kubernetes and its Flux integration.
Still, bootstrapping Flux with GitLab and setting up the agent for Kubernetes used to require a lot of documentation reading and switching between the GitLab UI and the terminal.
The GitLab CLI now offers the glab cluster agent bootstrap command to simplify installing the agent on top of an existing Flux installation.
Now, you can configure Flux and the agent with just two simple commands.
GitLab provides a real-time view of your pods, as well as pod log streaming, all through the dashboard for Kubernetes.
In GitLab 17.4, we offered a static listing of resource-specific event information from the UI.
This release further improves the dashboard for Kubernetes by letting you stream incoming events as they emerge in the cluster.
We’ve added Ruby support to GitLab Advanced SAST.
To use this new cross-file, cross-function scanning support, enable Advanced SAST.
If you’ve already enabled Advanced SAST, Ruby support is automatically activated.
You can now target groups/subgroups in security policy scopes. This extends the existing options allowing you to target all projects in a group/subgroup, projects based on a defined project list, and projects matching a list of compliance framework labels.
This gives you further flexibility in enabling policies across your groups, while also being able to apply exceptions to scope projects out of enforcement where necessary.
This improvement also precedes a number of enhancements that will simplify the process of linking security policy projects and granularly scoping enforcement of policies.
Administrators now have an enhanced, summarized view of the following critical pieces of information about the users on their instance:
Pending approval.
Without two-factor authentication.
Administrators.
This increases user management efficiency, because administrators can quickly see how many users are in these states from the summary view, and filter on them.
Previously, when SAML SSO was enabled, groups could choose to enforce SSO, which required all members to use SSO
authentication to access the group. However, some groups want the security of SSO enforcement for employees or
group members, while still allowing outside collaborators or contractors to access their groups without SSO.
Now, groups with SAML SSO enabled have SSO automatically enforced for all members
who have a SAML identity. Group members without SAML identities are not required to
use SSO unless SSO enforcement is explicitly enabled.
A member has a SAML identity if one or both of the following are true:
They signed in to GitLab using their GitLab group’s single sign-on URL.
They were provisioned by SCIM.
To ensure smooth operation of the selective SSO enforcement feature, ensure your SAML configuration is
working properly before selecting the Enable SAML authentication for this group checkbox.
Composition Analysis has released support for static reachability for Java and Python.
Static reachability enriches software composition analysis (SCA) results. Powered by GitLab Advanced SAST, static reachability scans project source code to identify which open source dependencies are in use.
You can use the data produced by static reachability as part of your triage and remediation decision making. Static reachability data can also be used with CVSS scores to provide a more focused view of your vulnerabilities.
This feature is an experiment. To enable it, set the STATIC_REACHABILITY_ENABLED variable in your .gitlab-ci.yml file, or in the project variables. Learn more about this feature in the walk-through video.
We welcome feedback on this feature. If you have questions, comments, or would like to engage with our team please see this feedback issue.
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.5.
GitLab 17.5 includes a new version (1.11.2) of the NGINX controller container image. The new controller uses endpointslices and requires an RBAC
rule to access them. Please configure the new container image before upgrading.
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