gitlab-org/gitlab-ce v16.4.0

on GitLab

Allowing developers access to Kubernetes clusters requires either developer cloud accounts or third-party authentication tools. This increases the complexity of cloud identity and access management. Now, you can grant developers access to Kubernetes clusters using only their GitLab identities and the agent for Kubernetes. Use traditional Kubernetes RBAC to manage authorizations within your cluster.

Together with the OIDC cloud authentication offering in GitLab pipelines, these features allow GitLab users to access cloud resources without dedicated cloud accounts without jeopardizing security and compliance.

In this first iteration of cluster access, you must manage your Kubernetes configuration manually. Epic 11455 proposes to simplify setup by extending the GitLab CLI with related commands.

If you need to trigger a downstream pipeline from a CI/CD pipeline job, you can use the trigger keyword. To enhance your deployment management, you can now specify an environment with the environment keyword when you use trigger. For example, you might trigger a downstream pipeline for the main branch on your /web-app project with environment name dev and a specified environment URL.

Previously, when you ran separate pipelines for CI and CD and used the trigger keyword to start the CD pipeline, specifying environment details was not possible. This made it hard to track deployments from your CI project. Adding support for environments simplifies deployment tracking across projects.

• GitLab 16.4 includes packages for OpenSUSE 15.5.
  

To provide as many opportunities for automation and integration with third-party systems as possible, we have added support for creating webhooks that trigger when a user adds or revokes an emoji reaction.

You could use the new webhook, for example, to send an email when users react to issues or merge requests with emoji.

GitLab can send messages to Slack workspace channels for certain GitLab events. With this release, you can now trigger Slack notifications for group mentions in public and private contexts in:

• Issue and merge request descriptions
  
• Comments on issues, merge requests, and commits
  

We recently turned a few hardcoded import limits into configurable application settings to allow self-managed
GitLab administrators to adjust these limits according to their needs.

In this release, we've added the timeout for decompressing archived files as a configurable application setting.

This limit was hardcoded at 210 seconds. On GitLab.com, and for self-managed installations by default, we've set this limit to 210 seconds. Both self-managed GitLab and
GitLab.com administrators can adjust this limit as needed.

In GitLab 15.9 we announced the deprecation of older versions of JSON web tokens in favor of id_token. Unfortunately, jobs had to be modified individually to accommodate this change. To enable a smooth transition to id_token, beginning from GitLab 16.4, you can set id_tokens as a global default value in .gitlab-ci.yml. This feature automatically sets the id_token configuration for every job. Jobs that use OpenID Connect (OIDC) authentication no longer require you to set up a separate id_token.

Use id_token and OIDC to authenticate with third party services. The required aud sub-keyword is used to configure the aud claim for the JWT.

Users with the Maintainer role for a group can now view details for group runners. Users with this role can view group runners to quickly determine which runners are available, or validate that automatically created runners were registered successfully to the group namespace.

We're also releasing GitLab Runner 16.4 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:

• Add queue duration histogram metric to the runner Prometheus metric endpoint
  

Bug Fixes:

• Kubernetes runner pods not cleaned up in GitLab Runner 16.3.0
  
• gitlab-runner-helper terminated during cache downloading
  

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

GitLab SAST includes many security analyzers that the GitLab Static Analysis team actively maintains, updates, and supports. We published the following updates during the 16.4 release milestone:

• Updated the KICS-based analyzer to version 1.7.7 of the KICS scanner. See the CHANGELOG for further details.
  
• Updated the Sobelow-based analyzer to version 0.13.0 of the Sobelow scanner. We also updated the base image for the analyzer to Elixir 1.13 to improve compatibility with more recent Elixir releases. See the CHANGELOG
  
• Updated the PMD Apex-based analyzer to version 6.55.0 of the PMD scanner. See the CHANGELOG for further details.
  
• Changed the PHPCS Security Audit-based analyzer to remove the Security.Misc.IncludeMismatch rule. See the CHANGELOG for further details.
  
• Updated the rules used in the Semgrep-based analyzer to fix rule errors, fix broken links in rule descriptions, and resolve conflicts between Java and Scala rules that had the same rule IDs. We also increased the maximum size of custom rule files to 10 MB. See the CHANGELOG for further details.
  

If you include the GitLab-managed SAST template (SAST.gitlab-ci.yml) and run GitLab 16.0 or higher, you automatically receive these updates.
To remain on a specific version of any analyzer and prevent automatic updates, you can pin its version.

For previous changes, see last month's updates.

Service Desk is one of the most meaningful connections between your business and your customers. Now you can use your own custom email address to send and receive emails for Service Desk.
With this change, it is much easier to maintain brand identity and instill customer confidence that they are communicating with the correct entity.

This feature is in Beta. We encourage users to try Beta features and
provide feedback in the feedback issue.

Group and project access tokens are frequently used for automation. It is important that administrators and group Owners are notified when one of these tokens is close to expiry, so interruptions are avoided. Administrators and group Owners now receive a notification email when a token is seven days or less away from expiry.

A user will get an email notification seven days before their group or project access expires. This only applies if there is an access expiration date set. Previously, there were no notifications when access expired. Advance notice means you can contact your GitLab administrator to ensure continuous access.