GitLab CE - v16.10.0

18 new features
2139 total badges

[GitLab chart improvements]( (self-managed only): Cloud Native Installation > In GitLab 16.10, we've removed support for installing GitLab on Kubernetes 1.24 and older. Kubernetes maintenance support of Kubernetes 1.24 ended > in July 2023. > > GitLab 16.10 includes support for installing GitLab on Kubernetes 1.27. For more information, see our new [Kubernetes version support policy]( Our goal is to support newer versions of > Kubernetes closer to their official release.
[Omnibus improvements]( (self-managed only): Omnibus Package > Gitlab 16.10 introduces a new major version of Patroni, version 3.0.1. This version upgrade will require downtime. For more > information and instructions, see the > [16.10 section of our GitLab 16 changes page]( > > GitLab 16.10 also includes a new version of Alertmanager, namely version 0.27. Most notably, this version includes the removal of API v1. For more information on this > release, see the [Alertmanager changelog]( > > GitLab 16.10 also includes [Mattermost 9.5]( > Mattermost 9.5 includes various security updates and the deprecation of support for MySQL 5.7. Users on this version of MySQL must update.
[Blocked users are excluded from the followers list]( User Profile > Previously, when a user who followed you was blocked, they still appeared in the followers list of your User Profile. From GitLab 16.10, blocked users are hidden from the followers list. If the user is unblocked, they will reappear in the followers list. > > Thank you @SethFalco for this community contribution!
[Filter groups by visibility in the REST API]( Groups & Projects > You can now filter groups by visibility in the [Groups API]( You can use filtering to focus on groups with a specific visibility level, making it easier to audit GitLab implementations. > > Thank you @imskr for this community contribution!
[Manually refresh the dashboard for Kubernetes]( Environment Management > GitLab 16.10 adds a dedicated refresh feature to the dashboard for Kubernetes. Now you can manually fetch Kubernetes resource data, and ensure you have access to the most recent information about your clusters.
[Improved environment details page]( Environment Management > The environment details page is improved in GitLab 16.10. When you select an environment from the environment list, you can review up-to-date information about your deployments and connected Kubernetes clusters, all in one convenient layout.
[Improved error message for authentication rate limit]( System Access > When authenticating with GitLab, it is possible to hit the authentication attempt rate limit, such as when using a script. Previously, if you hit the authentication rate limit, a `403 Forbidden` message was returned, which did not explain why you are getting this error. We now return a more descriptive error message which tells you that you've hit the authentication rate limit.
[Webhooks support mutual TLS]( (self-managed only): System Access > You can now configure webhooks to support mutual TLS. This configuration establishes the authenticity of the webhook source and enhances security. You configure the client certificate in PEM format, which is presented to the server during the TLS handshake. You can also protect the certificate with a PEM passphrase.
[Sign-in page improvements]( System Access > The GitLab sign-in page has been refreshed with improvements that fix spacing issues, broken elements, and alignment. There is also additional support for dark mode, and a button to manage cookie preferences. The combination of these improvements gives a fresh look and improved functionality on the sign-in page.
[Threaded notifications supported in Google Chat]( Integrations > Previously, notifications sent from GitLab to a space in Google Chat could not be created as replies to specified threads. > With this release, threaded notifications are enabled by default in Google Chat for the same GitLab object (for example, an issue or merge request). > > Thanks to [Robbie Demuth]( for [this community contribution](!
[Custom payload template for webhooks]( Webhooks > Previously, GitLab webhooks could send only specific JSON payloads, which meant the receiving endpoints had to understand the webhook format. To use those webhooks, you had to either use an app to specifically support GitLab or write your own endpoint. > > With this release, you can set a custom payload template in the webhook configuration. The request body is rendered from the template with the data for the current event. > > Thanks to [Niklas]( for [this community contribution](!
[Wiki templates]( Wiki > This version of GitLab introduces all-new templates to the Wiki. Now, you can create templates to streamline creating new pages or modifying existing ones. Templates are wiki pages that are stored in the templates directory in the wiki repository. > > With this enhancement, you can make your wiki page layouts more consistent, create or restructure pages faster, and ensure that information is presented clearly and coherently in your knowledge base.
[Support domain-level redirects for GitLab Pages]( Pages > Previously, GitLab focused on supporting simple redirect rules. In GitLab 14.3, we [introduced]( support for splat and placeholder redirects. > > From GitLab 16.10, GitLab Pages supports domain-level redirects. You can combine domain-level redirects with [splat rules]( to dynamically rewrite the URL path. This improvement helps prevent confusion and ensure that you can still find your information after a domain change, even if you use an old domain.
[Automatically collapse generated files in merge requests]( Code Review Workflow > Merge requests can contain changes from users and automated processes or compilers. Files like `package-lock.json`, `Gopkg.lock`, and minified `js` and `css` files increase the number of files shown in a merge request review, and distract reviewers from the human-generated changes. Merge requests now display these files collapsed by default, to help: > > - Focus reviewer attention on important changes, but enable a full review if desired. > - Reduce the amount of data needed to load the merge request, which might help larger merge requests perform better. > > For examples of the file types that are collapsed by default, see the [documentation]( To collapse more files and file types in the merge request, specify them as `gitlab-generated` in your project's `.gitattributes` file. > > You can leave feedback on this change in [issue 438727](
[Expanded checks in merge widget]( Code Review Workflow > The merge widget explains clearly if your merge request is not mergeable, and why. Previously, only one merge blocker was displayed at a time. This increased review cycles and forced you to resolve problems individually, without knowing if more blockers remained. > > When you view a merge request, the merge widget now gives you a comprehensive view of problems, both remaining and resolved. Now you can understand at a glance if multiple blockers exist, fix them all in a single iteration, and increase your confidence that no hidden blockers have been missed.
[GitLab Runner 16.10]( GitLab Runner Core > We're also releasing GitLab Runner 16.10 today! GitLab Runner is the lightweight, highly-scalable 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: > > - [Memory leak when jobs are cancelled in the Runner Kubernetes executor]( > > The list of all changes is in the GitLab Runner [CHANGELOG](
[Semantic versioning in the CI/CD catalog]( Pipeline Composition > To enforce consistent behavior across published components, in GitLab 16.10 we will enforce Semantic versioning for components that are published to the CI/CD catalog. When publishing a component, the tag must follow the 3-digit semantic versioning standard (for example `1.0.0`). > > When using a component with the `include: component` syntax, you should use the published semantic version. Using `~latest` continues to be supported, but it will always return the latest published version, so you must use it with caution as it could include breaking changes. Shorthand syntax is not supported, but it will be in an upcoming milestone.
[Create Service Desk tickets from the UI and API]( Service Desk > Now you can create Service Desk tickets from the UI and the API using the `/convert_to_ticket` quick action on a regular issue. > > Create a regular issue and add a comment with the `/convert_to_ticket` quick action. The provided email address becomes the external author of the ticket. GitLab doesn't send the [default thank you email]( You can add a public comment on the ticket to let the external participant know that the ticket has been created. > > Adding a Service Desk ticket using the API follows the same concept: Create an issue using the [Issues API]( and use the `issue_iid` to add a note with the quick action using the [Notes API](


March 21, 2024, midnight
GitLab 16.10
Register or login to:
  • 🔍View and search all GitLab CE releases.
  • 🛠️Create and share lists to track your tools.
  • 🚨Setup notifications for major, security, feature or patch updates.
  • 🚀Much more coming soon!
Continue with GitHub
Continue with Google