GitLab 17.11 release notes

GitLab Duo Chat now uses Anthropic Claude Sonnet 3.7 as the base model, replacing Claude 3.5 Sonnet for answering most questions.

Claude 3.7 Sonnet has strongly improved coding and reasoning capabilities, making it even better at explaining code, generating code, processing text data, and answering complex DevSecOps questions. You’ll notice more detailed and accurate Chat responses in these areas.

This upgrade applies to all Chat features, and ensures a consistent and improved experience across the entire Chat interface.

On GitLab Duo Self-Hosted, you can now select and configure individual supported models for each GitLab Duo feature and sub-feature on your GitLab Self-Managed instance.

To leave feedback, go to issue 524175.

Llama 3 models are now generally available with Gitlab Duo Self-Hosted to support GitLab Duo Chat and Code Suggestions.

To leave feedback on using these models with GitLab Duo Self-Hosted, see issue 523918.

Multiple conversations with GitLab Duo Chat is now available in GitLab Self-Managed instances in the web UI. You can create new conversations, browse your conversation history, and switch between conversations without losing context.

For your privacy, conversations with no activity for 30 days are automatically deleted, and you can manually delete any conversation at any time. On GitLab Self-Managed, administrators can reduce how long conversations are retained for.

Share your experience with us in issue 526013.

With this release, webhooks that return 4xx errors are now automatically re-enabled. All errors (4xx, 5xx, or server errors) are treated the same way, allowing for more predictable behavior and easier troubleshooting. This change was announced in this blog post.

Failing webhooks are temporarily disabled for one minute, extending to a maximum of 24 hours. After a webhook fails 40 consecutive times, it now becomes permanently disabled.

Webhooks that were permanently disabled in GitLab 17.10 and earlier underwent a data migration.

• For GitLab.com, these changes apply automatically.
• For GitLab Self-Managed and GitLab Dedicated, these changes affect only those instances where the auto_disabling_webhooks ops flag is enabled.

Thanks to Phawin for this community contribution!

Previously, ghost user contributions would create placeholder references that required manual reassignment, creating extra work during migrations. Now, importers using new contributions and membership mapping functionality, migration by direct transfer, GitHub, Bitbucket Server and Gitea importers, handle ghost user contributions more intelligently. When importing content to GitLab, contributions previously made by the ghost user on the source instance are now automatically mapped to the ghost user on the destination instance.

This enhancement eliminates the creation of unnecessary placeholder users for ghost user contributions, reducing clutter in user mapping interface and simplifying the migration process.

In this milestone, we’ve added SAML verification checks to contribution reassignment when importing to GitLab.com. These checks prevent reassignment errors in groups where SAML SSO is enabled.

If you import to GitLab.com and use SAML SSO for GitLab.com groups, all users must link their SAML identity to their GitLab.com account before you can reassign contributions and memberships. When you reassign contributions to users who have not verified their SAML identity, you’ll receive error messages. These messages explain the steps to take to help ensure your group memberships are attributed correctly.

Previously, placeholder users created during imports appeared mixed with regular users without clear distinction in the Admin area Users page.

With this release, administrators can now filter for placeholder accounts from the search box in the Users page in the Admin area. To do this, select Type in the dropdown list, then choose Placeholder.

For imports to GitLab.com, placeholder users are limited per top-level group. These limits depend on your GitLab license and number of seats. With this release, it’s possible to check your placeholder user usage and limits for a top-level group in the UI.

To view your current usage and limits:

1. On the left sidebar, select Search or go to and find your group. This group must be at the top level.
2. Select Settings > Usage Quotas.
3. Select the Import tab.

In GitLab 18.0, the minimum-supported version of PostgreSQL will be version 16. To prepare for this change, on instances that don’t use PostgreSQL Cluster, upgrades to GitLab 17.11 will attempt to automatically upgrade PostgreSQL to version 16.

If you use PostgreSQL Cluster or opt out of this automated upgrade, you must manually upgrade to PostgreSQL 16 to be able to upgrade to GitLab 18.0.

In GitLab 18.0, we plan to enable event-level product usage data collection from GitLab Self-Managed and GitLab Dedicated instances. Unlike aggregated data, event-level data provides GitLab with deeper insights into usage, allowing us to improve user experience on the platform and increase feature adoption.

Starting in GitLab 17.11, you will have the ability to opt out of event data collection before it starts, effectively allowing you to choose participation in advance. For more information and details on how to opt-out please see our documentation.

The Composition Analysis team has released beta support for static reachability for Python. This beta release focuses on enhancing stability, observability, and provides a better user experience via easier configuration.

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 and EPSS scores, as well as KEV indicators to provide a more focused view of your vulnerabilities.

We welcome feedback on this feature. If you have questions, comments, or would like to engage with our team please see this feedback issue.

The Dynamic Analysis team has introduced a check for CWE-79. This work allows our DAST scanner to check for reflected XSS attacks.

Checking for Reflective XSS is on by default. To turn off this check, in you configuration, set DAST_FF_XSS_ATTACK: false. If you have questions or feedback, see issue 525861.

In the past, you couldn’t assign new compliance frameworks to projects without navigating to the Projects tab in the compliance center after creating the compliance framework. This situation created unnecessary friction to creating new compliance frameworks in your groups.

In GitLab 17.11, when creating a compliance framework, we introduced a new step that provides the option of assigning multiple projects to the compliance framework before it is created.

This new feature:

• Helps keep you in the compliance framework creation workflow.
• Provides guidance for you to understand that compliance frameworks work together with projects in a group to monitor and enforce compliance adherence for the entire group.

This release adds full support for Kubernetes version 1.32, released in December 2024. If you deploy your apps to Kubernetes, you can now upgrade your connected clusters to the most recent version and take advantage of all its features.

You can read more about our Kubernetes support policy and other supported Kubernetes versions.

You can now configure SAML single sign-on (SSO) for your GitLab Dedicated instance for up to ten identity providers (IdPs).

All SAML configuration options available for GitLab Dedicated instances can be configured for each individual IdP.

If you had previously configured multiple IdPs, you can now view and edit all existing SAML configurations directly in Switchboard.

We’re excited to announce UI support for Docker Hub authentication in the GitLab Dependency Proxy. This feature was initially introduced in GitLab 17.10 with GraphQL API support only, and now includes a user interface for easier configuration.

With this enhancement, you can now configure Docker Hub authentication directly from your group settings page, helping you:

• Avoid pipeline failures due to rate limits.
• Access private Docker Hub images.
• Store your Docker Hub credentials, personal access token, or organization access tokens securely.

This streamlined approach makes it easier to maintain uninterrupted access to Docker Hub images in your CI/CD pipelines without using the GraphQL API.

You can now set work in progress limits by weight in addition to issue count, giving you more flexibility in managing your team’s workload.

Control the flow of work based on the complexity or effort of each task, rather than just the number of issues. Teams that use issue weights to represent effort can now ensure they don’t overcommit by limiting the total weight of issues in a given board list.

Use this feature to optimize your team’s productivity and create a more balanced workflow that accounts for varying task complexity.

The custom wiki sidebar now features improved styling with reduced heading sizes and better left-padding for lists. These ergonomic enhancements improve the readability of custom navigation created through the _sidebar wiki page.

Custom sidebars help teams organize their wiki content in a way that makes sense for their unique knowledge base structure. With this styling update, the sidebar is now easier to scan, creating a clearer visual hierarchy that helps team members find relevant information more quickly.

GLQL views now support displaying the last comment on an issue or merge request as a column. By including lastComment as a field in your GLQL query, you can see the most recent updates without leaving your current context.

Previously, you had to open each issue or merge request individually to view the last comment, which was time consuming and made it difficult to get a quick overview of progress. This improvement helps teams maintain momentum by providing at-a-glance visibility into ongoing conversations and status updates.

We welcome your feedback on this enhancement and GLQL views in general on our feedback issue.

GitLab provides templates for the most popular Static Site Generators (SSGs), and you can now create a GitLab Pages site using Nuxt, a powerful framework built on Vue.js. Nuxt is particularly valuable for teams looking to build modern, performant web applications with less configuration overhead.

This addition expands your options for quickly launching a Pages site with built-in CI/CD pipelines and a modern development experience, without spending time on initial setup and configuration.

Many organizations now require a software bill of materials (SBOM) to meet regulatory requirements and help further increase the security of the software supply chain. Previously, you could only export your dependency list as a JSON or CSV file from GitLab. Now, GitLab can generate your SBOM by exporting your dependency list in the widely-adopted CycloneDX format.

To download an SBOM directly as a CycloneDX file, in the dependency list, select Export > Export as CycloneDX (JSON).

Previously, when exporting the dependency list or the vulnerability report, you had to remain on the page until the export completed before you could download the report.

Now, you are notified by email with a download link when the dependency list or vulnerability report export is complete.

Previously, the tool search filter in the vulnerability report allowed you to filter results based on a single group of tools that included the type of scanner (like ESLint or Gemnasium) and the type of report (like SAST or container scanning).

To help you find the appropriate tools more easily, we’ve replaced the tool filter with the scanner filter and the report type filter. You can now filter your search based on each of these types of tools separately.

GitLab 17.11 introduces a new feature that allows users to verify the origin of build artifacts by tracking the source attribute of CI/CD jobs. This enhancement is particularly valuable for security and compliance workflows. For example, organizations can implement software supply chain security measures or require verifiable evidence of security scans for compliance purposes.

Jobs in GitLab now store and display a source value that identifies whether they originated from:

• A scan execution policy
• A pipeline execution policy
• A regular pipeline

You can access the source attribute on the Build > Jobs page with a new filter option, using the Jobs API, or through the ID token claims for artifact verification.

With this new feature, you can now:

• Verify the authenticity of security scan results.
• Filter jobs by source type to quickly identify policy-enforced scans.
• Implement cryptographic verification of artifacts using the new ID token claims.
• Ensure compliance requirements are met with proper audit trails.

Security and compliance teams can leverage this feature to:

• View only policy-enforced jobs using the new filter on the Jobs page.

• Automate tasks by accessing the source field in the Jobs API.

• Implement artifact verification using the new ID token claims:

  • job_source: Identifies the job’s origin.
  • job_policy_ref_uri: Points to the policy file (for policy-defined jobs).
  • job_policy_ref_sha: Contains the git commit SHA of the policy.

There are now additional sorting options for access tokens in the UI and API. These sorting options complement GitLab’s existing token management capabilities, giving you more control over your access token inventory, and helping you better maintain access token security. The new sorting options include:

• Sort by expiration date (ascending): View the tokens that expire soonest.
• Sort by expiration date (descending): View the tokens with the longest remaining lifetime.
• Sort by last used date (ascending): View the tokens that have not been used recently.
• Sort by last used date (descending): View the tokens used most recently.

The token management interface for service accounts now includes a helpful statistics dashboard that provides at-a-glance information about your token inventory. This information can help you assess the state of your tokens and identify tokens that require attention. The statistics dashboard includes four key metrics:

• Active tokens: View the total number of active tokens
• Expiring tokens: Identify tokens that expire in the next two weeks
• Revoked tokens: Track tokens that were manually revoked
• Expired tokens: Monitor tokens that have previously expired Thank you Chaitanya Sonwane for your contribution!

CI/CD jobs can occasionally get stuck in the ‘canceling’ state, blocking deployments or access to shared resources.

Users with the Maintainer role can now force-cancel these stuck jobs directly from the job logs page, ensuring problematic jobs can be properly terminated.

You can now manage runners more efficiently in your projects. Runners are displayed in a single-column layout and organized in their own lists instead of the previous two-column view.

This improved organization makes it simpler to find and manage runners, with new features including a list of assigned projects, runner managers, and jobs that a runner has run. For information about additional runner management improvements planned for GitLab 18.0, see issue 33803.

We’re also releasing GitLab Runner 17.11 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:

• Code sign GitLab Runner Windows executables

Bug Fixes:

• Cleaning Git configuration in GitLab Runner 17.10.0 results in an error
• The FF_DISABLE_UMASK_FOR_KUBERNETES_EXECUTOR flag doesn’t disable the umask command

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