Set your preferred text editor as default

Set your preferred text editor as default

In this version, we’re introducing the ability to set a default text editor for a more personalized editing experience. With this change, you can now choose between the rich text editor, the plain text editor, or opt for no default, allowing flexibility in how you create and edit content.

This update ensures smoother workflows by aligning the editor interface with individual preferences or team standards. With this enhancement, GitLab continues to prioritize customization and usability for all users.

Kubernetes 1.31 support

Kubernetes 1.31 support

This release adds full support for Kubernetes version 1.31, released in August 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.

Expanded Code Flow view for Advanced SAST

Expanded Code Flow view for Advanced SAST

The Advanced SAST code flow view is now available wherever vulnerabilities are shown, including the:

• Vulnerability Report.
• Merge request security widget.
• Pipeline security report.
• Merge request changes view.

The new views are all enabled on GitLab.com. On GitLab self-managed, the new views are on by default starting in GitLab 17.7 (MR changes view) and GitLab 17.6 (all other views). See code flow feature availability for details on supported versions and feature flags.

To learn more about Advanced SAST, see the announcement blog.

Extended token expiration notifications

Extended token expiration notifications

Previously, token expiration email notifications were only sent seven days before expiry. Now, these notifications are also sent 30 and 60 days before expiry. The increased frequency and date range of notifications makes users more aware of tokens that may be expiring soon.

Navigation and usability improvements for the compliance center

Navigation and usability improvements for the compliance center

We continue to make iterative and important improvements to the compliance center’s user experience for both groups and projects.

With GitLab 17.7, we shipped two key improvements:

• Users can now filter by groups in the Projects tab of the compliance center, which gives another option to users to apply, filter, and search for the appropriate project, and the compliance framework attached to that project.
• A project’s compliance center now has a Frameworks tab, which allows users to search for compliance frameworks attached to that particular project.

Please note that adding or editing frameworks is still done on groups, not projects.

New description field for access tokens

New description field for access tokens

When creating a personal, project, group, or impersonation access token, you can now optionally enter a description of that token. This helps provide extra context about the token, such as where and how is it used.

Unicode 15.1 emoji support 🦖🍋‍🟩🐦‍🔥

Unicode 15.1 emoji support 🦖🍋‍🟩🐦‍🔥

In previous versions of GitLab, emoji support was limited to an older Unicode standard, which meant some newer emojis were unavailable.

GitLab 17.7 introduces support for Unicode 15.1, bringing the latest emoji additions. This includes exciting new options like the t-rex 🦖, lime 🍋‍🟩, and phoenix 🐦‍🔥, allowing you to express yourself with the most up-to-date symbols. Additionally, this update enhances emoji diversity, ensuring greater representation across cultures, languages, and identities, helping everyone feel included when communicating on the platform.

Setting environment.action: access and prepare resets the auto_stop_in timer

Setting environment.action: access and prepare resets the auto_stop_in timer

Previously, when using the action: prepare, action: verify, and action: access jobs together with the auto_stop_in setting, the timer was not reset. Starting in 18.0, action: prepare and action: access will reset the timer, while action: verify leaves it untouched.

For now, you can change to the new implementation now by enabling the prevent_blocking_non_deployment_jobs feature flag.

Multiple breaking changes are intended to differentiate the behavior of the environment.action: prepare | verify | access values. The environment.action: access keyword will remain the closest to its current behavior, except for the timer reset.

To prevent future compatibility issues, you should review your use of these keywords now. You can learn more about these proposed changes in the following issues:

• Issue 437132
• Issue 437133
• Issue 437142

Manage scheduled scan execution pipeline concurrency

Manage scheduled scan execution pipeline concurrency

To improve scalability of global scheduled scan execution policies, we have introduced a new capability within scan execution policies to configure a time_window. You can configure the time_window property for each scheduled scan execution policy and control how the policy distributes the creation and execution of new schedules to ensure optimal performance.

To use the new property, update your policy using YAML mode and follow the time_window schema. You can provide a value in seconds for the window of time in which the schedules should run. For example, 86400 (24 hours). Then supply the distribution: random field and value to enforce the schedules to execute at random across the defined time window.

Group and project access tokens in credentials inventory

Group and project access tokens in credentials inventory

Group and project access tokens are now visible in the credentials inventory on GitLab.com. Previously, only personal access tokens and SSH keys were visible. Additional token types in the inventory allow for a more complete picture of credentials across the group.

New API endpoint to list enterprise users

New API endpoint to list enterprise users

Group Owners can now use a dedicated API endpoint to list enterprise users and any associated attributes.