gitlab-org/gitlab-foss v18.10.0

on GitLab

Free tier group Owners on GitLab.com can now unlock AI with GitLab Credits. Purchase a monthly credit amount, commit to an annual term, and get access to GitLab Duo Agent Platform agents and flows. Credits refresh automatically each month, so your team always has what it needs to build faster and smarter.

Key highlights:

• Usage-based pricing: Purchase a monthly credit commitment without needing a base plan subscription.
  
• Self-service purchasing: Buy credits through the GitLab purchase flow.
  
• Seamless upgrade path: Your credit commitment transfers if you later upgrade to Premium or Ultimate.
  
• Consumption tracking: Monitor your credit usage through the GitLab Credits dashboard.
  

This purchase option is currently only available for free GitLab.com top-level groups.

The gitlab_blob_search tool now enables GitLab AI agents to search your code:

• Across all projects in a group.
  
• Across all accessible projects on an instance.
  

Previously, blob search was limited to a single project, or required specifying explicit project IDs. This change makes it easier for AI-powered workflows to discover and reuse code that's spread across multiple related projects.

We've streamlined the projects page in Explore to reduce clutter and remove redundant options that accumulated over time.
The simplified interface now focuses on two core views:

• Active tab: Discover projects with recent activity and ongoing development.
  
• Inactive tab: Access archived projects and those scheduled for deletion.
  

We've removed several redundant tabs:

• Most starred projects can be found by sorting Active or Inactive tabs by star count.
  
• All projects are available by viewing both Active and Inactive tabs.
  
• Trending tab will be fully removed in GitLab 19.0 due to limited functionality and low usage.
  

The cleaner design aligns with other project lists for visual consistency. You can still access all the same content through more logical organization and flexible sorting options.

The GitLab planning experience is getting a significant upgrade with the work items list and saved views,
bringing together two long-requested capabilities:

• The work items list combines epics, issues, and other work items into a single unified list,
  eliminating the need to switch between separate pages for different work item types.
  This makes it easier to understand relationships across your planning objects.

• Saved views allow you to create and save customized list configurations, including filters,
  sort order, and display options. This makes routine checks more efficient, and supports standardized
  ways of viewing work across your team.

This is the next step in the GitLab work items journey, a unified architecture designed to deliver
consistency and unlock new capabilities across GitLab planning tools.

Share your thoughts and feedback in issue 590689.

You can now use task item checkbox syntax directly in Markdown table cells.

Previously, achieving this required a combination of raw HTML and Markdown, which was
cumbersome and difficult to maintain.

This improvement makes it easier to track task completion directly within structured table
layouts in issues, epics, and other content.

Using CI/CD variables for dynamic job configuration can be challenging. Variables follow a complex override hierarchy that's difficult to manage, and they can't be used for a variety of use cases.

Now you can use inputs to define explicit, typed inputs at the job level. Use job inputs to define and control the values that a job accepts at runtime. With job inputs, you get:

• Type safety (string, number, boolean, array).
  
• Default values that can be static or reference existing variables.
  
• The option to define a strict list of possible values to use.
  
• Regex support for validating input values.
  

Job inputs can use the default values without any user interaction, but you can modify the values when retrying a job or running a manual job.

We're also releasing GitLab Runner 18.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:

• Allow k8s runner to define Pod Level Resources for build pod
  
• Add automation to update Go versions and packages for all Runner projects
  

Bug Fixes:

• S3 cache with RoleARN returns 403 instead of 404 for non-existent cache
  
• Using helper image gitlab-runner-helper:x86_64-v16.11.1-nanoserver21H2 results in init-permissions error
  
• MacOS: LaunchAgent - Service could not initialize on M1 architecture
  

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

C and C++ development teams using Conan as their package manager have long requested registry support in GitLab. Previously, the Conan package registry was experimental and only supported Conan 1.x clients, limiting adoption for teams that have migrated to the modern Conan 2.0 toolchain.

The Conan package registry now supports Conan 2.0 and has been promoted from Experimental to Beta. This release includes full v2 API compatibility, recipe revision support, improved search capabilities, and proper handling of upload policies including the --force flag. Teams can publish and install Conan 2.0 packages directly from GitLab using standard Conan client workflows, reducing the need for external artifact management solutions like JFrog Artifactory.

With this update, platform engineering teams managing C and C++ dependencies can consolidate their package management within GitLab alongside their source code, CI/CD pipelines, and security scanning. The Conan registry supports both project-level and instance-level endpoints, and works with personal access tokens, deploy tokens, and CI/CD job tokens for authentication.

We welcome feedback as we work toward general availability. Please share your experience in the epic.

Teams using Helm to manage Kubernetes application deployments can now rely on the GitLab Helm Chart registry for production workloads. Previously in beta, the registry is now generally available following the resolution of key architectural and reliability concerns.

The path to GA included resolving a hard limit that prevented the index.yaml endpoint from returning more than 1,000 charts, fixing a background indexing bug that caused newly published chart versions to be missing from the index, completing a full AppSec security review, and adding Geo replication support for Helm metadata cache, ensuring high availability for self-managed customers running GitLab Geo.

Platform and DevOps teams can publish and install Helm charts directly from GitLab using standard Helm client workflows, with support for project-level endpoints and authentication using personal access tokens, deploy tokens, and CI/CD job tokens. Now you can keep charts alongside the source code, pipelines, and security scanning that depend on them.

GitLab now supports passkeys for passwordless sign-in and as a phishing-resistant two-factor authentication (2FA) method. Passkeys use public-key cryptography and biometric authentication (fingerprint, face recognition) or your device PIN to securely access your account.

Passkeys offer the following benefits:

• Passwordless convenience: Sign in with your device's biometrics or PIN instead of remembering a password.
  
• Multi-device support: Use passkeys on desktop browsers, mobile devices (iOS 16 or later, Android 9 or later), and FIDO2/WebAuthn-compatible hardware security keys.
  
• Phishing-resistant security: Your private key never leaves your device. GitLab only stores the public key, protecting your account even if GitLab servers are compromised.
  
• Automatic 2FA integration: For accounts with 2FA enabled, passkeys become available as your default 2FA method.
  

To get started, add a passkey in your account settings. We welcome your questions and feedback in issue 366758.