GitLab.org/GitLab: Release v14.10.0-ee

Name: GitLab

Released: 2022-04-22

License: MIT

Release Assets:

![23 new features](https://img.shields.io/static/v1?color=108548&label=new+features&labelColor=525252&message=23&style=for-the-badge "New features added in this release") ![2453 total badges](https://img.shields.io/static/v1?color=1F75CB&label=total+features&labelColor=525252&message=2453&style=for-the-badge "Total features") #### [Ultimate](https://about.gitlab.com/pricing/ultimate/) ![5 new features](https://img.shields.io/static/v1?color=108548&label=new+features&labelColor=525252&message=5&style=flat-square "New features added to this tier in this release") ![330 total badges](https://img.shields.io/static/v1?color=1F75CB&label=total+features&labelColor=525252&message=330&style=flat-square "Total features in this tier")

[User interface for streaming audit events](https://docs.gitlab.com/ee/administration/audit_event_streaming.html): Audit Events

> You can now use the GitLab UI to set up [streaming audit events](https://docs.gitlab.com/ee/administration/audit_event_streaming.html) 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](https://www.gitlab.cn/) for this contribution!

[New DORA metric API: Change failure rate](https://docs.gitlab.com/ee/api/dora/metrics.html): Continuous Delivery, Value Stream Management

> 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](https://docs.gitlab.com/ee/operations/incident_management/incidents.html) divided by the number of deployments to a production environment in the given time period. > The [DORA metrics](https://cloud.google.com/blog/products/devops-sre/using-the-four-keys-to-measure-your-devops-performance) 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.

[Compliance report individual violation reporting](https://docs.gitlab.com/ee/user/compliance/compliance_report/): Compliance Management

> 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](https://docs.gitlab.com/ee/user/compliance/compliance_report/#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.

##### [Application security testing](https://about.gitlab.com/stages-devops-lifecycle/application_security_testing/)

[Manually create a Vulnerability Record](https://docs.gitlab.com/ee/user/application_security/vulnerability_report/#manually-add-a-vulnerability-finding): Vulnerability Management

> 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](https://docs.gitlab.com/ee/api/graphql/reference/#mutationvulnerabilitycreate), 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.

##### [Software supply chain security](https://about.gitlab.com/stages-devops-lifecycle/software_supply_chain_security/)

[Security policy management user experience improvements](https://docs.gitlab.com/ee/user/application_security/policies/): Container Scanning

> 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**.

#### [Premium](https://about.gitlab.com/pricing/premium/) ![3 new features](https://img.shields.io/static/v1?color=108548&label=new+features&labelColor=525252&message=3&style=flat-square "New features added to this tier in this release") ![482 total badges](https://img.shields.io/static/v1?color=1F75CB&label=total+features&labelColor=525252&message=482&style=flat-square "Total features in this tier")

[Geo verifies CI job artifacts](https://docs.gitlab.com/ee/administration/geo/) (self-managed only): Geo-replication, Disaster Recovery

> Geo automatically verifies the data integrity of replicated [CI job artifacts](https://docs.gitlab.com/ee/ci/pipelines/job_artifacts.html). 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.

[Multiple approval rules for deployment approvals API](https://docs.gitlab.com/ee/ci/environments/deployment_approvals.html#multiple-approval-rules): Release Orchestration, Environment Management

> 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.

##### [Monitor](https://about.gitlab.com/stages-devops-lifecycle/monitor/)

[Escalating manually created incidents](https://docs.gitlab.com/ee/operations/incident_management/paging.html#escalating-an-incident): Incident Management, On-call Schedule Management

> 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.

#### Core ![15 new features](https://img.shields.io/static/v1?color=108548&label=new+features&labelColor=525252&message=15&style=flat-square "New features added to this tier in this release") ![1641 total badges](https://img.shields.io/static/v1?color=1F75CB&label=total+features&labelColor=525252&message=1641&style=flat-square "Total features in this tier")

[Install the agent for Kubernetes with Helm](https://docs.gitlab.com/ee/user/clusters/agent/install/#install-the-agent-with-helm): Kubernetes Management

> 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)](https://gitlab.com/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](https://charts.gitlab.io/) and [ArtifactHUB](https://artifacthub.io/packages/helm/gitlab/gitlab-agent) repositories.

[GitLab chart improvements](https://docs.gitlab.com/charts/) (self-managed only): Cloud Native Installation

> - GitLab 14.10 includes a fix to Sidekiq's [`health_checks.port`, setting the value to `3808` by default](https://gitlab.com/gitlab-org/charts/gitlab/-/merge_requests/2479). This ensures the [Sidekiq pods will listen separately for metrics and health checks](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/3198), so Kubernetes probes behave appropriately.

[Omnibus improvements](https://docs.gitlab.com/omnibus/) (self-managed only): Omnibus Package

> - GitLab 14.10 includes [Mattermost 6.5](https://mattermost.com/blog/mattermost-v6-5-is-now-available/), 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](https://mattermost.com/security-updates/) and upgrade from earlier versions is recommended.

[Importing from GitHub defaults to the current group path](https://docs.gitlab.com/ee/user/project/import/github.html#select-which-repositories-to-import): Importers

> 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.

[View history of all project imports on a single page](https://docs.gitlab.com/ee/user/project/import/#project-import-history): Importers

> 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.

##### [Create](https://about.gitlab.com/stages-devops-lifecycle/create/)

[Incremental repository backups reduce backup time](https://docs.gitlab.com/ee/raketasks/backup_restore.html#incremental-repository-backups) (self-managed only): Gitaly, Backup/Restore of GitLab instances

> 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](https://about.gitlab.com/handbook/product/product-principles/#the-minimal-viable-change-mvc). > > Please feel free to try out this exciting new feature and don't hesitate to > [provide feedback](https://gitlab.com/gitlab-org/gitaly/-/issues/4176)! > > See our [Repository level incremental backup epic](https://gitlab.com/groups/gitlab-org/-/epics/2094) > for updates on progress on this feature!

##### [Verify](https://about.gitlab.com/stages-devops-lifecycle/verify/)

[Expanded view of group runners](https://docs.gitlab.com/ee/ci/runners/runners_scope.html#group-runners): GitLab Runner

> 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.

[Improved pipeline variables inheritance](https://docs.gitlab.com/ee/ci/yaml/#triggerforward): Pipeline Authoring

> 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.

[CI/CD Limits set at the Instance Level](https://docs.gitlab.com/ee/administration/settings/continuous_integration.html#set-cicd-limits) (self-managed only): Continuous Integration (CI)

> 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.

[Create pipeline schedules for tags in the UI](https://docs.gitlab.com/ee/ci/pipelines/schedules.html#add-a-pipeline-schedule): Continuous Integration (CI)

> 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](https://gitlab.com/KevSlashNull) for this contribution!

[GitLab Runner 14.10](https://docs.gitlab.com/runner/): GitLab Runner

> 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: > > - [Configure artifact download path](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/6610) > - [Script line timestamp improvements](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/28774) > > The list of all changes is in the GitLab Runner [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/14-10-stable/CHANGELOG.md).

[GitLab Runner Operator for Kubernetes](https://docs.gitlab.com/runner/install/operator.html#install-on-kubernetes): GitLab Runner

> In GitLab 13.10, we [released](https://gitlab.com/gitlab-org/gl-openshift/gitlab-runner-operator/-/issues/6) 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](https://operatorhub.io/operator/gitlab-runner-operator).

##### [Application security testing](https://about.gitlab.com/stages-devops-lifecycle/application_security_testing/)

[Static Analysis analyzer updates](https://docs.gitlab.com/ee/user/application_security/sast/analyzers): SAST, Secret Detection

> GitLab Static Analysis includes [many security analyzers](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks) 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](https://gitlab.com/gitlab-org/security-products/analyzers/gosec/-/blob/master/CHANGELOG.md#v352) 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](https://gitlab.com/gitlab-org/security-products/analyzers/kics/-/blob/main/CHANGELOG.md#v150) for details. > - Add new rules > - Fix existing rules > - Delete redundant rules > - PMD analyzer updated to version 6.44.0. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/pmd-apex/-/blob/master/CHANGELOG.md#v21214) for details. > - Add Java 18 support > - Fix rules > - Secrets analyzer updated to version 8.6.1. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/blob/master/CHANGELOG.md#v3270) 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](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/blob/main/CHANGELOG.md#v2200) for details. > - Support Go 1.18 generics > - Additional bug fixes and performance improvements > > If you [include the GitLab-managed SAST template](https://docs.gitlab.com/ee/user/application_security/sast/#configure-sast-in-your-cicd-yaml) ([`SAST.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/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](https://docs.gitlab.com/ee/user/application_security/sast/#pinning-to-minor-image-version). 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.

[Faster, easier Java scanning in SAST](https://docs.gitlab.com/ee/user/application_security/sast/#supported-languages-and-frameworks): 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)](https://about.gitlab.com/releases/2021/10/22/gitlab-14-4-released/#semgrep-sast-analyzer-for-go) and for [JavaScript, TypeScript, and Python (introduced in GitLab 13.12)](https://about.gitlab.com/releases/2021/05/22/gitlab-13-12-released/#semgrep-sast-analyzer-for-javascript-typescript-and-python). > > 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](https://docs.gitlab.com/ee/user/application_security/sast/#configure-sast-in-your-cicd-yaml) ([`SAST.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/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](https://docs.gitlab.com/ee/update/deprecations#sast-analyzer-consolidation-and-cicd-template-changes), we'll change [the GitLab-managed SAST template](https://docs.gitlab.com/ee/user/application_security/sast/#configure-sast-in-your-cicd-yaml) ([`SAST.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Security/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](https://gitlab.com/gitlab-org/gitlab/-/issues/new?issuable_template=Bug&add_related_issue=352666&issue[title]=Feedback%20on%20SAST%20Semgrep%20Java%20support&issue[description]=%2Flabel%20~%22group%3A%3Astatic%20analysis%22), we'll be glad to help.

##### [Monitor](https://about.gitlab.com/stages-devops-lifecycle/monitor/)

[Upload metric screenshots to an Alert](https://docs.gitlab.com/ee/operations/incident_management/alerts.html#metrics-tab): Incident Management

> GitLab 13.2 introduced the [metrics tab](https://docs.gitlab.com/ee/operations/incident_management/alerts.html#metrics-tab) in GitLab alerts. However, with the deprecation of [GitLab Managed Apps](https://docs.gitlab.com/ee/user/clusters/applications.html) 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](https://docs.gitlab.com/ee/operations/incident_management/incidents.html#metrics). Having a screenshot of the metric that triggered the alert helps responders triage alerts more efficiently.