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

Today, we are excited to announce the release of JiHu GitLab 14.10 with Compliance report individual violation reporting, a UI for streaming audit events, JiHu 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.

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 JiHu GitLab 14.10

Compliance report individual violation reporting

SaaS

私有化部署版

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

Documentation Issue

GitLab Runner Operator for Kubernetes

SaaS

Self-managed

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.

Documentation Issue

User interface for streaming audit events

SaaS

Self-managed

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!

Documentation Issue

User interface for streaming audit events

Escalating manually created incidents

SaaS

Self-managed

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.

Documentation Issue

New DORA metric API: Change failure rate

SaaS

Self-managed

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.

Documentation Issue