gitlab-org/gitlab-foss v18.6.0

on GitLab

We've introduced rate limiting for the /api/v4/projects/:id/members/all and /api/v4/groups/:id/members/all endpoints to improve API stability and ensure fair resource usage across all users.
The GET /api/v4/projects/:id/members/all and GET /api/v4/groups/:id/members/all endpoints now have a rate limit of 200 requests per minute per user.
This change helps protect GitLab instances from excessive API usage that could impact performance for all users.
The limit of 200 requests per minute provides ample capacity for normal usage patterns while preventing potential abuse or unintentional resource exhaustion.
If your integrations or scripts use this endpoint, ensure they handle rate limit responses appropriately (HTTP 429) and implement retry logic with backoff as needed.
Most users should not be affected by this change under normal usage patterns.

Introducing a smarter, more intuitive GitLab UI that puts developer productivity first.

The new side-by-side design uses contextual panels to keep you in your workflow, reducing unnecessary clicks and helping teams work faster. Customize your workspace, maximize screen real estate, and enjoy a cleaner, more dynamic experience that adapts to your workflow.

GitLab is committed to continuous improvement, so please share your thoughts in the feedback issue and help shape the future of GitLab.

On your homepage, draft merge requests can clutter your merge request view and
distract from work that's ready for action. Previously, you could not filter them
out.

You can now hide draft merge requests from the Your merge requests section on
your homepage by using the display preferences. When you hide draft merge requests:

• They are excluded from the active count.
  
• A footer displays the number of filtered draft merge requests.
  
• Your preference is saved automatically.
  

This change helps you focus on merge requests that need immediate attention.

The GitLab CLI (glab) provides new features and improvements to enhance your
GitLab workflow from the command line:

• Enhanced authentication: Auto-detect GitLab URLs from git remotes
  during login, making it easier to authenticate against the correct
  GitLab instance.

• Flexible pipeline monitoring: View any pipeline by ID with the
  ci-view command.

• GPG key management: Manage GPG keys directly from the CLI with
  new commands.

• Project member management: Add, remove, and update project members
  from the command line.

• Improved Git integration: Enhanced git-credential plugin with
  support for all token types.

• Modern user interface: Updated prompt library for better confirmation
  dialogs and consistent GitLab theme across UI components.

For a full list of changes and updates, see CLI releases.
To get started with the GitLab CLI or update to the latest version,
see the installation guide.

Webhook integrations are critical for automating workflows and keeping
external systems synchronized with GitLab merge request activities.
However, when reviewers were re-requested for merge requests, webhook
consumers had no way to identify which specific reviewer was being
re-requested, making it difficult to trigger appropriate notifications
or automation.

Webhook payloads for merge requests now include a re_requested attribute
in reviewer data that clearly indicates which reviewer was re-requested:

• Set to true for the specific reviewer being re-requested.
  
• Set to false for all other reviewers.
  

This improvement enables more precise automation around the merge request
review process. Webhook consumers can send targeted notifications,
update external tracking systems, and trigger appropriate workflows when
reviews are re-requested.

GitLab Self-Managed administrators in offline or tightly controlled network environments can now configure a custom Web IDE extension host domain, enabling full Web IDE functionality without external internet access.

Previously, the Web IDE required connectivity to .cdn.web-ide.gitlab-static.net to load VS Code extensions and functionality. This requirement blocked Web IDE adoption for security-conscious organizations, government and public sector customers, and enterprises with strict network policies.

With this update, administrators can configure their GitLab instance to serve Web IDE assets directly, removing the dependency on external domains. You can now:

• Use the full Web IDE feature set in completely offline environments.
  
• Enable the Extension Marketplace with a custom extension registry service.
  
• Enable markdown preview, code editing, and GitLab Duo Chat within the Web IDE in isolated networks.
  

Previously, CI/CD components couldn't reference their own metadata, such as version numbers
or commit SHAs, within their configuration. This lack of information could cause you to use configuration with
hardcoded values or complex workarounds. Writing configuration this way can
lead to version mismatches when components build resources such as Docker images,
because there's no way to automatically tag those resources with the component's compatible version.

In this release, we've introduced the ability to access component context with the spec:component keyword.
You can now build and publish versioned resources like Docker images when you release a component version,
ensuring everything is in sync, eliminating manual version management, and preventing version mismatches.

parallel:matrix makes it possible
to easily run multiple jobs in parallel with different requirements, for example
to test code for multiple platforms at the same time. But if you wanted later jobs
to use needs:parallel:matrix to depend on specific parallel jobs, the configuration was complex
and inflexible.

Now, with the new $[[matrix.VARIABLE]] expression introduced as a Beta feature,
users can create dynamic 1-1 dependencies which makes complex parallel:matrix configurations
much easier to manage. This can help you create faster pipelines, with efficient artifact handling,
better scalability, and cleaner configuration. This feature is particularly valuable for multi-platform builds,
Terraform deployments across multiple environments, and any workflow requiring parallel processing across multiple dimensions.

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

• Implement minimal job confirmation API
  

Bug Fixes:

• GitLab Runner does not expand the variables in the Docker image platform option
  
• Helper sidecar container fails to upload cache to S3 bucket from another account
  
• Automatically canceled job continues execution and fails
  
• Missing UTF8 BOM in the generated PowerShell script allows remote code execution using merge request title with character Ä
  
• Intermittent Kubernetes API server request failures with Kubernetes executor
  
• When using a Kubernetes executor, jobs with large commit messages fail
  

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

GitLab's Helm chart registry previously generated metadata responses on-the-fly, which created performance bottlenecks when repositories contained large numbers of charts. To maintain system stability, we enforced a hard limit of the 1,000 most recent charts. This limit caused frustrating 404 errors when platform teams tried to access older chart versions.

Platform engineers were forced to implement complex workarounds, like splitting charts across multiple repositories, manually managing chart retention policies, or maintaining separate chart storage solutions. These workarounds added operational overhead and fragmented deployment workflows, making it harder to maintain centralized chart governance.

In GitLab 18.6, we've eliminated the 1,000 chart limitation by pre-computing metadata responses and storing them in object storage. This architectural change delivers both unlimited chart access and improved performance, as metadata is generated once in background jobs rather than on every request.

We've added support for 40 new rules to GitLab's pipeline secret detection. Some existing rules have also been updated to improve quality and reduce false positives. These changes are released in version 7.20.1 of the secrets analyzer.

You can now designate an account beneficiary permission to manage your GitLab account if you are incapacitated or unavailable. To access your account, the beneficiary must provide appropriate legal documentation. This feature helps ensure the continuity of your work and projects while preventing unauthorized access.