Jan 18, 2024 - 转载自: GitLab.com - Jocelyn Eillis  
16.8

GitLab 16.8 released with Google Cloud Secret Manager support and the ability to speed up your builds with the Maven dependency proxy

GitLab 16.8 released with Google Cloud Secret Manager support, the ability to speed up your builds with the Maven dependency proxy, general availability of Workspaces, and much more!

Today, we are excited to announce the release of GitLab 16.8 with Google Cloud Secret Manager support, the ability to speed up your builds with the Maven dependency proxy, general availability of Workspaces, new organization-level DevOps view with DORA-based industry benchmarks and much more!

These are just a few highlights from the 25+ improvements in this release. Read on to check out all of the great updates below.

To the wider GitLab community, thank you for the 207 contributions you provided to GitLab 16.8! At GitLab, everyone can contribute and we couldn't have done it without you!

To preview what's coming in next month’s release, check out our Upcoming Releases page, which includes our 16.9 release kickoff video.

Workspaces are now generally available

We’re thrilled to share that workspaces are now generally available and ready to improve your developer efficiency!

By creating secure, on-demand remote development environments, you can reduce the time you spend managing dependencies and onboarding new developers and focus on delivering value faster. With our platform-agnostic approach, you can use your existing cloud infrastructure to host your workspaces and keep your data private and secure.

Since their introduction in GitLab 16.0, workspaces have received improvements to error handling and reconciliation, support for private projects and SSH connections, additional configuration options, and a new administrator interface. These improvements mean that workspaces are now more flexible, more resilient, and more easily managed at scale.

Workspaces are now generally available

Enforce 2FA for GitLab administrators

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.


Speed up your builds with the Maven dependency proxy

A typical software project relies on a variety of dependencies, which we call packages. Packages can be internally built and maintained, or sourced from a public repository. Based on our user research, we’ve learned that most projects use a 50/50 mix of public and private packages. Package installation order is very important, as using an incorrect package version can introduce breaking changes and security vulnerabilities into your pipelines.

Now you can add one external Java repository to your GitLab project. After adding it, when you install a package using the dependency proxy, GitLab first checks for the package in the project. If it’s not found, GitLab then attempts to pull the package from the external repository.

When a package is pulled from the external repository, it’s imported into the GitLab project. The next time that particular package is pulled, it’s pulled from GitLab and not the external repository. Even if the external repository is having connectivity issues and the package is present in the dependency proxy, pulling the package still works, making your pipelines faster and more reliable.

If the package changes in the external repository (for example, a user deletes a version and publishes a new one with different files) the dependency proxy detects it. It invalidates the package, so GitLab pulls the newer one. This ensures the correct packages are downloaded, and helps reduce security vulnerabilities.


Deeper insights into velocity in the Issue Analytics report

The Issue Analytics report now contains information on the number of closed issues in a month to allow for a detailed velocity analysis. With this valuable addition, GitLab users can now gain insights into trends associated with their projects, and improve the overall turn-around time and value delivered to their customers. The Issue Analytics visualization contains a bar chart with the number of issues for each month, with a default time span of 13 months. You can access this chart from the drill-down in the Value Streams Dashboard.

Deeper insights into velocity in the Issue Analytics report

New organization-level DevOps view with DORA-based industry benchmarks

We added a new DORA Performers score panel to the Value Streams Dashboard to visualize the status of the organization’s DevOps performance across different projects. This new visualization displays a breakdown of the DORA score (high, medium, or low) so that executives can understand the organization’s DevOps health top to bottom.

The four DORA metrics are available out-of-the-box in GitLab, and now with the new DORA scores organizations can compare their DevOps performance against industry benchmarks or peers. This benchmarking helps executives understand where they stand in relation to others, and identify best practices or areas where they might be lagging behind.

To help us improve the Value Streams Dashboard, please share feedback about your experience in this survey.

New organization-level DevOps view with DORA-based industry benchmarks

Other improvements in GitLab 16.8

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

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

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.

View blame information directly in the file page

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:

Bug Fixes:

The list of all changes is in the GitLab Runner CHANGELOG.

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.

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

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

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.

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

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.

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.

View all ancestor items of a task or OKR

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.

View all ancestor items of a task or OKR

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

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

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.

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

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.

Enforce policy to prevent branches being deleted or unprotected

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.

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.

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.

SAML SSO authentication for merge request approval

Believe it

Get unlimited access to all JiHu GitLab Premium features for 60 days.