Apr 22, 2022 - Brian Rhea  

GitLab 14.10 released with individual compliance violation reporting and a UI for streaming audit events

GitLab 14.10 released with individual compliance violation reporting, a UI for streaming audit events, GitLab Runner Operator for Kubernetes, and much more!

Today, we are excited to announce the release of GitLab 14.10 with Compliance report individual violation reporting, a UI for streaming audit events, GitLab Runner operator for Kubernetes, escalating manually created incidents 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 preview what's coming in next month’s release, check out our Upcoming Releases page, which includes our 15.0 release kickoff video.

GitLab MVP badge

This month's Most Valuable Person (MVP) is Jeremy Wu

Jeremy added a user interface for streaming audit events to GitLab that provides an easy way for users, including non-technical users, to get started with streaming audit events, rather than needing to use the API.

Thanks to this contribution, users can now easily add and remove streaming audit event destinations as well as see the list of existing streaming audit event destinations.

Great work! Thank you, Jeremy! 🙌

Key improvements released in GitLab 14.10

Compliance report individual violation reporting

The compliance report now reports every individual merge request violation for the projects within a group. This is a huge improvement over the previous version, which only showed the latest MR that had one or more violations. The new version allows you to see history and patterns of violations over time.

These violations are individually listed so you can see what caused a violation, who was involved, and when it happened. You can select a violation to show even more information about the merge request that caused it. For more information, see the list of violation types.

We are happy to have also added several quality of life features, including both filtering and sorting, to help you find what you are looking for quickly.

Compliance report individual violation reporting

GitLab Runner Operator for Kubernetes

In GitLab 13.10, we released the GitLab Runner Operator for the Red Hat OpenShift container platform for Kubernetes. That release provided OpenShift users with the automation and management capabilities of the Operator Framework and simplified the ongoing management of runners in an OpenShift Kubernetes cluster. Available starting in 14.10 is a GitLab Runner Operator v1.7.0 that you can use in non-OpenShift Kubernetes clusters. This GitLab Runner Operator is available on OperatorHub.io.

User interface for streaming audit events

You can now use the GitLab UI to set up streaming audit events in your groups! Access it under the new Streams tab in the group audit events page.

This screen makes it easy to:

  • Add and remove streaming audit event destinations.
  • See the list of locations streaming audit events are being sent to.

Thank you to Jeremy Wu from JiHu for this contribution!

User interface for streaming audit events

Escalating manually created incidents

Incident Management is set up to trigger escalation policies for new alerts. In this scenario, the on-call responder who is paged can end the paging by acknowledging the alert. If the responder changes the status back to triggered, we restart the escalation policy and begin paging again. When a user creates an incident manually, there is no associated alert and therefore no way to page on-call responders.

This release enables paging on manually created incidents. Responders now have the ability to acknowledge the page on incidents, or restart paging by resetting the status to triggered, just as you can for alerts.

Escalating manually created incidents

New DORA metric API: Change failure rate

In this release, we have added the fourth DORA metric API, change failure rate. GitLab measures the change failure rate as the number of incidents divided by the number of deployments to a production environment in the given time period. The DORA metrics enable executives who are investing in DevOps transformation to understand ROI on processes they are implementing and tools they have purchased. Changes in these metrics easily become KPIs for those teams.

New DORA metric API: Change failure rate

Other improvements in GitLab 14.10

Importing from GitHub defaults to the current group path

When importing from GitHub, this milestone changes the default destination for imported projects to the contextual namespace of the GitLab group from which you started the import. Previously, GitHub projects imported to your personal namespace. This usability enhancement helps users import projects in a more intuitive way and doesn’t place imported projects in confusing locations.

Incremental repository backups reduce backup time

We are pleased to offer our self-managed customers an opportunity to use our preliminary incremental backup offering. After you take at least one full backup, you can run subsequent incremental backups that only pack repository changes since the last backup into the backup bundle. This dramatically reduces backup time.

While this is available now, we want to clarify that each incremental backup overwrites the last incremental backup, and remind you that this is our MVC.

Please feel free to try out this exciting new feature and don’t hesitate to provide feedback!

See our Repository level incremental backup epic for updates on progress on this feature!

Create pipeline schedules for tags in the UI

Previously, if you wanted to create a pipeline schedule for tags, you had to use the API. The simpler method of using the pipeline schedules UI could only be used for branches.

Now, when you use the pipeline schedules UI, you can choose from either branches or tags as needed, and no longer need to use the API! Thanks @KevSlashNull for this contribution!

GitLab Runner 14.10

We’re also releasing GitLab Runner 14.10 today! GitLab Runner is the lightweight, highly-scalable agent that runs your build 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:

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

Faster, easier Java scanning in SAST

GitLab Static Application Security Testing (SAST) now uses Semgrep to scan Java code, building on previous support for Go (introduced in GitLab 14.4) and for JavaScript, TypeScript, and Python (introduced in GitLab 13.12).

The Semgrep-based analyzer runs significantly faster—up to 7 times faster in our testing than the existing analyzer that’s based on SpotBugs. It also doesn’t need to compile your code before scanning, so it’s much simpler to use than SpotBugs.

The Static Analysis and Vulnerability Research teams worked together to translate rules to the Semgrep format, preserving most existing rules. We also updated, refined, and tested the rules as we converted them.

If you use the GitLab-managed SAST template (SAST.gitlab-ci.yml), both Semgrep and SpotBugs now run whenever Java code is found. In GitLab Ultimate, the Security Dashboard combines findings from the two analyzers, so you won’t see duplicate vulnerability reports.

In a future release, as we announced, we’ll change the GitLab-managed SAST template (SAST.gitlab-ci.yml) to only run the Semgrep-based analyzer for Java code. The SpotBugs-based analyzer will still scan other JVM languages like Groovy, Kotlin, and Scala.

If you have any questions, feedback, or issues with the new Semgrep-based Java scanning, please file an issue, we’ll be glad to help.

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 14.10 release milestone. These updates bring additional coverage, bug fixes, and improvements.

  • Gosec analyzer updated to version 2.11.0. See CHANGELOG for details.
    • Add rule for potential directory traversal through http.Dir("/")
    • Detect minimum TLS version even when declared in a different file within the package
  • Kics analyzer updated to version 1.5.5. See CHANGELOG for details.
    • Add new rules
    • Fix existing rules
    • Delete redundant rules
  • PMD analyzer updated to version 6.44.0. See CHANGELOG for details.
    • Add Java 18 support
    • Fix rules
  • Secrets analyzer updated to version 8.6.1. See CHANGELOG for details.
    • Add entropy values to all findings
    • Skip content checks for rules that are only based on file paths
    • Add ability to skip a finding if gitleaks:allow is included in the same line as a detected secret
  • Semgrep analyzer updated to version 0.86.5. See CHANGELOG for details.
    • Support Go 1.18 generics
    • Additional bug fixes and performance improvements

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.

Install the agent for Kubernetes with Helm

The GitLab agent for Kubernetes has a component that needs to be installed into the user cluster. Previously, we provided a Docker-based one-liner installer and a Kpt-based advanced installation method. As Helm is an often requested method for installing Kubernetes applications, we are replacing the Docker-based installer with a Helm package.

Thanks to Eamonn McCudden’s (@emctl) contribution, the GitLab agent for Kubernetes can be installed into a user cluster from a Helm package. This facilitates the installation of the agent into the cluster as well as automating with Terraform. We have replaced the Docker-based installation method with the new Helm package as we expect users to have helm installed on the local machines.

The Helm package exists on both the charts.gitlab.io and ArtifactHUB repositories.

Security policy management user experience improvements

Several initiatives to improve the user experience for managing security policies were completed in GitLab 14.10:

  • A new workflow for selecting the policy type when creating a new policy.
  • Validation of the YAML syntax when saving changes, including specific details when errors are encountered.
  • A more consistent experience for the policy details drawer across policy types, including a text description of the policy.
  • Previously, only project Owners were able to see information about the policy management project. Other roles can now see a button on the Policy page indicating the policy management project’s location.
  • Various other improvements to performance, design, and handling of error states.

To get started with GitLab Security Policies, navigate to a project > Security & Compliance > Policies.

GitLab chart improvements

View history of all project imports on a single page

The new Project import history page lists all project imports, regardless of where they were imported from. This view consolidates information that was previously scattered on the import pages of each individual importer.

Having all the details about previous imports in one view gives you a single place to find and review the status of all previous imports. This includes details on imports that failed, so that you can verify that you successfully imported all the intended projects.

View history of all project imports on a single page

CI/CD Limits set at the Instance Level

To contain resource usage in support of instance stability, GitLab administrators of instances with high CI/CD usage might want to add limits for specific CI/CD events. This could be to set the maximum number of jobs in a single pipeline, the maximum number of concurrent jobs in active pipelines, or the maximum number of scheduled pipelines per project.

GitLab instance administrators can now set these limits (and others) directly in the instance’s Admin Area panel.

Expanded view of group runners

Group runners are now displayed in an expanded view, where you can more easily administer and manage the runners associated with the namespace. To view the new UI, on the left sidebar, select CI/CD. This view includes the number of online, offline, and stale runners associated with the group and subgroups.

Expanded view of group runners

Improved pipeline variables inheritance

Previously, it was possible to pass some CI/CD variables to a downstream pipeline through a trigger job, but variables added in manual pipeline runs or by using the API could not be forwarded.

In this release we’ve added a new trigger:forward keyword to control what things you forward to downstream parent-child pipelines or multi-project pipelines, which provides a flexible way to handle variable inheritance in downstream pipelines.

Manually create a Vulnerability Record

Vulnerability Management in GitLab processes and aggregates security findings from our many Secure scanners, and can seamlessly incorporate results from integrated 3rd-party scanners. While this provides valuable security information in a unified experience, it limits Vulnerability Management to only those vulnerabilities picked up by currently supported tools.

We’re introducing the ability to manually create vulnerability records to greatly expand the use cases Vulnerability Management can handle. Leveraging our recently-released ability to create vulnerability records through the API, making a new vulnerability record is as simple as entering a few required pieces of information. With manually created vulnerability records you can provide additional details supported by vulnerability records, including the severity, identifiers and suggested solution. You can view manually created records in the Group, Project, and Security Center Vulnerability Reports. And you can move records through your triage and remediation workflows like you would any scanner-detected vulnerability.

Manually create a Vulnerability Record

Multiple approval rules for deployment approvals API

Previously, deployment approvals supported a simple model where the ability to execute a deployment and approve a deployment were both controlled with a single list of users. With this update, you have more flexibility and granularity with these rules and can specify multiple levels of control using the API. One type of model that can now be supported is where there is separation of duties between deployment executors and approvers in your organization. Another supported model is where approval is needed separately from multiple levels, such as a QA tester group and a security group.

Upload metric screenshots to an Alert

GitLab 13.2 introduced the metrics tab in GitLab alerts. However, with the deprecation of GitLab Managed Apps and alerts on the Metrics page, metrics no longer automatically populate on new alerts and are difficult to support on old ones. This release completes the deprecation of the old metrics functionality, and introduces the ability to add a screenshot to alerts, similar to how screenshots can be added to incidents. Having a screenshot of the metric that triggered the alert helps responders triage alerts more efficiently.

Geo verifies CI job artifacts

Geo automatically verifies the data integrity of replicated CI job artifacts. This ensures that artifacts are not corrupted in transfer or at rest. If Geo is used as part of a disaster recovery strategy, this protects customers against data loss.

Omnibus improvements

  • GitLab 14.10 includes Mattermost 6.5, whose newest release includes custom groups, cross-team channel navigation, playbook import, export, and duplication, improved board sharing, Bitbucket integration, workplace optimization, improved onboarding experiences, Persian language support, plus more! This version also includes security updates and upgrade from earlier versions is recommended.

Bug fixes

Some of the notable bug fixes in 14.10 are:

Performance improvements

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

In GitLab 14.10, we’re shipping performance improvements for issues, projects, milestones, and much more! Some improvements in GitLab 14.10 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 14.10, we’re shipping usability improvements for issues, projects, milestones, and much more! We highlight the following changes in GitLab 14.10:


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

  • Dependency Scanning default Java version changed to 17
  • Manual iteration management
  • Outdated indices of Advanced Search migrations
  • Toggle notes confidentiality on APIs
  • Removals and breaking changes

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

    Other notable changes

    NFS for Git repository storage support extended to November 22, 2022

    We announced during the release of GitLab 14.0 our intention to stop supporting NFS for Git repository storage in GitLab 15.0. After consulting with both customers and internal teams, we have decided to extend customer support until November 22, 2022.

    Java 17 now the default version in dependency scanning

    In GitLab 15.0, for Dependency Scanning, the default version of Java that the scanner expects will be updated from 11 to 17. Java 17 is the most up-to-date Long Term Support (LTS) version. Dependency scanning continues to support the same range of versions (8, 11, 13, 14, 15, 16, 17), only the default version is changing. If your project uses the previous default of Java 11, be sure to set the DS_Java_Version variable to match.

    Permissions change for downloading Composer dependencies

    In GitLab 14.10, a breaking change was released for the Composer repository. You must now authenticate when you download Composer dependencies.

    Important notes on upgrading to GitLab 14.10

    • The upgrade to GitLab 14.10 executes a concurrent index drop of unneeded entries from the ci_job_artifacts database table. This could potentially run for multiple minutes, especially if the table has a lot of traffic and the migration is unable to acquire a lock. It is advised to let this process finish as restarting may result in data loss.


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


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


    Check out our update page.


    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