Jul 22, 2022 - Sam Kerr  
15.2

GitLab 15.2 released with live wiki diagram previews and redesigned merge request reports

GitLab 15.2 released with Live preview diagrams in the wiki WYSIWYG editor, Incident Timelines, Group and subgroup scan execution policies, Change failure rate chart for visualizing software stability, and much more!

Today, we are excited to announce the release of GitLab 15.2 with Live preview diagrams in the wiki WYSIWYG editor, Incident timelines, Group and subgroup scan execution policies, Change failure rate chart for visualizing software stability, and much more!

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

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

GitLab MVP badge

This month's Most Valuable Person (MVP) is kyrie.31415926535

This month we are thrilled to recognize someone nominated in 15.1 for their contributions to improving the security of all GitLab users! kyrie.31415926535 contributed changes that prevent users from adding weak SSH keys. The best place to stop a security problem is before it starts. This change serves as an additional safeguard to protect GitLab accounts from compromise.

Thank you so much kyrie.31415926535 for your contribution!

Key improvements released in GitLab 15.2

Live preview diagrams in the wiki WYSIWYG editor

GitLab Flavored Markdown includes extensions to support Mermaid, PlantUML, and Kroki diagrams but writing anything other than the most basic diagrams can be cumbersome without a live preview. You can toggle between the raw source and static preview and there are external tools you can use to write these diagrams, but the shift away from your content can be distracting.

GitLab 15.2 introduces a live rendered preview of your diagram in the wiki’s WYSIWYG editor. Now, as you write your diagram in a specialized code block we will detect the diagram type and display a preview icon. When enabled, the live preview renders above the code block and updates as you type, so you can ensure your formatting is correct and the output will be exactly what you expect.

Live preview diagrams in the wiki WYSIWYG editor

Merge request reports redesign

Merge request reports are an important part of code review, providing insights into the impact of changes and improvements to meet project standards.

Report widgets now all follow design guidelines for layout, hierarchy, and content sections, making them consistent, scannable, and utilitarian. These improvements make it easier for you to find actionable information in each report.

Merge request reports redesign

Enforce IP address restrictions for Git over SSH

Limiting access to requests from a trusted set of IP addresses may improve security. Until now, only the API and UI supported such access restrictions; SSH access was blocked entirely. SSH now also adheres to this restriction, and grants access only to requests coming from IP addresses in your list.


Change failure rate chart for visualizing software stability

In this release, we added a new trend chart for the DORA Change failure rate metric. This chart shows the percentage of deployments that cause an incident in a production environment. GitLab measures the change failure rate as the number of incidents divided by the number of deployments to a production environment during a given time period.

This is the fourth DORA chart available in GitLab that provides insights into value stream velocity and reliability trends.

Change failure rate chart for visualizing software stability

Group and subgroup scan execution policies

Your security and compliance teams can now apply policies uniformly to all projects by scanning execution policies at the group and subgroup levels. This functionality is especially helpful for large organizations who have a large number of projects. Policies defined for the group or subgroup will flow down and apply to all child projects. To get started, ask your group owner to link a security policy project to your group on the Security & Compliance > Policies page.

Currently scan execution policies are the only policy type that is supported at the group and subgroup levels. You can track the efforts to add group and subgroup level support for scan result policies in this epic.

Group and subgroup scan execution policies

Incident timeline

Capturing what happened during an incident is an important practice that facilitates learning and the opportunity for improvement. Yet, asking incident responders to take on additional administrative tasks when they’re busy fire-fighting, or trying to reconstruct the timeline of events post incident lead to incomplete or less than accurate information.

GitLab incident timeline is designed to make information capture during an incident, or post incident, easy and efficient. In the Incident timeline MVC, we make it possible to add new timeline events manually, delete a timeline event, and view the incident timeline in a dedicated tab within an incident issue.


Set the image pull policy in pipeline configuration

You can select different pull policies for how a GitLab Runner downloads Docker images in CI/CD jobs. always (the default behavior) ensures the image is always downloaded, if-not-present downloads an image only when a local version does not exist, and never only uses the local version (never download an image).

Previously, you could define the pull policy only at the runner level. In this release we’ve added the ability to define the pull policy at the pipeline level. Use pull_policy in your .gitlab-ci.yml to define different pull policies at the job or pipeline level. This feature is not supported by shared runners.

Set the image pull policy in pipeline configuration

Other improvements in GitLab 15.2

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.

Audit events for group-level merge request settings

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.

Filter jobs by status on the jobs page

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!

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.

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.

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.

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!

Verification token displayed in 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.

Programmatically delete duplicate package assets

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.

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.

Edit protected environment approvals in project 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.

Group-level UI for protected environment settings

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.

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.

Bug fixes

Some of the notable bug fixes in 15.2 are:

Performance improvements

In every release, we continue to make great strides improving GitLab’s performance. We’re committed to making every GitLab instance faster. This includes GitLab.com, an instance with over 1 million registered users!

In GitLab 15.2, we’re shipping performance improvements for issues, projects, milestones, and much more! Some improvements in GitLab 15.2 are:

Usability improvements

In every release, we make great strides in improving the overall effectiveness and usefulness of our product.

We also have a UI Polish Gallery to track important updates to our interfaces. These updates, while often small, improve your user experience.

In GitLab 15.2, we’re shipping usability improvements for issues, projects, milestones, and much more! We highlight the following changes in GitLab 15.2:

Deprecations

New deprecations and the complete list of all features that are currently deprecated can be viewed in the GitLab documentation.

  • Remove `job_age` parameter from `POST /jobs/request` Runner endpoint
  • Removals and breaking changes

    The complete list of all removed features can be viewed in the GitLab documentation.

    Other notable changes

    self_signed_cert key in gitlab_shell['http_settings'] is removed

    In an update to the GitLab Shell, the option to validate self-signed certificates was deprecated and removed in GitLab 14.8 because it allowed for man-in-the-middle attacks. Gitaly has been updated to reflect this deprecation and removed gitlab_shell['http_settings'] as well.

    Changelog

    Please check out the changelog to see all the named changes:

    Installing

    If you are setting up a new GitLab installation please see the download GitLab page.

    Updating

    Check out our update page.

    Questions?

    We'd love to hear your thoughts! Visit the GitLab Forum GitLab Forum and let us know if you have questions about the release.

    GitLab Subscription Plans
    • Free: Free-forever features for individual users
    • Premium: Enhance team productivity and coordination
    • Ultimate: Organization wide security, compliance, and planning

    Try all GitLab features - free for 30 days

    Cover image licensed under CC0

    Try all GitLab features - free for 30 days

    GitLab is more than just source code management or CI/CD. It is a full software development lifecycle & DevOps tool in a single application.

    Try GitLab Free
    Open in Web IDE View source