Audit events for group-level merge request settings
GitLab now records additional audit events when changes are made to group-level merge request settings. These are in addition to project
audit events that record changes to the same settings on projects. Specifically, audit events are now created when changes are made to groups to:
- Prevent approval by author
- Prevent approvals by users who add commits
- Prevent editing approval rules in projects and merge requests.
- Require user password to approve
- Remove all approvals when commits are added to the source branch
These audit events can help you know that the settings and default configurations for your group-level merge request settings have been put in place correctly and that they have not been changed. This is especially important because these group-level settings
will cascade down to child projects. Governance and visibility over these changes will help you strengthen separation of duties and further simplify audits.
Custom HTTP headers for streaming audit events
You can now add custom HTTP headers to be sent with streaming audit events! This improvement
makes it easier to integrate with 3rd-party systems that require specific headers on
messages they receive. Custom headers can be used to do things like adding authentication information, adding
routing information, or tagging which project an event came from.
Previously, you had to use a proxy server to add
these custom headers to streaming audit events. Setting up this proxy was time-consuming, error prone,
and added additional complexity to your organization. Setting custom headers directly within GitLab
makes integrating with other tools and driving automation much simpler and allows you to do what you
need directly within the GitLab platform.
To add custom HTTP headers, use our GraphQL APIs
to add a new header as a key/value pair. You can also update and remove headers.
Enforce per-plan webhook rate limits
Webhook rate limits will now be enforced for GitLab.com users to protect the performance and availability of the GitLab application. In return, the limit protects performance for all tenants. Limits are applied per plan and per namespace and are based on the number of seats in your subscription, starting at 500 and up to 13,000 calls per minute per top-level namespace.
Streaming audit events for Git operations
You can now monitor the Git activity inside your groups with new audit events that are recorded when users push to or
pull from repositories. This will include information such as the user name, the timestamp, and the project that was pulled from or pushed to.
These events generate a high volume of data, so they are only available as
streaming audit events.
Streaming audit events for project forks
You can now monitor the project forking inside your groups with new audit events that are recorded whenever
a project is forked. This includes information such as:
- The user name of the user that forked the project.
- The timestamp of when the project was forked.
- Details of the forked project.
This gives you visibility on where your projects and source code are being copied to, and by
whom, so that you can take action if needed.
These events potentially generate a high volume of data, so they are only available as
streaming audit events.
Thank you Linjie Zhang for this contribution!
Improved and faster file browsing and syntax highlighting
In recent months, we made multiple changes to improve the experience of browsing a repository and viewing source files. Rather than reloading the full page when moving from folder to folder, we now display repository files and folders with a single VUE application. Our repository tree view is more performant and stable now, and working with files is faster. We’ve also switched from server-side transformations for files to client-side syntax highlighting. The rendering time for large files is now up to 66% faster.
Filter jobs by status on the jobs page
When you’re troubleshooting a pipeline that is behaving unexpectedly, you may want to filter for the jobs with a particular status. Previously, that would require looking at the full list of jobs or use the GitLab API to manipulate the data outside of GitLab.
Now you can filter jobs by their status directly on the job page, so you can see all jobs with the same status in your project.
Predefined CI/CD variable for project description
GitLab CI/CD provides many useful predefined CI/CD variables out-of-the-box, but did not have one for your project’s description. In this release we now have the CI_PROJECT_DESCRIPTION predefined variable, which makes it easy for you to access the project description from within a CI/CD job. Thank you to @nejc for this contribution!
API to retrieve agent server (KAS) metadata
After we released the agent for Kubernetes, one of the first requests we got was for an automated way to set it up. In the past months, Timo implemented a REST API and extended the GitLab Terraform Provider to support managing agents in an automated way. The current release further improves management of the agent specifically, and of GitLab in general, by introducing a /metadata REST endpoint that is the superset of the /version endpoint.
The /metadata endpoint contains information about the current GitLab version, whether the agent server (KAS) is enabled, and where it can be accessed. This change improves upon the previous functionality, where you had to put the KAS address in your automation scripts manually.
Fetch secrets based on deployment tier
Secrets can be assigned based on the deployment tier of an environment. In this release, we include the deployment_tier in the JSON Web Token (CI_JOB_JWT) so that users can fetch secrets per a specific deployment tier.
Updated cluster version support, including Kubernetes 1.23 and 1.24
If you use Kubernetes, GitLab wants to ensure you have full functionality when you upgrade your clusters to the most recent Kubernetes version. While many of you use GitLab to deploy your Kubernetes clusters, until recently there was no official support for Kubernetes 1.23 and 1.24. This release brings full support for all of the Kubernetes-related features from those versions.
Together with providing support to Kubernetes version 1.23 and 1.24, we are changing our Kubernetes support policy to be more predictable than it was in the past. With the new support policy, we plan to add support to every new Kubernetes minor version three months after the initial release, and we will support the last three Kubernetes minor versions.
License compliance support for Gradle implementation directive
Gradle 6 introduced a new implementation directive for defining dependencies. Beginning with Gradle 7, this new directive became mandatory and replaced the previous compile directive. GitLab 15.2 introduces support for detecting dependencies that are introduced using this new directive.
Omnibus improvements
- GitLab 15.2 includes Mattermost 7.0, with the general availability of Collapsed Reply Threads, voice calls and screen share (beta), messaging format toolbar, Playbooks inline editor, usage statistics, and the ability to change triggers and actions mid-run. This version also includes security updates and upgrade from earlier versions is recommended.
Audit events when two-factor authentication is disabled
GitLab now records an audit event when a user disables their two-factor authentication (2FA) settings.
This audit event helps you ensure that all the users in your instance are properly using
2FA (and identify when the security of a user’s account has been lowered),
so that you can investigate and take action.
Disable user 2FA using API
Administrators can disable 2FA for specific users using the API. This is useful when a user has lost or forgotten their backup codes for their primary token generator.
After the administrator disables 2FA for that user, the user can set up 2FA from scratch.
Improvements to users’ contribution calendar for private contributions
We fixed an issue where private contributions did not display in users’ contribution calendar graph. Now when you select Include private contributions on my profile in your profile settings, private contributions remain visible even when you’re removed from a project.
Streaming audit events for merge request creation
You can now monitor with audit events when merge requests are created inside your groups. The audit event includes information like:
- User name of the merge request author.
- Creation timestamp.
- Details of the newly-created merge request.
This gives you visibility of the activity inside your projects and source code so that you can take action if needed.
These events generate a high volume of data, so they are only available as
streaming audit events.
Thank you Linjie Zhang for this contribution!
Verification token displayed in UI
The GitLab UI now displays the verification token value
for each streaming destination! This makes it easy to quickly see what the value is,
check it against logs you see, or copy it to other tools that will receive the streaming
audit event data.
Previously, if you needed to get this value, you had to use an API
to list all audit destinations in a group and find the value. This was complicated and an
extra step, so we are excited to make this much easier by putting the value directly in the UI!
Persist last used Wiki editor
The WYSIWYG editor was introduced in the wiki way back in GitLab 14.0 allowing you to write Markdown using visual formatting tools and a giving you a real-time preview of your content as you write. However, since its release, you had to manually switch to use the WYSIWYG editor every time to started editing a wiki page.
GitLab 15.2 will now persist your last used editor in the wiki. You’ll save time when editing consecutive pages by jumping right into your preferred experience without having to switch between editors every time.
GitLab Runner 15.2
We’re also releasing GitLab Runner 15.2 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.
Bug Fixes:
The list of all changes is in the GitLab Runner CHANGELOG.
Programmatically delete duplicate package assets
You use the GitLab Package Registry to publish and share your project’s packages. When a package is published, it includes package assets. For example, each time you publish a Maven package, it includes a pom and jar package. Some formats, such as Maven, NuGet, and generic packages, allow you to publish duplicate packages, resulting in hundreds or thousands of duplicate package assets. In previous versions of GitLab, you would only be able to delete these assets one at a time using the user interface or the API. Now you can use a cleanup policy to define a maximum number of duplicate assets to keep. For example, if you define a cleanup policy to preserve five duplicate versions of an asset, only the five most recent assets are kept the next time the policy runs.
The introduction of cleanup policies for Packages helps reduce the amount of storage used for your project and makes it easier to navigate the user interface by reducing clutter.
Edit protected environment approvals in project settings
Previously, to edit the number of approvals required for deployment to a protected environment, you had to use the API, which could be cumbersome. Starting in 15.2, you can edit the number of required approvals directly in the project’s settings.
Group-level UI for protected environment settings
Previously, if you wanted to configure group-level settings for protected environments, you had to use the API. With this release, you can now view and edit these settings in the UI. This change allows you to more easily set policies for which users and groups can deploy to environments across projects within a group.
Faster Secret Detection
We’ve optimized GitLab Secret Detection to use a new technique that cuts scan times by skipping expensive operations when they can’t possibly match.
The analyzer now first scans for exact strings before running full matching rules.
This optimization significantly reduces scan duration in our testing, cutting scan times by 50–75% in medium-sized repositories.
It works for secrets that have a defined prefix or known identifier; for example, GitLab Personal Access Tokens start with glpat- by default.
We’ve updated the built-in secret detection rules to use this faster method.
If you’ve added custom rules, you can optimize them by setting a keywords value for them in your custom GitLeaks TOML configuration file.
At least one string in keywords must match before the regular expression pattern runs.
We hope to make this optimization easier to apply in the future after delivering this first iteration.
Static Analysis analyzer updates
GitLab Static Analysis includes many security analyzers that the GitLab Static Analysis team actively manages, maintains, and updates. The following analyzer updates were published during the 15.2 release milestone. These updates bring additional coverage, bug fixes, and improvements.
- CodeClimate analyzer updated to version 0.85.29. See CHANGELOG for details.
- Add support for
eslint-8 channel.
- Don’t analyze files or allow LinkLocal addresses in
prepare step.
- Kics analyzer updated to handle exit codes better. See CHANGELOG for details.
- Kubesec analyzer updated to include Kubesec 2.11.5 and Helm 3.9.0, and to handle an issue with helm output. See CHANGELOG for details.
- PMD-Apex analyzer updated to version 6.45.0. See CHANGELOG for details.
- Semgrep analyzer engine updated to version 0.98.0. See CHANGELOG for details.
- Improve performance, fix bugs, and otherwise improve scanning engine.
- Bypass language-based matcher (which decides whether to run the scanning process) if you define custom rules. This makes it easier for you to define custom rules for languages that aren’t covered in GitLab-managed rulesets.
- Secrets analyzer updated to remove built-in rules for Social Security Numbers (SSNs) and apply new optimizations. See CHANGELOG for details.
If you include the GitLab-managed SAST template (SAST.gitlab-ci.yml), you don’t need to do anything to receive these updates. However, if you override or customize your own CI/CD template, you need to update your CI/CD configurations.
To remain on a specific version of any analyzer, you can pin to a minor version of an analyzer. Pinning to a previous version prevents you from receiving automatic analyzer updates and requires you to manually bump your analyzer version in your CI/CD template.
For previous changes, see last month’s updates.
Geo supports BuildKit cache images
With GitLab 15.2, Geo supports replication of BuildKit cache images. With the support of the BuildKit cache image format in GitLab 15.2, and the addition of support for OCI container images in GitLab 15.1, Geo now supports a broader list of container types.
GitLab chart improvements
- When using the horizontal pod autoscaler to automatically scale the number of pods in a Kubernetes deployment of GitLab (in this case, Gitlab.com), we noticed that scaling behavior can be erratic due to the spiky nature of the CPU profile being observed. To see less rapid scaling events we have added support for
v2beta2 and v2 which add significantly more control over scaling events.
We want to hear from you
Enjoyed reading this blog post or have questions or feedback? Share your thoughts by creating a new topic in the GitLab community forum.
Share your feedback