The following features were added in this release.
In addition, we want to thank all of our contributors, including this month's notable contributor.
Everyone can nominate GitLab’s community contributors! Show your support for our active candidates or add a new nomination! 🙌
Vedant has been an outstanding community contributor, known for his proactive approach to contributing, his commitment to delivering, and his collaboration skills. He excels at taking on feedback, incorporating it into his work, and seeking assistance when needed, ensuring that his contributions are not only completed but also meet GitLab’s standards.
His contributions include streamlining project management processes with Abstracted work item attributes to a single list/board, Ordering of metadata on work items, and feature development in Remember the collapsed state of work item widgets. Vedant also fixed links in the UI to documentation (1, 2), helping the technical writing team as part of an important effort to improve UX across the entire product.
Amanda Rueda, Sr. Product Manager, Product Planning at GitLab, nominated Vedant and highlighted his proactive and community-oriented mindset, “Vedant’s work not only addresses user needs but through his contributions, he is co-creating a more stable and reliable GitLab environment. By contributing to bug fixes, usability improvements, and maintenance efforts, he has played a vital role in enhancing the overall quality of the product. His proactive approach and cross-group contributions embody GitLab’s core values of iteration, customer collaboration, and continuous improvement, making him a standout contributor in the community.”
“Thanks to everyone who helped me achieve my contributions,” says Vedant. “So grateful that I am able to make a good impact and looking forward to more contributions.”
Vedant is a Frontend Engineer at Atlan, an active metadata platform for modern data teams, and a Google Summer of Code 2024 Mentor.
We are so grateful to Vedant for all of his contributions and to all of our open source community for contributing to GitLab!
Instance administrators can now configure an allowlist to control which integrations can be enabled on a GitLab instance. If an empty allowlist is configured, no integrations are allowed on the instance. After an allowlist is configured, new GitLab integrations are not on the allowlist by default.
Previously enabled integrations that are later blocked by the allowlist settings are disabled. If these integrations are allowed again, they are re-enabled with their existing configuration.
The new method of user contribution and membership mapping is now available when you migrate between GitLab instances by direct transfer. This feature offers flexibility and control for both users managing the import process and users receiving contribution reassignments. With the new method, you can:
When you reassign a contribution to a user on the destination instance, the user can accept or reject the reassignment.
For more information, see streamline migrations with user contribution and membership mapping. To leave feedback, add a comment to issue 502565.
GitLab’s security scanning tools help identify known vulnerabilities and potential weaknesses in your application code. Scanning feature branches surfaces new weaknesses or vulnerabilities so they can be remediated before merging. In the case of vulnerabilities already in your project’s default branch, fixing these in a feature branch will mark the vulnerability as no longer detected when the next default branch scan runs. While it is informative to know which vulnerabilities are no longer detected, each must still be manually marked as Resolved to close them. This can be time consuming if there are many of these to resolve, even when using the new Activity filter and bulk-changing status.
We are introducing a new policy type Vulnerability Management policy for users who want vulnerabilities automatically set to Resolved when no longer detected by automated scanning. Simply configure a new policy with the new Auto-resolve option and apply it to the appropriate project(s). You can even configure the policy to only Auto-resolve vulnerabilities of a certain severity or from specific security scanners. Once in place, the next time the project’s default branch is scanned, any existing vulnerabilities that are no longer found will be marked as Resolved. The action updates the vulnerability record with an activity note, timestamp when the action occurred, and the pipeline the vulnerability was determined to be removed in.
You can now use the UI to rotate personal, project, and group access tokens. Previously, you had to use the API to do this.
Thank you shangsuru for your contribution!
Central DevOps teams often need to track where their CI/CD components are used across pipelines to better manage and optimize them. Without visibility, it’s challenging to identify outdated component use, understand adoption rates, or support component life cycles.
To address this, we’ve added a new GraphQL query that enables DevOps teams to view a list of projects where a component is used across their organization’s pipelines. This capability empowers DevOps teams to enhance productivity and make better decisions by providing crucial insights.
We are excited to introduce the small hosted runner on Linux Arm for GitLab.com, available for all tiers. This 2 vCPUs Arm runner is fully integrated with GitLab CI/CD and allows you to build and test applications natively on the Arm architecture.
We are determined to provide the industry’s fastest CI/CD build speed and look forward to seeing teams achieve even shorter feedback cycles and ultimately deliver software faster.
Because of a bug, FIPS Linux packages for GitLab 17.6 and earlier did not use the system Libgcrypt, but the same Libgcrypt bundled with regular Linux packages.
This issue is fixed for all FIPS Linux packages for GitLab 17.7, except for AmazonLinux 2. The Libgcrypt version of AmazonLinux 2 is not compatible with the GPGME and GnuPG versions shipped with the FIPS Linux packages.
FIPS Linux packages for AmazonLinux 2 will continue to use the same Libgcrypt bundled with the regular Linux packages, otherwise we would have to downgrade GPGME and GnuPG.
We’ve updated Advanced SAST to detect the following vulnerability classes more accurately:
We’ve also improved detection of user input sources for C# (ASP.NET) and Java (JSF, HttpServlet) and updated severity levels for consistency.
To see which types of vulnerabilities Advanced SAST detects in each language, see Advanced SAST coverage. To use this improved cross-file, cross-function scanning, enable Advanced SAST. If you’ve already enabled Advanced SAST, the new rules are automatically activated.
In GitLab 17.7, we added support for the Known Exploited Vulnerabilities Catalog (KEV). The KEV Catalog is maintained by CISA and curates listings of CVEs that have been exploited in the wild. You can leverage KEV to better prioritize scan results and to help evaluate the potential impact a vulnerability may have on your environment.
This data is available to composition analysis users through GraphQL. There is planned work to support displaying this data in the GitLab UI.
The Advanced SAST code flow view is now available wherever vulnerabilities are shown, including the:
The new views are 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). For details on supported versions and feature flags, see code flow feature availability.
To learn more about Advanced SAST, see the announcement blog.
Discover GitLab Duo Chat’s powerful features! Just type /help in the chat message field to explore everything it can do for you.
Give it a try and see how GitLab Duo Chat can make your work smoother and more efficient.
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 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. Learn more about these proposed changes in the following issues:
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.
For more information, see our Kubernetes support policy and other supported Kubernetes versions.
environment.kubernetes.namespace and environment.kubernetes.flux_resource_path attributes.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.
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.
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:
Please note that adding or editing frameworks is still done on groups, not projects.