gitlab-org/gitlab-foss v17.11.0

on GitLab

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.

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 Serber 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.

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.

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.

As of this release, the new issue look is generally available and replaces the legacy issue experience. Issues now share a common framework with epics and tasks, featuring real-time updates and workflow improvements:

• Drawer view: You can open items from lists or boards in a drawer for quick viewing without leaving your current context. A button at the top lets you expand to a full-page view.
  
• Change type: Convert types between epics, issues, and tasks using the “Change type” action (replaces “Promote to epic”)
  
• Start date: Issues now support start dates, aligning their functionality with epics and tasks.
  
• Ancestry: The complete hierarchy is above the title and the Parent field in the sidebar. To manage relationships, use the new quick action commands /set_parent, /remove_parent, /add_child, and /remove_child.
  
• Controls: All actions are now accessible from the top menu (vertical ellipsis), which remains visible in the sticky header when scrolling.
  
• Development: All development items (merge requests, branches, and feature flags) related to an issue or task are now consolidated in a single, convenient list.
  
• Layout: UI improvements create a more seamless experience between issues, epics, tasks, and merge requests, helping you navigate your workflow more efficiently.
  
• Linked items: Create relationships between tasks, issues, and epics with improved linking options. Drag and drop to change link types and toggle the visibility of labels and closed items.
  

We're thrilled to announce the launch of the extension marketplace in the Web IDE for self-managed users. With the extension marketplace, you can discover, install, and manage third-party extensions to enhance your development experience.

By default, the GitLab instance is configured to use the Open VSX extension registry. To activate this, follow the enable with default extension registry steps.

If you want to use your own or custom registry, you also have the option to connect a custom extension registry. This provides you with more flexibility to manage available extensions.

After enabling the extension marketplace, individual users must still opt in to use it. They can do this by going to the Integrations section in their Preferences settings.

It's important to note that some extensions require a local runtime environment and are not compatible with the web-only version. Despite this, you can still choose from thousands of available extensions to boost your productivity and customize your workflow.

You can now quickly identify failed jobs in the pipeline graph with new visual indicators. Failed job groups are highlighted in the pipeline graph, and failed jobs are grouped at the top of each stage. This improved visualization helps you troubleshoot pipeline failures without having to search through complex pipeline structures.

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.

CI/CD variables are essential for dynamic CI/CD workflows, and are used for many things, including as environment variables, context variables, tool configuration, and matrix variables. But developers sometimes rely on CI/CD variables to inject pipeline variables into pipelines to manually modify pipeline behavior, which have some risks due to the higher precedence of pipeline variables.

In GitLab 17.11 and later, you can now use inputs to safely modify pipeline behavior instead of using pipeline variables, including in scheduled pipelines, downstream pipelines, triggered pipelines, and other cases. Inputs provide developers with a more structured and flexible solution for injecting dynamic content at CI/CD job runtime. After you switch to inputs, you can completely disable access to pipeline variables.

We'd greatly appreciate it if you could try it out and share your feedback through this dedicated issue.

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.

Container registries are critical infrastructure for modern DevSecOps teams. Until now, GitLab users with the Developer role or higher could push and delete any container tag in their projects, creating risks of accidental or unauthorized changes to production-critical container images.

With protected container tags, you now have fine-grained control over who can push or delete specific container tags. You can:

• Create up to five protection rules per project.
  
• Use RE2 regex patterns to protect tags like latest, semantic versions (for example, v1.0.0), or stable release tags (for example, main-stable).
  
• Restrict push and delete operations to Maintainer, Owner, or Administrator roles.
  
• Prevent protected tags from being removed by cleanup policies.
  

This feature requires the next-generation container registry, which is already enabled by default on GitLab.com. For GitLab Self-Managed instance, you'll need to enable the metadata database to use protected container tags.

We're thrilled to introduce support for protected Maven packages to enhance the security and stability of your GitLab package registry. Accidental modification of packages can disrupt the entire development process. With protected packages, you can safeguard your most important dependencies against unintended changes.

In GitLab 17.11, you can now protect Maven packages by creating protection rules. If a package matches a protection rule, only specified users can push new versions of the package. Package protection rules prevent accidental overwrites, improve compliance with regulatory requirements, and reduce the need for manual oversight.

Protected packages support for Maven and other package formats are all community contributions from gerardo-navarro and the Siemens crew. Thank you, Gerardo, and the rest of the crew from Siemens for their many contributions to GitLab! If you want to learn more about how Gerardo and the Siemens crew contributed this change, check out this video in which Gerardo shares his learnings and best practices for contributing to GitLab based on his experience as an external contributor.

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.
  

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.
    

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.