GitLab 16.8 Release

Introduce group-level landing page for Analytics Dashboards

Introduce group-level landing page for Analytics Dashboards

We are introducing a new landing page for the group-level analytics dashboard. This enhancement ensures a more consistent and user-friendly navigation experience. In the first phase this page includes the Value Streams Dashboard, but it also sets the groundwork for future features, allowing you to personalize your dashboards. These improvements aim to streamline your experience, and provide more flexibility in managing and interpreting your data.

Set CPU and memory usage per workspace

Set CPU and memory usage per workspace

Improved developer experience, onboarding, and security are driving more development toward cloud IDEs and on-demand development environments. However, these environments might contribute to increased infrastructure costs. You can already configure CPU and memory usage per project in your devfile.

Now you can also set CPU and memory usage per workspace. By configuring requests and limits at the GitLab agent level, you can prevent individual developers from using an excessive amount of cloud resources.

View blame information directly in the file page

View blame information directly in the file page

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.

GitLab Runner 16.8

GitLab Runner 16.8

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.

Runner Fleet Dashboard: CSV export of compute minutes used by instance runners

Runner Fleet Dashboard: CSV export of compute minutes used by instance runners

You might need to run a report of CI/CD compute minutes used by projects on instance runners for various reasons. However, there wasn’t a simple to use mechanism in GitLab for you to generate a CI/CD compute minutes usage report. With this feature, you can export a report of CI/CD compute minutes used by each project on shared runners as a CSV file.

Kubernetes 1.28 support

Kubernetes 1.28 support

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.

Compliance framework management improvements

Compliance framework management improvements

Our compliance center is becoming the central destination for understanding compliance posture and managing compliance frameworks. We’re moving framework management into a new tab in the compliance center, as well as adding more exciting capabilities:

• View frameworks in a list view in the Frameworks tab.
• Search and filter to find specific frameworks.
• Use the new compliance framework sidebar to explore more details for each framework.
• Edit your framework to view all settings, including managing name, description, linked projects, and more.
• Create a quick report of your frameworks with an export to CSV.

Filter streaming audit events by sub group/project at group level

Filter streaming audit events by sub group/project at group level

Streaming audit events have been extended to support filtering by sub-group or project at the group level, in addition to the existing support for event type filtering.

This additional filter will allow you to separate out events in your streams to send to different destinations, or to exclude irrelevant sub-groups/projects, ensuring you have the most actionable events for your team to monitor.

New customizable permissions

New customizable permissions

There are five new abilities available you can use to create custom roles:

• Manage project access tokens.
• Manage group access tokens.
• Manage group members.
• Ability to archive a project.
• Ability to delete a project.

Add these abilities, along with other pre-existing custom abilities, to any base role to create a custom role. Custom roles allow you to define granular roles that only give a user the abilities they need to do their jobs, and reduce unnecessary privilege escalation.

Omnibus improvements

Omnibus improvements

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.

View all ancestor items of a task or OKR

View all ancestor items of a task or OKR

With this release, you can now view the entire hierarchy lineage of a work item instead of just the immediate parent.

Work items include: - Tasks, in all tiers. - Objectives and key results, in the Ultimate tier and behind a feature flag.

Smarter approval resets with patch-id support

Smarter approval resets with patch-id support

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.

CI/CD Components Catalog section for your internal components

CI/CD Components Catalog section for your internal components

As the number of items in the CI/CD catalog continues to expand, it is increasingly challenging for you to locate the CI/CD components released by your teams and available to you. In this release, we are introducing a dedicated Your groups tab, empowering you to effortlessly filter and identify the components associated with your organization. This simplified search process enhances efficiency, as you can more quickly find and use released CI/CD components.

Predefined variables for merge request description

Predefined variables for merge request description

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.

Windows 2022 support for SaaS runners on Windows

Windows 2022 support for SaaS runners on Windows

Teams can now build, test, and deploy applications on Windows Server 2022.

SaaS runners on Windows allow you to increase your development teams’ velocity in building and deploying applications that require Windows in a secure, on-demand GitLab Runner build environment integrated with GitLab CI/CD.

Try it out today by using saas-windows-medium-amd64 as the tag in your .gitlab-ci.yml file.

Assign a custom role with SAML SSO

Assign a custom role with SAML SSO

Users can be assigned a custom role as the default role they are created with when they are provisioned with SAML SSO. Previously, only static roles could be chosen as the default. This allows automatically provisioned users to be assigned a role that best aligns with the principle of least privilege.

Enforce policy to prevent branches being deleted or unprotected

Enforce policy to prevent branches being deleted or unprotected

One of several new settings added to scan result policies to aide in compliance enforcement of security policies, branch modification controls will limit the ability to circumvent policies by changing project-level settings.

For each existing or new scan result policy, you can enable Prevent branch modification to take effect for the branches defined within the policy to prevent users from deleting or unprotecting those branches.

Instance-level audit event streaming to AWS S3

Instance-level audit event streaming to AWS S3

Previously, you could configure only top-level group streaming audit events for AWS S3.

With GitLab 16.8, we’ve extended support for AWS S3 to instance-level streaming destinations.

SAML Group Sync for custom roles

SAML Group Sync for custom roles

You can now use SAML Group Sync to map custom roles to groups of users. Previously, you could only map SAML groups to GitLab’s static roles. This gives more flexibility to customers who use SAML Group Links to manage group membership and member roles.

SAML SSO authentication for merge request approval

SAML SSO authentication for merge request approval

For those using SAML SSO and SCIM for user account management in GitLab, you can now use SSO to meet the merge request authentication requirement over password-based authentication for approving merge requests.

This method ensures only authenticated users can approve a merge request for security and compliance, without having to use a separate password-based solution.