GitLab 17.10 release notes

Maintaining context across different topics in GitLab Duo Chat is now easier with multiple conversations. You can create new conversations, browse your conversation history, and switch between conversations.

Previously, starting a new conversation meant losing the context of your existing chat. Now, you can manage multiple conversations on different topics. Each conversation maintains its own context, so for example, you can ask follow-up questions about code explanations in one conversation, whilst preparing a work-plan in another conversation.

When you need to revisit previous discussions, select the new chat history icon to see all your recent conversations. Conversations are automatically organized by most recent activity, making it easy to pick up where you left off.

For your privacy, conversations with no activity for 30 days are automatically deleted, and you can manually delete any conversation at any time.

This feature is currently available only on GitLab.com in the web UI. It is not available in GitLab Self-Managed instances, nor in IDE integrations.

Share your experience with us in issue 526013.

On GitLab Duo Self-Hosted, you can now select individual supported models for each GitLab Duo Chat sub-feature on your self-managed instance. Model selection and configuration for Chat sub-features is now in beta.

To leave feedback, go to issue 524175.

You can now use the AI Impact Dashboard with GitLab Duo Self-Hosted Code Suggestions on your self-managed instance to help you understand the impact of GitLab Duo on your productivity. The AI Impact Dashboard is in beta with GitLab Duo Self-Hosted, and you can use this feature with your self-managed instance and Visual Studio Code, Microsoft Visual Studio, JetBrains, and Neovim IDEs.

Use the AI Impact Dashboard to compare AI usage trends with metrics like lead time, cycle time, DORA, and vulnerabilities. This allows you to measure how much time is saved in your end-to-end workstream using GitLab Duo Self-Hosted, whilst staying focused on business outcomes rather than developer activity.

Please leave feedback on the AI Impact Dashboard in issue 456105.

You can now use select Meta Llama 3 models with GitLab Duo Self-Hosted. These models are in beta for GitLab Duo Self-Hosted to support GitLab Duo Chat and Code Suggestions.

Please leave feedback on using these models with GitLab Duo Self-Hosted in issue 523912.

With this release, user contribution mapping now supports bulk reassignment by using a CSV file. If you have a large user base with many placeholder users, group members with the Owner role can:

1. Download a prefilled CSV template.
2. Add GitLab usernames or public emails from the destination instance.
3. Upload the completed file to reassign all contributions at once.

This method eliminates tedious manual reassignment through the UI. To further streamline large-scale migrations, API support for CSV-based reassignment is now also available.

We’re excited to announce significant improvements to the project overview in Your Work, designed to streamline how you discover and access your projects. This update introduces a more intuitive tab-based navigation system that better reflects how users interact with their projects.

• The new Contributed tab (previously Yours) now displays all projects you’ve contributed to, including your personal projects, making it easier to track your development activity.
• Find your individual projects faster with the Personal tab, now prominently featured in the main navigation.
• Access team projects through the Member tab (formerly All), showing all projects where you have membership.
• The Inactive tab (previously Pending deletion) now provides a comprehensive view of both archived projects and those pending deletion.

Further, if you have the appropriate permissions, you can now edit or delete a project directly from the Your Work projects overview. These changes reflect our commitment to creating a more efficient and user-friendly GitLab experience. The new layout helps you focus on the projects that matter most to your work, reducing the time spent navigating between different project categories.

We value your feedback on this update! Join the discussion in epic 16662 to share your experience with the new navigation system.

We’ve improved the project creation permission settings to make them more clear, intuitive, and aligned with our security principles. The improved settings include:

• Renamed the “Default project creation protection” dropdown to “Minimum role required for project creation” to clearly reflect the setting’s purpose.
• Renamed the “Developers + Maintainers” dropdown option to “Developers” for consistency across the platform.
• Reordered the dropdown options from most restrictive to least restrictive access level.

These changes make it easier to understand and configure which roles can create projects within your groups, helping administrators enforce appropriate access controls more confidently.

Thank you @yasuk for this community contribution!

Dependency Scanning has added support for pub, the official package manager for Dart. Support for this has been added to our Dependency Scanning latest template and CI/CD component.

This addition was a community contribution from one of our users, Alexandre Laroche. The GitLab Composition Analysis team appreciates this contribution to improve our product, many thanks, Alexandre. If you are interested in learning more about contributing to GitLab please check out our Community Contribution program.

Users can set a default compliance framework in the GitLab compliance centre, which is applied to all new and imported projects that are created in that group. A default compliance framework has a default label to help users identify it.

To make it easier to set a compliance framework as default, we are introducing the ability for users to set a framework as default by using the framework dropdown list on the list frameworks page in the compliance center of a top-level group. This feature isn’t available in the compliance center of subgroups nor projects.

When browsing the history of a repository, there might be commits that aren’t relevant to otherwise meaningful changes in the project. This can happen during:

• Refactors where you change from one library to another without changing functionality.
• Implementation of code formatters or linters that require standardizing the entire codebase.

When you look through the history of a project with blame, these kinds of commits make it difficult to understand the changes that occurred. Git supports identifying these commits with a .git-blame-ignore-revs file in your project. GitLab now allows you to toggle the blame view to show or hide these specific revisions in the “Blame preferences” dropdown list, making it easier to understand the history of your project.

When teams configure a CODEOWNERS file, it’s common to include broad matching patterns for paths and file types. These broad configurations can be problematic if your documentation, automated build files, or other patterns don’t require a specified Code Owner.

You can now configure the CODEOWNERS file with path exclusions to ignore certain paths. This is helpful when you want to exclude specific files, or paths from requiring a Code Owner approval.

Different Git workflows require different strategies for handling commits when merging between branches. In previous versions of GitLab, you could only set a single strategy for whether commits should be squashed when merging and how strongly that should be enforced. This setup could be error-prone or require developers to make specific choices to follow the project convention for different branch targets.

You can now configure squash settings for each protected branch through branch rules. For example, you can:

• Require squashing when merging from your feature branch to the develop branch to keep history clean.
• Disable squashing when merging from the develop branch to main branch when you want the commit history to remain intact.

This flexibility ensures consistent commit history across your project while respecting the unique needs of each branch in your workflow, all without requiring manual developer intervention.

To strengthen your control over pipeline execution, jobs enforced in the .pipeline-policy-pre reserved stage are now required to complete before jobs in subsequent stages can begin, regardless of whether the job defines any needs statements. Previously, jobs defined in the .pipeline-policy-pre stage and jobs in subsequent pipelines with a needs statement both started as soon as the pipeline executed. With this enhancement, jobs in subsequent stages must wait for the .pipeline-policy-pre to complete before starting any other jobs without dependencies, helping you enforce ordered execution and ensuring compliance within the security policies.

Our customers rely on reserved stages to enforce compliance and security checks before developer jobs run. A common use case is to enforce a security or compliance check that fails the entire pipeline if the check does not pass. Allowing jobs to run out of order could bypass this enforcement and weaken policy intent. This improvement provides you with a more consistent approach to compliance enforcement.

To inject jobs at the beginning of the pipeline without overriding needs behavior, configure the jobs to use a custom stage with the new custom stages feature that we introduced in 17.9.

You can now authenticate to private GitLab Pages sites programmatically using access tokens, making it easier to automate interactions with your Pages content. Previously, accessing restricted Pages sites required interactive authentication through the GitLab UI.

This powerful enhancement increases productivity while maintaining security, giving developers more flexibility in how they interact with and distribute private Pages content.

The GitLab Dependency Proxy for container images now supports authentication with Docker Hub, helping you avoid pipeline failures due to rate limits and giving you access to private images.

Starting April 1, 2025, Docker Hub will enforce stricter pull limits (100 per 6-hour window per IPv4 address or IPv6 /64 subnet) for unauthenticated users. Without authentication, your pipelines might fail once these limits are reached.

With this release, you can configure Docker Hub authentication through the GraphQL API using your Docker Hub credentials, personal access token, or organization access tokens. Support for UI configuration will be available in GitLab 17.11.

Package registry operations are now logged as audit events so teams can track when packages are published or deleted to meet compliance requirements.

Before this release, there was no built-in way to track who published or made changes to packages. Teams had to create their own tracking systems or manually document package changes to maintain logs of these activities. Now, each audit event shows who made a change, when it happened, how they were authenticated, and exactly what changed in the package.

Audit events for projects are stored either in a group namespace or the project itself for individual project Owners. Groups can turn off audit events to manage storage needs.

GitLab administrators can now use a unified API to identify and revoke tokens. Previously, administrators had to use endpoints related to the specific type of token. This API allows revocation regardless of the type. For a list of supported token types, see the Token information API.

Thank you Nicholas Wittstruck and the team from Siemens for your contribution!

When using GitLab as an OpenID Connect (OIDC) provider, you can now configure the duration of ID tokens with the id_token_expiration attribute. Previously, ID tokens had a fixed expiration time of 120 seconds.

Thank you Henry Sachs for your contribution!

We’re also releasing GitLab Runner 17.10 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.

What’s new:

• Perform Autoscaler executor health check before instance usage
• Expand Docker executor volumes
• Add Docker excecutor configuration for device addition for services

Bug Fixes:

• The Windows gitlab-runner-helper image fails due to invalid volume specification for the `/opt/step-runner’ path
• Repository mirroring for RPM packages is not working properly in GitLab Runner 17.7.0 and later
• Running git submodule update --remote in GitLab CI/CD returns an error

The list of all changes is in the GitLab Runner CHANGELOG.