gitlab-org/gitlab-ce v16.8.0

on GitLab

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
gitlab.rb file so that plaintext passwords are not exposed:

• GitLab Kubernetes Agent Server
  
• GitLab Workhorse
  
• GitLab Exporter
  

This means plaintext passwords for Redis no longer need to be stored in gitlab.rb.

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 the patch-id before 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.

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.

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:

• Overwrite generated Kubernetes pod specifications - Beta
  

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.

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_DESCRIPTION predefined variable, making the description easily accessible in all jobs. In GitLab 16.8 we tweaked the behavior to truncate CI_MERGE_REQUEST_DESCRIPTION at 2700 characters, because very large descriptions can cause runner errors. You can check if the description was truncated with the newly introduced CI_MERGE_REQUEST_DESCRIPTION_IS_TRUNCATED predefined variable, which is set to true when the description was truncated.

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.