This release adds full support for Kubernetes version 1.28, released in August 2023. 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.
From GitLab 16.8, you can specify commands to generate configurations for the following services in the
This means plaintext passwords for Redis no longer need to be stored in You can now enforce whether GitLab administrators are required to use two-factor authentication (2FA) in their self-managed instance. It is good security practice to use 2FA for all accounts, especially for privileged accounts like administrators. If this setting is enforced, and an administrator does not already use 2FA, they must set up 2FA on their next sign-in.
Kubernetes 1.28 support:
Deployment Management
Omnibus improvements (self-managed only):
Omnibus Package
gitlab.rb file so that plaintext passwords are not exposed:
gitlab.rb.
Enforce 2FA for GitLab administrators (self-managed only):
User Management
Plan
View all ancestor items of a task or OKR: Portfolio Management
With this release, you can now view the entire hierarchy lineage of a work item (such as task, objective, or key result) instead of just the immediate parent.
Create
Smarter approval resets with patch-id support: Code Review Workflow
To ensure all changes are reviewed and approved, it's common to remove all approvals when new commits are added to a merge request. However, rebases also unnecessarily invalidated existing approvals, even if the rebase introduced no new changes, requiring authors to seek re-approval.
Merge request approvals now align to a
git-patch-id. It's a reasonably stable and reasonably unique identifier that enables smarter decisions about resetting approvals. By comparing thepatch-idbefore and after the rebase, we can determine if new changes were introduced that should reset approvals and require a review.If you have feedback about your experiences with resets now, let us know in issue #435870.
View blame information directly in the file page: Source Code Management
In previous versions of GitLab, viewing file blame required you to access a different page. Now you can view the file blame information directly from the file page.
Verify
GitLab Runner 16.8: GitLab Runner Core
We're also releasing GitLab Runner 16.8 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.
What's new:
Bug Fixes:
- GitLab Runner authentication token exposed in the runner log file
- Registering multiple autoscaling runners results in a partial config.toml file
- Interrupt of the restore_cache helper task corrupts the cache
The list of all changes is in the GitLab Runner CHANGELOG.
Predefined variables for merge request description: Secrets Management
If you use automation to work with merge requests in CI/CD pipelines, you might have wanted an easier way to fetch a merge request's description without an API call. In GitLab 16.7 we introduced the
CI_MERGE_REQUEST_DESCRIPTIONpredefined variable, making the description easily accessible in all jobs. In GitLab 16.8 we tweaked the behavior to truncateCI_MERGE_REQUEST_DESCRIPTIONat 2700 characters, because very large descriptions can cause runner errors. You can check if the description was truncated with the newly introducedCI_MERGE_REQUEST_DESCRIPTION_IS_TRUNCATEDpredefined variable, which is set totruewhen the description was truncated.