GitLab 18.1 release notes

Exact code search (in beta) now consolidates multiple search results from the same file into a single view. This improvement:

• Preserves context between adjacent matches instead of displaying isolated lines.
• Reduces visual clutter by eliminating duplicate content when matches are close together.
• Enhances navigation by clearly showing the number of matches per file.
• Improves readability by displaying code as you would see it in your editor.

With this change, finding and understanding code patterns across your repositories is now more efficient.

Previously, you couldn’t define a name for an external custom control when creating a custom compliance framework, which made it difficult to identify external controls when listed alongside GitLab controls.

We’ve now added a Name field as part of the workflow when defining an external custom control, so you can create multiple external custom controls and clearly define each one with its own unique name.

When creating a compliance framework, you can specify a maximum of 50 requirements.

However, it becomes very difficult to navigate a compliance framework with this many requirements because they consume a lot of space in the user interface.

In this release, we have introduced pagination for requirements to make it easier for users to navigate, find, and select requirements when there is a large number of them attached to a compliance framework.

We have continued to improve the UI performance and filtering options provided by the compliance center. In this release, we have:

• Improved the UI speed and performance of the Edit Framework page, especially where there are many requirements and projects on the page.
• Introduced new filtering options so that you can group by requirement, project, or framework in the Compliance status report tab in the compliance center.

By delivering these improvements, we continue to ensure that the compliance center and associated functions continue to perform at scale for customers who regularly use the compliance center.

Controls in the compliance status report have three different statuses:

• Pass
• Fail
• Pending

No matter the number of controls that are attached to the requirement, if at least one control was ‘pending’, the entire requirement row was shown as ‘pending’ as well. This deviated from the established UX pattern for visualizing failed controls, where the requirement would show the number of controls associated with the requirement, even when there was at least one control that fails.

To provide further context and information for ‘pending’ controls, we now provide a hover over pop-up on the requirement row status, with the status of each control listed. You can now understand which controls are pending, and which are potentially succeeding and failing, rather than just seeing a single status for ‘pending’.

When you review a merge request, it can be valuable to see all of the comments and feedback you’ve provided before you submit your review. Previously, this experience was fragmented between the final comment and an additional pop-up to see your pending comments, making it hard to get the complete overview.

When conducting code reviews, you can now access a dedicated drawer that consolidates all your pending draft comments in one organized view. The enhanced review panel moves the review submission interface to a more accessible location, and provides a numbered badge showing your pending comment count. When you open the panel, you’ll see all your draft comments organized in a scrollable list, making it easier to review and manage your feedback before submitting.

GitLab now provides enhanced validation for CODEOWNERS files that goes beyond basic syntax checking. When viewing a CODEOWNERS file, GitLab automatically runs comprehensive validations to help you identify both syntax and permission issues before they affect your merge request workflows.

The enhanced validation checks the first 200 unique user and group references in your CODEOWNERS file, and verifies that:

• All referenced users and groups have access to the project.
• Users have the necessary permissions to approve merge requests.
• Groups have at least Developer-level access or higher.
• Groups contain at least one user with merge request approval permissions.

This proactive validation helps prevent approval workflow disruptions by catching configuration issues early, ensuring your Code Owners can actually fulfill their review responsibilities when merge requests are created.

GitLab workspace now supports custom postStart events in your devfile, allowing you to define commands that automatically execute after workspace startup. Use these events to:

• Set up development dependencies.
• Configure your environment.
• Run initialization scripts that prepare your project for immediate productivity without manual intervention.

The GitLab Workflow extension for VS Code now displays job logs from downstream pipelines directly in your editor. Previously, viewing logs from child pipelines required switching to the GitLab web interface.

This feature was developed through the GitLab Co-create program. Special thanks to Tim Ryan for making this contribution!

We’ve made a significant improvement to GitLab Query Language (GLQL) views. You can now use epic as a type in your queries to search for epics across groups, and query by parent epic!

This is a huge step forward for our planning and tracking capabilities, making it easier than ever to query and organize at the epic level.

We have added PHP support to GitLab Advanced SAST. To use this new cross-file, cross-function scanning support, enable Advanced SAST. If you have already enabled Advanced SAST, PHP support is automatically activated.

To see which types of vulnerabilities Advanced SAST detects in each language, see the Advanced SAST coverage page.

Security teams often strike a delicate balance between security assurance and developer experience. It’s critical to ensure security scans are properly enforced, but security analyzers can require specific inputs from development teams to properly execute. With variable precedence controls, security teams now have granular control over how variables are handled in pipeline execution policies through the new variables_override configuration option.

Using this new configuration, you can now:

• Enforce container scanning policies that allow project-specific container image paths (CS_IMAGE).
• Allow lower risk variables like SAST_EXCLUDED_PATHS while blocking high risk variables like SAST_DISABLED.
• Define globally shared credentials that are secured (masked or hidden) with global CI/CD variables, such as AWS_CREDENTIALS, while allowing project-specific overrides where appropriate through project-level CI/CD variables.

This powerful feature supports two approaches:

• Lock variables by default (allow: false): Lock all variables except specific ones you list as exceptions.
• Allow variables by default (allow: true): Allow variables to be customized, but restrict critical risks by listing them as exceptions.

To improve traceability and troubleshooting when a pipeline execution policy is the source of an CI/CD job, we’re also introducing job logs to help developers and security teams identify the jobs executed by a policy. The job logs provide details on the impact of variable overrides to help you understand if variables are overridden or locked by policies.

Real-world impact

This enhancement bridges the gap between security requirements and flexibility for developers:

• Security teams can enforce standardized scanning while allowing project-specific customizations.
• Developers maintain control over project-specific variables without requesting policy exceptions.
• Organizations can implement consistent security policies without disrupting development workflows.

By solving this critical variable control challenge, GitLab enables organizations to implement robust security policies without sacrificing the flexibility teams need to deliver software efficiently.

Established GitLab instances can often have large numbers of human and bot users. You can now filter the users list in the Admin area by user type. Filtering users can help you:

• Quickly identify and manage human users separately from automated accounts.
• Perform targeted administrative actions on specific user types.
• Simplify user auditing and management workflows.

GitLab now supports ORCID identifiers in user profiles, making GitLab more accessible and valuable for researchers and the academic community. ORCID (Open Researcher and Contributor ID) provides researchers with a persistent digital identifier that distinguishes them from other researchers and supports automated linkages between researchers and their professional activities, ensuring their work is properly recognized.

This feature was developed as a community contribution by Thomas Labalette and Erwan Hivin, master students at Artois University, under the supervision of Daniel Le Berre, addressing a long-standing request from the academic community.

You can now subscribe to notifications for pipeline events triggered by service accounts. Notifications are sent when the pipeline passes, fails, or is fixed. Previously, these notifications were only sent to the service account’s email address if the service account has a valid custom email address.

Thank you Densett, Gilles Dehaudt, Lenain, Geoffrey McQuat, and Raphaël Bihoré for your contribution!

Previously, you had to manually resolve detected vulnerabilities with these Common Weakness Enumeration (CWE) identifiers:

• CWE-78 (Command Injection)
• CWE-89 (SQL Injection)

Now, Duo Vulnerability Resolution can automatically fix these vulnerabilities.

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

Bug Fixes:

• If you upgrade to GitLab 17.10 or 17.11, runners might receive a 404 response when they request jobs.

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