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

Name: GitLab

Released: 2022-01-22

License: MIT

Release Assets:

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

[Streaming audit events](https://docs.gitlab.com/ee/administration/audit_event_streaming.html): Audit Events

> You can now stream audit events to a destination of your choosing! This is a > great way to correlate GitLab audit events with other data streams you have, maintain a > backup of audit events, or build out your own automation to take action when a specific audit event happens. > > You can specify an HTTPS endpoint with our new GraphQL API and events are sent to it > as webhooks. These messages contain the same information as the Audit Events UI > about what type of change happened, when it happened, who was involved, as well as some > additional metadata. > > After you receive those messages, you can filter based on person, type, or inject that data > into another third-party tool. This is a great way to trigger any custom automation you have built if, for example, > a new user is created or a key setting is changed. We're excited to see what you use streaming audit > events for and would love to hear from you about it! Let us know by commenting on the [epic](https://gitlab.com/groups/gitlab-org/-/epics/5925).

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

[Go to Git blame from code search results](https://docs.gitlab.com/ee/user/search/#code-search): Global Search

> Users often want to understand more about code search results, such as when was a file changed or by whom. With GitLab 14.7, users can easily answer these questions with fewer clicks by using the **View blame** link in Global Search results. This change adds an additional link next to lines of code when hovering over results from a code search.

[Project names of records added to value stream stage table](https://docs.gitlab.com/ee/user/group/value_stream_analytics/#stage-table): Value Stream Management

> The value stream analytics stage table for groups now includes the project name of each issue and merge request to help you better understand the data in the stage table.

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

[Delete a GitLab Agent for Kubernetes from the UI](https://docs.gitlab.com/ee/user/clusters/agent/#remove-an-agent): Kubernetes Management

> The [GitLab Agent for Kubernetes](https://docs.gitlab.com/ee/user/clusters/agent/) > is tested and adopted by hundreds of GitLab customers each month. A few users > noticed that it's not straightforward to remove a registered agent from GitLab. > Until now, the agent could be removed only through the GraphQL API. > Introduced in GitLab 14.7, you can delete an agent directly from the GitLab UI > as well. > > When you delete the agent, GitLab revokes its tokens and the > given connection stops working immediately.

[OpenID Connect support for GitLab CI/CD](https://docs.gitlab.com/ee/ci/cloud_services): Secrets Management

> Connecting GitLab CI/CD to cloud providers using environment variables works fine for many use cases. However, it doesn't scale well if you need advanced permissions management or would prefer a signed, short-lived, contextualized connection to your cloud provider. GitLab 12.10 shipped initial support for JWT token-based connection (`CI_JOB_JWT`) to enable HashiCorp Vault users to safely retrieve secrets. That implementation was restricted to Vault, while the logic we built JWT upon opened up the possibility to connect to other providers as well. > > In GitLab 14.7, we are introducing a [`CI_JOB_JWT_V2`](https://docs.gitlab.com/ee/ci/cloud_services/) environment variable that can be used to connect to AWS, GCP, Vault, and likely many other cloud services. Please note that this is an [alpha](/handbook/product/gitlab-the-product/#alpha) feature and not ready for production use. Your feedback is welcomed in [this epic](https://gitlab.com/groups/gitlab-org/-/epics/7335). > > For AWS specifically, with the new `CI_JOB_JWT_V2` variable, you can connect to AWS to retrieve secrets, or to deploy within your account. You can also manage access rights to your cluster using AWS IAM roles. You can read more on setting up [OIDC connection with AWS](https://docs.gitlab.com/ee/ci/cloud_services/aws/). > > The new variable is automatically injected into your pipeline but is not backward compatible with the current `CI_JOB_JWT`. Until GitLab 15.0, the `CI_JOB_JWT` will continue to work normally but this will change in a [future release](https://gitlab.com/gitlab-org/gitlab/-/issues/349110). We will notify you about the change in time. The `secrets` stanza today uses the `CI_JOB_JWT_V1` variable. If you use the `secrets` stanza, you don't have to make any changes yet.

[Backup and restore supports package registry files](https://docs.gitlab.com/ee/raketasks/backup_restore.html#back-up-gitlab) (self-managed only): Backup/Restore of GitLab instances

> With the [GitLab Package Registry](https://docs.gitlab.com/ee/user/packages/package_registry/), you can use GitLab as a private or public registry for a variety of supported package managers. > Before GitLab 14.7, our [backup and restore Rake tasks](https://docs.gitlab.com/ee/raketasks/backup_restore.html#back-up-gitlab) did not support package registry files. GitLab now includes package registry files in backups created with the command `gitlab-backup create`. Administrators no longer need to have a separate backup strategy for these files to protect against data loss. > Note that this only applies to items stored in the file system. If you are storing package registry files using object storage, enable backups with your object storage provider.

[Backup and restore supports Terraform state files](https://docs.gitlab.com/ee/raketasks/backup_restore.html#back-up-gitlab) (self-managed only): Backup/Restore of GitLab instances

> The [GitLab-managed Terraform state backend](https://docs.gitlab.com/ee/user/infrastructure/iac/terraform_state.html#gitlab-managed-terraform-state) can store your Terraform state securely, sparing you the need to set up additional remote resources. > Before GitLab 14.7, our [backup and restore rake tasks](https://docs.gitlab.com/ee/raketasks/backup_restore.html#back-up-gitlab) did not support Terraform state files. GitLab now includes Terraform state files in backups created with the command `gitlab-backup create`. Administrators no longer need to have a separate backup strategy for these files to protect against data loss. > Note that this only applies to items stored in the file system. If you are storing Terraform state files using object storage, enable backups with your object storage provider.

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

> - GitLab 14.7 includes [Mattermost 6.2](https://mattermost.com/blog/mattermost-v6-2-is-now-available/), with private channel autocomplete, click to reply to a thread, ability to follow Playbook runs, Boards calendar view and @mention autocomplete, and much more. This version also includes [security updates](https://mattermost.com/security-updates/) and upgrade from earlier versions is recommended. > - With GitLab 14.7, you can [configure Redis to run behind SSL](https://docs.gitlab.com/omnibus/settings/redis.html#using-secure-sockets-layer-ssl).

[Setting to enable personalization questions during group creation](https://docs.gitlab.com/ee/administration/settings/third_party_offers.html) (self-managed only): Subgroups

> In previous releases, we added personalization questions to the group creation process. This information might be helpful for our SaaS users on GitLab.com, but less helpful for self-managed instances. We found out that these additional questions confuse the users and complicate the group creation process. In this release, thanks to [Jonas Wälter's](https://gitlab.com/wwwjon) contribution, we've added the ability for GitLab administrators to disable these questions.

[Delete labels directly from the Edit Label page](https://docs.gitlab.com/ee/user/project/labels.html#label-management): Projects, Subgroups

> In this release, we've added the ability to delete labels in the Edit Label page. This is a usability enhancement that finally allows users to delete labels instead of having a long list of labels called "deprecated". This includes Admin, Project, and Group labels.

[LDAP failover support](https://docs.gitlab.com/ee/administration/auth/ldap/index.html#basic-configuration-settings) (self-managed only): Authentication and Authorization

> You can now specify multiple hosts (using `hosts`) in your GitLab LDAP configuration. GitLab will use the first reachable host. This ensures continuity of access to GitLab should one of your LDAP hosts become unresponsive. > > Thanks to [Mathieu Parent](https://gitlab.com/sathieu) for the contribution!

[GitLab UI identifies to administrators that a user is locked](https://docs.gitlab.com/ee/security/unlock_user.html) (self-managed only): Authentication and Authorization

> In previous versions of GitLab, administrators could not see in the UI that a user was locked. Now, the GitLab UI identifies locked users to administrators, which helps confirm they are locked.

[Group access tokens](https://docs.gitlab.com/ee/user/group/settings/group_access_tokens.html) (self-managed only): Authentication and Authorization

> With group access tokens, you can use a single token to perform actions for groups, manage the projects within the group, and, in GitLab 14.2 and later, authenticate with Git over HTTPS. > > Previously, group access tokens were limited to self-managed instances only, and could only be generated using the Rails console. Now, you can create group access tokens using the UI and API. You can define token name, expiration date, and scope. You can also revoke an existing group access token. > > Thank you [Fabio Huser](https://gitlab.com/fh1ch) for your contribution!

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

[Runner status badges in Admin view](https://docs.gitlab.com/ee/administration/admin_area.html#administering-runners): GitLab Runner

> You can now easily visualize the state of all the runners on your instance. The Admin Area for runners now includes status badges and big, bold numbers, so you can see critical data at a glance, improving your runner fleet management experience.

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

> We’re also releasing GitLab Runner 14.7 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: > > - [Add interactive web terminal support to the GitLab Runner Helm Chart](https://gitlab.com/gitlab-org/charts/gitlab-runner/-/issues/79) > > #### Bug Fixes: > > - [Only parse `stdout` while determining `uid` when `FF_DISABLE_UMASK_FOR_DOCKER_EXECUTOR` is enabled](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/27598) > > The list of all changes is in the GitLab Runner [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/14-7-stable/CHANGELOG.md).

[Bulk delete artifacts with the API](https://docs.gitlab.com/ee/api/job_artifacts.html#delete-project-artifacts): Build Artifacts

> While a good strategy for managing storage consumption is to set regular expiration policies for artifacts, sometimes you need to reduce items in storage right away. Previously, you might have used a script to automate the tedious task of deleting artifacts one by one with API calls, but now you can use a new API endpoint to bulk delete job artifacts quickly and easily.

[GitLab Runner compliant with FIPS 140-2](https://docs.gitlab.com/runner/install/index.html#fips-compliant-gitlab-runner) (self-managed only): GitLab Runner

> For some GitLab customers, U.S. government regulatory requirements require the use of FIPS (Federal Information Processing Standards) compliant software. The FIPS 140-2 and FIPS 140-3 publications define the security requirements for cryptographic modules used in computer and telecommunication systems, and within cyber systems that protect sensitive information. GitLab Runner is now FIPS 140-2 compliant for AMD64 compute architectures and Red Hat Enterprise Linux (RHEL) distributions. Refer to [this epic](https://gitlab.com/groups/gitlab-org/-/epics/5104) to follow the discussions about making GitLab FIPS compliant.

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

[Sort Docker tags in the Container Registry browser](https://docs.gitlab.com/ee/user/packages/container_registry/#view-the-tags-of-a-specific-image): Container Registry

> You can now sort the list of tags in the Container Registry tag details page by name. Previously, there was no sort functionality. This sometimes required you to scroll through many pages to find a specific tag. By default, the tags list is now sorted by name in ascending order. You may also change the sort order to descending. See [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/346362) to track any further work on tag sorting.

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

[Major Gitleaks performance improvements](https://docs.gitlab.com/ee/user/application_security/sast/analyzers): Secret Detection

> Building on the [large rule expansion included in GitLab 14.5](/releases/2021/11/22/gitlab-14-5-released/#additional-secret-detection-pattern-support), we are updating our [GitLab Secret Detection analyzer](https://docs.gitlab.com/ee/user/application_security/secret_detection/), [Gitleaks](https://github.com/zricethezav/gitleaks), to the next major version 8. This new, major version includes massive performance updates and a [complete rewrite](https://github.com/zricethezav/gitleaks/releases/tag/v8.0.0) of its core detection engine. Secret Detection historical scans should now run much faster, with a large reduction in memory usage. This means both faster detection and shorter (and more efficient) pipelines. This change also sets us up to make more performance improvements that will improve all non-historical Secret Detection job runs in the future. > > Here's some real world performance data showcasing the speed and memory decreases of v8: > > - Large repo (~82K commits) > - memory: 800 MB -> 120 MB (6.67x reduction) > - scan time: 28 minutes -> 1 minute 24 seconds (21x speedup) > - Medium Repo (~600 commits) > - memory: 300 MB -> 30 MB (10x reduction) > - scan time: 27 seconds -> 8.9 seconds (3x speedup) > - Small Repo (~36 commits) - > - memory: 26 MB -> 8.4 MB (3x reduction) > - scan time: 315 ms -> 277 ms > > We want to give [Zachary Rice](https://gitlab.com/zrice) a special shoutout, as not only is he a [member of the GitLab team](https://about.gitlab.com/company/team/#zrice), but he's the creator and maintainer of the [open source Gitleaks project](https://github.com/zricethezav/gitleaks), which has helped many organizations, both public and private, search their codebases for leaked secrets. We are thrilled to support his work with Gitleaks, as well as his contributions to the wider open source community.

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

> GitLab Static Analysis is comprised of a [set of 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. Below are the analyzer updates released during GitLab 14.7. These updates bring additional coverage, bug fixes, and improvements. > > - Spotbugs updated to v2.28.12 - [MR](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs/-/merge_requests/121), [Changelog](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs/-/blob/master/CHANGELOG.md) > - Updates Log4j library to patched version (v4.5.3). See our [updated blog post](https://about.gitlab.com/blog/2021/12/15/updates-and-actions-to-address-logj-in-gitlab/) for more information. > - Code Climate updated to v0.85.26 - [MR](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/78125), [Changelog](https://gitlab.com/gitlab-org/ci-cd/codequality/-/blob/master/CHANGELOG.md#anchor-08526) > > If you [include the GitLab managed vendored 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 do not 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.