gitlab-org/gitlab-foss v17.7.0

on GitLab

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.

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:

• Issue 437132
  
• Issue 437133
  
• Issue 437142
  

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.

To use the dashboard for Kubernetes, you need to select an agent for Kubernetes connection from the environment settings, and optionally configure a namespace and a Flux resource to track the reconciliation status. In GitLab 17.6, we added support for selecting an agent with a CI/CD configuration. However, configuring the namespace and the Flux resource still required you to use the UI or make an API call. In 17.7, you can fully configure the dashboard using the CI/CD syntax with the environment.kubernetes.namespace and environment.kubernetes.flux_resource_path attributes.

This experimental feature is another step in helping users prioritize vulnerabilities identified during Dependency Scanning or Container Scanning. Users may include this CI/CD component in their .gitlab-ci.yml file, which will generate a prioritization report for vulnerabilities found in the project. The report will print to the pipeline output.

The component queries the GitLab GraphQL API to retrieve vulnerability data and prioritizes as follows:

1. Vulnerabilities with known exploits (KEV) are the top priority.
   
2. Vulnerabilities with high EPSS scores.
   
3. Higher severity vulnerabilities.
   

Only detected and confirmed vulnerabilities are shown. Currently, the component relies on EPSS and KEV data to help prioritize vulnerabilities. EPSS and KEV data are only found on CVEs, which are collected through dependency and container scanning. To learn more, please refer to the Vulnerability Prioritizer.

As always, we welcome your feedback. Please add any questions or comments to the feedback issue.

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:

• Reassign memberships and contributions to existing users on the destination instance after the import has completed. Any memberships and contributions you import are first mapped to placeholder users. All contributions appear associated with placeholders until you reassign them on the destination instance.
  
• Map memberships and contributions for users with different email addresses on source and destination instances.
  

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.

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've introduced the new Planner role to give you tailored access to Agile planning tools like epics, roadmaps, and Kanban boards without over-provisioning permissions. This change helps you collaborate more effectively while keeping your workflows secure and aligned with the principle of least privilege.

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.

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.

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!