GitLab.org/GitLab: Release v15.2.0-ee
Name: GitLab
Owner: GitLab.org
Release: GitLab 15.2
Released: 2022-07-22
License: MIT
Release Assets:
[Enforce per-plan webhook rate limits](https://docs.gitlab.com/ee/user/gitlab_com/#rate-limits) (SaaS only):
> 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.
Integrations[Enforce IP address restrictions for Git over SSH](https://docs.gitlab.com/ee/user/group/#group-access-restriction-by-ip-address) (SaaS only):
> 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.
Source Code Management[Streaming audit events for merge request creation](https://docs.gitlab.com/ee/administration/audit_event_streaming.html#audit-event-streaming-on-merge-request-create-actions):
> 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](https://docs.gitlab.com/ee/administration/audit_event_streaming.html).
>
> Thank you [Linjie Zhang](https://gitlab.com/zhanglinjie) for this contribution!
Audit Events[Streaming audit events for project forks](https://docs.gitlab.com/ee/administration/audit_event_streaming.html#audit-event-streaming-on-project-fork-actions):
> 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](https://docs.gitlab.com/ee/administration/audit_event_streaming.html).
>
> Thank you [Linjie Zhang](https://gitlab.com/zhanglinjie) for this contribution!
Audit Events[Streaming audit events for Git operations](https://docs.gitlab.com/ee/administration/audit_event_streaming.html#audit-event-streaming-on-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](https://docs.gitlab.com/ee/administration/audit_event_streaming.html).
Audit Events[Custom HTTP headers for streaming audit events](https://docs.gitlab.com/ee/administration/audit_event_streaming.html#custom-http-headers):
> 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](https://docs.gitlab.com/ee/api/graphql/reference/#mutationauditeventsstreamingheaderscreate)
> to add a new header as a key/value pair. You can also update and remove headers.
Audit Events[Verification token displayed in UI](https://docs.gitlab.com/ee/administration/audit_event_streaming.html#verify-event-authenticity):
> 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](https://docs.gitlab.com/ee/api/graphql/reference/#group)
> 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!
Audit Events[Change failure rate chart for visualizing software stability](https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html#view-change-failure-rate-chart):
> In this release, we added a new trend chart for the DORA [Change failure rate](https://docs.gitlab.com/ee/user/analytics/ci_cd_analytics.html) 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](https://docs.gitlab.com/ee/operations/incident_management/incidents.html) 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](https://about.gitlab.com/blog/2022/06/20/gitlab-value-stream-management-and-dora/).
Value Stream Management, Continuous Delivery[License compliance support for Gradle `implementation` directive](https://docs.gitlab.com/ee/user/compliance/license_compliance/#supported-languages-and-package-managers):
> 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.
License Compliance[Group and subgroup scan execution policies](https://docs.gitlab.com/ee/user/application_security/policies/scan-execution-policies.html):
> 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](https://gitlab.com/groups/gitlab-org/-/epics/7622).
Security Orchestration[Audit events when two-factor authentication is disabled](https://docs.gitlab.com/ee/administration/audit_events.html#instance-events) (self-managed only):
> 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.
Audit Events[Audit events for group-level merge request settings](https://docs.gitlab.com/ee/administration/audit_events.html#group-events):
> 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[Group-level UI for protected environment settings](https://docs.gitlab.com/ee/ci/environments/protected_environments.html#group-level-protected-environments):
> Previously, if you wanted to configure group-level settings for [protected environments](https://docs.gitlab.com/ee/ci/environments/protected_environments.html), 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.
Release Orchestration, Environment Management[Edit protected environment approvals in project settings](https://docs.gitlab.com/ee/ci/environments/protected_environments.html#protected-environments):
> 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.
Environment Management[Geo supports BuildKit cache images](https://docs.gitlab.com/ee/administration/geo/replication/docker_registry.html) (self-managed only):
> With GitLab 15.2, Geo supports replication of [BuildKit cache images](https://github.com/opencontainers/image-spec/blob/main/spec.md). With the support of the BuildKit cache image format in GitLab 15.2, and the addition of support for [OCI container images](https://about.gitlab.com/releases/2022/06/22/gitlab-15-1-released/#geo-supports-oci-container-images) in GitLab 15.1, Geo now supports a broader list of container types.
Geo-replication, Disaster Recovery[API to retrieve agent server (KAS) metadata](https://docs.gitlab.com/ee/api/metadata.html):
> 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](https://gitlab.com/tuxtimo) [implemented a REST API](https://about.gitlab.com/releases/2022/05/22/gitlab-15-0-released/#rest-api-for-the-agent-for-kubernetes) and extended the GitLab Terraform Provider to [support managing agents](https://registry.terraform.io/providers/gitlabhq/gitlab/latest/docs/resources/cluster_agent) 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.
Kubernetes Management, Infrastructure as Code[Updated cluster version support, including Kubernetes 1.23 and 1.24](https://docs.gitlab.com/ee/user/clusters/agent/#supported-cluster-versions):
> 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](https://docs.gitlab.com/ee/user/clusters/agent/#supported-cluster-versions) 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.
Kubernetes Management[GitLab chart improvements](https://docs.gitlab.com/charts/) (self-managed only):
> - When using the [horizontal pod autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) 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](https://gitlab.com/gitlab-org/charts/gitlab/-/issues/2862).
Cloud Native Installation[Omnibus improvements](https://docs.gitlab.com/omnibus/) (self-managed only):
> - GitLab 15.2 includes [Mattermost 7.0](https://mattermost.com/blog/mattermost-v7-0-is-now-available/), 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](https://mattermost.com/security-updates/) and upgrade from earlier versions is recommended.
Omnibus Package[Disable user 2FA using API](https://docs.gitlab.com/ee/api/users.html#disable-two-factor-authentication) (self-managed only):
> 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.
User Management[Improvements to users' contribution calendar for private contributions](https://docs.gitlab.com/ee/user/profile/#show-private-contributions-on-your-user-profile-page):
> 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.
User Profile[Fetch secrets based on deployment tier](https://docs.gitlab.com/ee/ci/secrets/):
> 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.
Environment Management, Secrets Management[Improved and faster file browsing and syntax highlighting](https://docs.gitlab.com/ee/user/project/highlighting.html):
> 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.
Source Code Management[Persist last used Wiki editor](https://docs.gitlab.com/ee/user/project/wiki/#use-the-content-editor):
> The WYSIWYG editor was introduced in the wiki way back in [GitLab 14.0](https://about.gitlab.com/releases/2021/06/22/gitlab-14-0-released/#edit-wiki-pages-with-the-wysiwyg-markdown-editor/) 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.
Wiki[Merge request reports redesign](https://design.gitlab.com/regions/merge-request-reports/):
> 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.
Code Review, Code Testing and Coverage, Review Apps, Performance Testing, Code Quality, License Compliance, Secret Detection, SAST, Audit Reports, Infrastructure as Code, Compliance Management[Live preview diagrams in the wiki WYSIWYG editor](https://docs.gitlab.com/ee/user/project/wiki/#use-the-content-editor):
> GitLab Flavored Markdown includes extensions to support [Mermaid, PlantUML, and Kroki diagrams](https://docs.gitlab.com/ee/user/markdown.html#diagrams-and-flowcharts) 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.
Wiki[Filter jobs by status on the jobs page](https://docs.gitlab.com/ee/ci/jobs/#view-all-jobs-in-a-project):
> 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.
Continuous Integration (CI)[Predefined CI/CD variable for project description](https://docs.gitlab.com/ee/ci/variables/predefined_variables.html):
> 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`](https://gitlab.com/nejc) for this contribution!
Pipeline Authoring[GitLab Runner 15.2](https://docs.gitlab.com/runner):
> 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:
>
> - [DEBUG set as a variable in a job definition causes random failures](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/3068)
> - [Update containerd version to 1.4.12](https://gitlab.com/gitlab-org/gitlab-runner/-/issues/29165)
>
> The list of all changes is in the GitLab Runner [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-runner/blob/15-2-stable/CHANGELOG.md).
GitLab Runner Core[Set the image pull policy in pipeline configuration](https://docs.gitlab.com/ee/ci/yaml/#imagepull_policy):
> You can select different [pull policies](https://docs.gitlab.com/runner/executors/docker.html#how-pull-policies-work) 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.
Pipeline Authoring[Programmatically delete duplicate package assets](https://docs.gitlab.com/ee/user/packages/package_registry/reduce_package_registry_storage.html):
> 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.
Package Registry[Static Analysis analyzer updates](https://docs.gitlab.com/ee/user/application_security/sast/analyzers):
> 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 15.2 release milestone. These updates bring additional coverage, bug fixes, and improvements.
>
> - CodeClimate analyzer updated to version 0.85.29. See [CHANGELOG](https://gitlab.com/gitlab-org/ci-cd/codequality/-/blob/master/CHANGELOG.md#anchor-08529) 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](https://gitlab.com/gitlab-org/security-products/analyzers/kics/-/blob/main/CHANGELOG.md#v203) 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](https://gitlab.com/gitlab-org/security-products/analyzers/kubesec/-/blob/master/CHANGELOG.md#v303) for details.
> - PMD-Apex analyzer updated to version 6.45.0. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/pmd-apex/-/blob/master/CHANGELOG.md#v301) for details.
> - Semgrep analyzer engine updated to version 0.98.0. See [CHANGELOG](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/blob/main/CHANGELOG.md#v311) 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](https://gitlab.com/gitlab-org/security-products/analyzers/secrets/-/blob/master/CHANGELOG.md#v420) for details.
>
> 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.
>
> For previous changes, see [last month's updates](https://about.gitlab.com/releases/2022/06/22/gitlab-15-1-released/#static-analysis-analyzer-updates).
Code Quality, SAST, Secret Detection[Faster Secret Detection](https://docs.gitlab.com/ee/user/application_security/secret_detection/#detected-secrets):
> 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](https://docs.gitlab.com/ee/administration/settings/account_and_limit_settings/#personal-access-token-prefix).
>
> We've updated the [built-in secret detection rules](https://docs.gitlab.com/ee/user/application_security/secret_detection/#detected-secrets) to use this faster method.
> If you've [added custom rules](https://docs.gitlab.com/ee/user/application_security/secret_detection/#synthesize-a-custom-configuration), 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](https://gitlab.com/gitlab-org/gitlab/-/issues/367490) in the future after delivering this first iteration.
Secret Detection[Incident timeline](https://docs.gitlab.com/ee/operations/incident_management/incident_timeline_events.html):
> 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.
Incident Management