root
/
gitlab-ce
mirror of https://gitlab.com/free-releases/gitlab-ce.git
1
0
Fork 0
Code Issues Actions Packages Projects Releases Wiki Activity

Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2020-11-03 21:09:12 +00:00
parent 62baa95f25
commit 037bda35bf
22 changed files with 148 additions and 96 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
GITALY_SERVER_VERSION
View File

@ -1 +1 @@
940a45ca938b20031820a4976f936a5b6173de92
5783f980c3c83022dd5a0173186fba4158948062

16
doc/administration/consul.md
View File

@ -17,12 +17,9 @@ a service networking solution that you can manage by using `/etc/gitlab/gitlab.r
## Configure the Consul nodes
NOTE: **Important:**
Before proceeding, refer to the
[available reference architectures](reference_architectures/index.md#available-reference-architectures)
to find out how many Consul server nodes you should have.
On **each** Consul server node perform the following:
After you review the [reference architecture](reference_architectures/index.md#available-reference-architectures)
documentation to determine the number of Consul server nodes you should have,
on _each_ Consul server node:
1. Follow the instructions to [install](https://about.gitlab.com/install/)
GitLab by choosing your preferred platform, but do not supply the
@ -93,10 +90,9 @@ Consult the [troubleshooting section](#troubleshooting-consul) if the cluster is
able to recover after the upgrade. The [outage recovery](#outage-recovery) may
be of particular interest.
NOTE: **Note:**
GitLab uses Consul to store only transient data that is easily regenerated. If
the bundled Consul was not used by any process other than GitLab itself, then
[rebuilding the cluster from scratch](#recreate-from-scratch) is fine.
GitLab uses Consul to store only easily regenerated, transient data. If the
bundled Consul wasn't used by any process other than GitLab itself, you can
[rebuild the cluster from scratch](#recreate-from-scratch).
## Troubleshooting Consul

14
doc/administration/instance_limits.md
View File

@ -179,7 +179,6 @@ Plan.default.actual_limits.update!(project_hooks: 100)
Plan.default.actual_limits.update!(group_hooks: 100)
```
NOTE: **Note:**
Set the limit to `0` to disable it.
## Incoming emails from auto-responders
@ -217,7 +216,6 @@ Plan.default.actual_limits.update!(offset_pagination_limit: 10000)
- **Default offset pagination limit:** 50000
NOTE: **Note:**
Set the limit to `0` to disable it.
## CI/CD limits
@ -250,7 +248,6 @@ To set this limit on a self-managed installation, run the following in the
Plan.default.actual_limits.update!(ci_active_jobs: 500)
```
NOTE: **Note:**
Set the limit to `0` to disable it.
### Number of CI/CD subscriptions to a project
@ -273,7 +270,6 @@ To set this limit on a self-managed installation, run the following in the
Plan.default.actual_limits.update!(ci_project_subscriptions: 500)
```
NOTE: **Note:**
Set the limit to `0` to disable it.
### Number of pipeline schedules
@ -462,11 +458,10 @@ Setting a limit helps reduce the memory usage of the indexing processes as well
as the overall index size. This value defaults to `1024 KiB` (1 MiB) as any
text files larger than this likely aren't meant to be read by humans.
NOTE: **Note:**
You must set a limit, as an unlimited file size is not supported. Setting this
value to be greater than the amount of memory on GitLab's Sidekiq nodes will
lead to GitLab's Sidekiq nodes running out of memory as they will pre-allocate
this amount of memory during indexing.
You must set a limit, as unlimited file sizes aren't supported. Setting this
value to be greater than the amount of memory on GitLab's Sidekiq nodes causes
GitLab's Sidekiq nodes to run out of memory, as they will pre-allocate this
amount of memory during indexing.
### Maximum field length
@ -486,7 +481,6 @@ indexed](#maximum-file-size-indexed)).
This limit can be configured for self-managed installations when [enabling
Elasticsearch](../integration/elasticsearch.md#enabling-advanced-search).
NOTE: **Note:**
Set the limit to `0` to disable it.
## Wiki limits

9
doc/administration/nfs.md
View File

@ -19,11 +19,10 @@ From GitLab 13.0, using NFS for Git repositories is deprecated. In GitLab 14.0,
support for NFS for Git repositories is scheduled to be removed. Upgrade to
[Gitaly Cluster](gitaly/praefect.md) as soon as possible.
NOTE: **Note:**
Filesystem performance has a big impact on overall GitLab
performance, especially for actions that read or write to Git repositories. See
[Filesystem Performance Benchmarking](operations/filesystem_benchmarking.md)
for steps to test filesystem performance.
Filesystem performance can impact overall GitLab performance, especially for
actions that read or write to Git repositories. For steps you can use to test
filesystem performance, see
[Filesystem Performance Benchmarking](operations/filesystem_benchmarking.md).
## Known kernel version incompatibilities

70
doc/administration/object_storage.md
View File

@ -61,18 +61,17 @@ must be enabled, only the following providers can be used:
- [Google Cloud Storage](#google-cloud-storage-gcs)
- [Azure Blob storage](#azure-blob-storage)
Background upload is not supported with the consolidated object storage
configuration. We recommend enabling direct upload mode because it does
not require a shared folder, and [this setting may become the
Background upload isn't supported with the consolidated object storage
configuration. We recommend enabling direct upload mode because it doesn't
require a shared folder, and [this setting may become the
default](https://gitlab.com/gitlab-org/gitlab/-/issues/27331).
NOTE: **Note:**
Consolidated object storage configuration cannot be used for
backups or Mattermost. See [the full table for a complete list](#storage-specific-configuration).
Consolidated object storage configuration can't be used for backups or
Mattermost. See the [full table for a complete list](#storage-specific-configuration).
NOTE: **Note:**
Enabling consolidated object storage will enable object storage for all object types.
If you wish to use local storage for specific object types, you can [selectively disable object storages](#selectively-disabling-object-storage).
Enabling consolidated object storage enables object storage for all object
types. If you want to use local storage for specific object types, you can
[selectively disable object storages](#selectively-disabling-object-storage).
Most types of objects, such as CI artifacts, LFS files, upload
attachments, and so on can be saved in object storage by specifying a single
@ -347,10 +346,9 @@ gitlab_rails['object_store']['connection'] = {
###### Azure Workhorse settings (source installs only)
NOTE: **Note:**
For source installations, Workhorse needs to be configured with the
Azure credentials as well. This is not needed in Omnibus installs because
the Workhorse settings are populated from the settings above.
For source installations, Workhorse also needs to be configured with Azure
credentials. This isn't needed in Omnibus installs, because the Workhorse
settings are populated from the previous settings.
1. Edit `/home/git/gitlab-workhorse/config.toml` and add or amend the following lines:
@ -370,14 +368,14 @@ GitLab Rails and Workhorse.
#### OpenStack-compatible connection settings
NOTE: **Note:**
This is not compatible with the consolidated object storage form.
OpenStack Swift is only supported with the storage-specific form. See the
[S3 settings](#s3-compatible-connection-settings) if you want to use the consolidated form.
Although OpenStack Swift provides S3 compatibility, some users may want to use
the [Swift API](https://docs.openstack.org/swift/latest/api/object_api_v1_overview.html).
While OpenStack Swift provides S3 compatibility, some users may want to use the
[Swift API](https://docs.openstack.org/swift/latest/api/object_api_v1_overview.html).
Here are the valid connection settings below for the Swift API, provided by
This isn't compatible with the consolidated object storage form. OpenStack Swift
is supported only with the storage-specific form. If you want to use the
consolidated form, see the [S3 settings](#s3-compatible-connection-settings).
Here are the valid connection settings for the Swift API, provided by
[fog-openstack](https://github.com/fog/fog-openstack):
| Setting | Description | Default |
@ -392,12 +390,11 @@ Here are the valid connection settings below for the Swift API, provided by
#### Rackspace Cloud Files
NOTE: **Note:**
This is not compatible with the consolidated object
storage form. Rackspace Cloud is only supported with the storage-specific form.
The following table describes the valid connection parameters for
Rackspace Cloud, provided by [fog-rackspace](https://github.com/fog/fog-rackspace/).
Here are the valid connection parameters for Rackspace Cloud, provided by
[fog-rackspace](https://github.com/fog/fog-rackspace/):
This isn't compatible with the consolidated object storage form.
Rackspace Cloud is supported only with the storage-specific form.
| Setting | Description | example |
|---------|-------------|---------|
@ -407,13 +404,13 @@ Here are the valid connection parameters for Rackspace Cloud, provided by
| `rackspace_region` | The Rackspace storage region to use, a three letter code from the [list of service access endpoints](https://developer.rackspace.com/docs/cloud-files/v1/general-api-info/service-access/) | `iad` |
| `rackspace_temp_url_key` | The private key you have set in the Rackspace API for [temporary URLs](https://developer.rackspace.com/docs/cloud-files/v1/use-cases/public-access-to-your-cloud-files-account/#tempurl). | `ABC123DEF456ABC123DEF456ABC123DE` |
NOTE: **Note:**
Regardless of whether the container has public access enabled or disabled, Fog will
use the TempURL method to grant access to LFS objects. If you see errors in logs referencing
instantiating storage with a `temp-url-key`, ensure that you have set the key properly
on the Rackspace API and in `gitlab.rb`. You can verify the value of the key Rackspace
has set by sending a GET request with token header to the service access endpoint URL
and comparing the output of the returned headers.
Regardless of whether the container has public access enabled or disabled, Fog
uses the TempURL method to grant access to LFS objects. If you see error
messages in logs that refer to instantiating storage with a `temp-url-key`,
be sure you have set the key properly both in the Rackspace API and in
`gitlab.rb`. You can verify the value of the key Rackspace has set by sending a
GET request with token header to the service access endpoint URL and comparing
the output of the returned headers.
### Object-specific configuration
@ -521,15 +518,16 @@ gitlab_rails['uploads_object_store_remote_directory'] = 'uploads'
gitlab_rails['uploads_object_store_connection'] = { 'provider' => 'AWS', 'aws_access_key_id' => 'access_key', 'aws_secret_access_key' => 'secret' }
```
While this provides flexibility in that it makes it possible for GitLab
Although this provides flexibility in that it makes it possible for GitLab
to store objects across different cloud providers, it also creates
additional complexity and unnecessary redundancy. Since both GitLab
Rails and Workhorse components need access to object storage, the
consolidated form avoids excessive duplication of credentials.
NOTE: **Note:**
The consolidated object storage configuration is **only** used if all
lines from the original form is omitted. To move to the consolidated form, remove the original configuration (for example, `artifacts_object_store_enabled`, `uploads_object_store_connection`, and so on.)
The consolidated object storage configuration is used _only_ if all lines from
the original form is omitted. To move to the consolidated form, remove the
original configuration (for example, `artifacts_object_store_enabled`, or
`uploads_object_store_connection`)
## Storage-specific configuration

16
doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md
View File

@ -999,3 +999,19 @@ project = Project.find_by_full_path('<group/project>')
Geo::RepositorySyncService.new(project).execute
```
### Generate usage ping
#### Generate or get the cached usage ping
```ruby
Gitlab::UsageData.to_json
```
#### Generate a fresh new usage ping
This will also refresh the cached usage ping displayed in the admin area
```ruby
Gitlab::UsageData.to_json(force_refresh: true)
```

6
doc/api/experiments.md
View File

@ -8,13 +8,13 @@ info: To determine the technical writer assigned to the Stage/Group associated w
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/262725) in GitLab 13.5.
This API is for listing Experiments [experiment use in development of GitLab](../development/experiment_guide/index.md).
This API is for listing A/B experiments [defined in GitLab](../development/experiment_guide/index.md).
All methods require user be a [GitLab team member](https://gitlab.com/groups/gitlab-com/-/group_members) for authorization.
The user must be a [GitLab team member](https://gitlab.com/groups/gitlab-com/-/group_members) to access the API.
## List all experiments
Get a list of all experiments, with its enabled status.
Get a list of all experiments. Each experiment has an `enabled` status that indicates whether the experiment is enabled globally, or only in specific contexts.
```plaintext
GET /experiments

2
doc/api/graphql/reference/gitlab_schema.graphql
View File

@ -2779,7 +2779,7 @@ type CodeCoverageSummary {
"""
Latest date when the code coverage was created for the project.
"""
lastUpdatedAt: Time
lastUpdatedOn: Date
}
type Commit {

4
doc/api/graphql/reference/gitlab_schema.json
View File

@ -7580,14 +7580,14 @@
"deprecationReason": null
},
{
"name": "lastUpdatedAt",
"name": "lastUpdatedOn",
"description": "Latest date when the code coverage was created for the project.",
"args": [
],
"type": {
"kind": "SCALAR",
"name": "Time",
"name": "Date",
"ofType": null
},
"isDeprecated": false,

2
doc/api/graphql/reference/index.md
View File

@ -437,7 +437,7 @@ Represents the code coverage summary for a project.
| ----- | ---- | ----------- |
| `averageCoverage` | Float | Average percentage of the different code coverage results available for the project. |
| `coverageCount` | Int | Number of different code coverage results available. |
| `lastUpdatedAt` | Time | Latest date when the code coverage was created for the project. |
| `lastUpdatedOn` | Date | Latest date when the code coverage was created for the project. |
### Commit

1
doc/development/changelog.md
View File

@ -56,6 +56,7 @@ the `author` field. GitLab team members **should not**.
- Any change behind a disabled feature flag **should not** have a changelog entry.
- Any change behind an enabled feature flag **should** have a changelog entry.
- Any change that adds new usage data metrics and changes that needs to be documented in Product Analytics [Event Dictionary](https://about.gitlab.com/handbook/product/product-analytics-guide#event-dictionary) **should** have a changelog entry.
- A change that adds snowplow events **should** have a changelog entry -
- A change that [removes a feature flag](feature_flags/development.md) **should** have a changelog entry -
only if the feature flag did not default to true already.
- A fix for a regression introduced and then fixed in the same release (i.e.,

2
doc/operations/error_tracking.md
View File

@ -16,7 +16,7 @@ Error Tracking allows developers to easily discover and view the errors that the
### Deploying Sentry
You can sign up to the cloud hosted <https://sentry.io>, deploy your own [on-premise instance](https://github.com/getsentry/onpremise/) or use GitLab to [install Sentry to a Kubernetes cluster](../user/clusters/applications.md#install-sentry-using-gitlab-cicd).
You can sign up to the cloud hosted [Sentry](https://sentry.io), deploy your own [on-premise instance](https://github.com/getsentry/onpremise/), or use GitLab to [install Sentry to a Kubernetes cluster](../user/clusters/applications.md#install-sentry-using-gitlab-cicd). To make this easier, we are [considering shipping Sentry with GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab/-/issues/5343).
### Enabling Sentry

BIN
doc/user/admin_area/settings/img/custom_sign_in_page_v13_6.png Normal file
View File

Binary file not shown.
Side by Side

After

Width:  |  Height:  |  Size: 60 KiB

17
doc/user/admin_area/settings/sign_in_restrictions.md
View File

@ -50,8 +50,21 @@ All users that are not logged-in will be redirected to the page represented by t
All users will be redirect to the page represented by the configured "After sign out path"
after sign out if value is not empty.
If a "Sign in text" in Markdown format is provided, then every user will be presented with
this message after logging-in.
In the Sign-in restrictions section, scroll to the "Sign-in text" text box. You can add a
custom message for your users in Markdown format.
For example, if you include the following information in the noted text box:
```markdown
# Custom sign-in text
To access this text box, navigate to Admin Area > Settings > General, and expand the "Sign-in restrictions" section.
```
Your users will see the "Custom sign-in text" when they navigate to the sign-in screen for your
GitLab instance:
![Sign-in page](img/custom_sign_in_page_v13_6.png)
<!-- ## Troubleshooting

45
doc/user/clusters/agent/index.md
View File

@ -24,9 +24,11 @@ tasks in a secure and cloud-native way. It enables:
Many more features are planned. Please [review our roadmap](https://gitlab.com/groups/gitlab-org/-/epics/3329).
## Architecture
## GitLab Agent GitOps workflow
### GitLab Agent GitOps workflow
The GitLab Agent uses multiple GitLab projects to provide a flexible workflow
that can suit various needs. This diagram shows these repositories and the main
actors involved in a deployment:
```mermaid
sequenceDiagram
@ -44,11 +46,6 @@ sequenceDiagram
end
```
Please refer to our [full architecture documentation](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/master/doc/architecture.md#high-level-architecture)
in the Agent project.
## Get started with GitOps and the GitLab Agent
There are several components that work in concert for the Agent to accomplish GitOps deployments:
- A properly-configured Kubernetes cluster.
@ -57,15 +54,43 @@ There are several components that work in concert for the Agent to accomplish Gi
- A manifest repository that contains a `manifest.yaml`, which is tracked by the
Agent and can be auto-generated. Any changes to `manifest.yaml` are applied to the cluster.
These repositories might be the same GitLab project or separate projects.
For more details, please refer to our [full architecture documentation](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/-/blob/master/doc/architecture.md#high-level-architecture) in the Agent project.
## Get started with GitOps and the GitLab Agent
The setup process involves a few steps to enable GitOps deployments:
1. Installing the Agent server.
1. Installing the Agent server. This must be done one time for every GitLab installation.
1. Defining a configuration directory.
1. Creating an Agent record in GitLab.
1. Generating and copying a Secret token used to connect to the Agent.
1. Installing the Agent into the cluster.
1. Creating a `manifest.yaml`.
### Upgrades and version compatibility
As the GitLab Kubernetes Agent is a new product, we are constantly adding new features
to it. As a result, while shipped features are production ready, its internal API is
neither stable nor versioned yet. For this reason, GitLab only guarantees compatibility
between corresponding major.minor (X.Y) versions of GitLab and its cluster side
component, `agentk`.
Upgrade your agent installations together with GitLab upgrades: if you install
GitLab version 13.6, use version 13.6.x versions of `agentk`.
The available `agentk` versions can be found in
[its container registry](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/container_registry/eyJuYW1lIjoiZ2l0bGFiLW9yZy9jbHVzdGVyLWludGVncmF0aW9uL2dpdGxhYi1hZ2VudC9hZ2VudGsiLCJ0YWdzX3BhdGgiOiIvZ2l0bGFiLW9yZy9jbHVzdGVyLWludGVncmF0aW9uL2dpdGxhYi1hZ2VudC9yZWdpc3RyeS9yZXBvc2l0b3J5LzEyMjMyMDUvdGFncz9mb3JtYXQ9anNvbiIsImlkIjoxMjIzMjA1LCJjbGVhbnVwX3BvbGljeV9zdGFydGVkX2F0IjpudWxsfQ==).
### Upgrades and Version compatibility
As the GitLab Kubernetes Agent is a new product, we are constantly adding new features to it. As a result, while shipped features are production ready, it's internal API is not stable nor versioned yet. For this reason, we only guarantee compatibility between corresponding major.minor versions of GitLab and its cluster side component, `agentk`. Please, upgrade your agent installations together with GitLab upgrades.
Example: having GitLab 13.6 installed, please use version 13.6.x versions of `agentk`.
The available `agentk` versions can be found in [its container registry](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/container_registry/eyJuYW1lIjoiZ2l0bGFiLW9yZy9jbHVzdGVyLWludGVncmF0aW9uL2dpdGxhYi1hZ2VudC9hZ2VudGsiLCJ0YWdzX3BhdGgiOiIvZ2l0bGFiLW9yZy9jbHVzdGVyLWludGVncmF0aW9uL2dpdGxhYi1hZ2VudC9yZWdpc3RyeS9yZXBvc2l0b3J5LzEyMjMyMDUvdGFncz9mb3JtYXQ9anNvbiIsImlkIjoxMjIzMjA1LCJjbGVhbnVwX3BvbGljeV9zdGFydGVkX2F0IjpudWxsfQ==).
### Install the Kubernetes Agent Server
The GitLab Kubernetes Agent Server (KAS) can be deployed using [Omnibus
@ -77,6 +102,8 @@ documentation](https://docs.gitlab.com/ee/install/README.html).
NOTE: **Note:**
GitLab plans to include the KAS on [GitLab.com](https://gitlab.com/groups/gitlab-org/-/epics/3834).
#### Install with Omnibus
When using the [Omnibus GitLab](https://docs.gitlab.com/omnibus/) package:
1. Edit `/etc/gitlab/gitlab.rb`:
@ -87,6 +114,8 @@ gitlab_kas['enable'] = true
1. [Reconfigure GitLab](../../../administration/restart_gitlab.md#omnibus-gitlab-reconfigure).
#### Install with the Helm chart
When installing or upgrading the GitLab Helm chart, consider the following Helm v3 example.
If you're using Helm v2, you must modify this example. See our [notes regarding deploy with Helm](https://docs.gitlab.com/charts/installation/deployment.html#deploy-using-helm).

4
package.json
View File

@ -43,8 +43,8 @@
"@babel/plugin-syntax-import-meta": "^7.10.1",
"@babel/preset-env": "^7.10.1",
"@gitlab/at.js": "1.5.5",
"@gitlab/svgs": "1.174.0",
"@gitlab/ui": "21.42.0",
"@gitlab/svgs": "1.175.0",
"@gitlab/ui": "21.44.0",
"@gitlab/visual-review-tools": "1.6.1",
"@rails/actioncable": "^6.0.3-3",
"@rails/ujs": "^6.0.3-2",

2
spec/frontend/clusters/components/__snapshots__/remove_cluster_confirmation_spec.js.snap
View File

@ -14,6 +14,8 @@ exports[`Remove cluster confirmation modal renders splitbutton with modal includ
>
<!---->
<!---->
<span
class="gl-new-dropdown-button-text"
>

2
spec/frontend/code_navigation/components/__snapshots__/popover_spec.js.snap
View File

@ -12,7 +12,7 @@ exports[`Code navigation popover component renders popover 1`] = `
<gl-tabs-stub
contentclass="gl-py-0"
nav-class="gl-hidden"
navclass="gl-hidden"
theme="indigo"
>
<gl-tab-stub

4
spec/frontend/jira_import/components/__snapshots__/jira_import_form_spec.js.snap
View File

@ -91,6 +91,8 @@ exports[`JiraImportForm table body shows correct information in each cell 1`] =
>
<!---->
<!---->
<span
class="gl-new-dropdown-button-text"
>
@ -203,6 +205,8 @@ exports[`JiraImportForm table body shows correct information in each cell 1`] =
>
<!---->
<!---->
<span
class="gl-new-dropdown-button-text"
>

2
spec/frontend/packages/list/components/__snapshots__/packages_list_app_spec.js.snap
View File

@ -10,7 +10,7 @@ exports[`packages_list_app renders 1`] = `
activenavitemclass="gl-tab-nav-item-active gl-tab-nav-item-active-indigo"
class="gl-tabs"
contentclass=",gl-tab-content"
navclass="gl-tabs-nav"
navclass=",gl-tabs-nav"
nofade="true"
nonavstyle="true"
tag="div"

4
spec/frontend/vue_shared/components/members/table/role_dropdown_spec.js
View File

@ -116,11 +116,11 @@ describe('RoleDropdown', () => {
await nextTick();
expect(findDropdown().attributes('disabled')).toBe('disabled');
expect(findDropdown().props('disabled')).toBe(true);
await waitForPromises();
expect(findDropdown().attributes('disabled')).toBeUndefined();
expect(findDropdown().props('disabled')).toBe(false);
});
});
});

20
yarn.lock
View File

@ -861,21 +861,21 @@
eslint-plugin-vue "^6.2.1"
vue-eslint-parser "^7.0.0"
"@gitlab/svgs@1.174.0":
version "1.174.0"
resolved "https://registry.yarnpkg.com/@gitlab/svgs/-/svgs-1.174.0.tgz#954b4d908a6188a2fcc45f00f748beeb23f054b0"
integrity sha512-CgnZvO2miZkWxANhFdaK+2S4qRgkrMRE3vh3Xxwc+hIV9ki9KavlAAez9MNIs0Um/SJ1UpfmqKoM/dMyZX7K/w==
"@gitlab/svgs@1.175.0":
version "1.175.0"
resolved "https://registry.yarnpkg.com/@gitlab/svgs/-/svgs-1.175.0.tgz#734f341784af1cd1d62d160a17bcdfb61ff7b04d"
integrity sha512-gXpc87TGSXIzfAr4QER1Qw1v3P47pBO6BXkma52blgwXVmcFNe3nhQzqsqt66wKNzrIrk3lAcB4GUyPHbPVXpg==
"@gitlab/ui@21.42.0":
version "21.42.0"
resolved "https://registry.yarnpkg.com/@gitlab/ui/-/ui-21.42.0.tgz#9cba612a6b0c8ee533865fa0c1e12243ced0c6e2"
integrity sha512-1q55KuGozOZ3iQPzE+GD7ChX+BCCe9eYGtaLMrFP6mjtyGDI1v9AHfYqHIqgS3+chaTKWCr8YpJ0PECPaLLM6A==
"@gitlab/ui@21.44.0":
version "21.44.0"
resolved "https://registry.yarnpkg.com/@gitlab/ui/-/ui-21.44.0.tgz#a8bf21434aa269eb198bcf88091eedb9d021e58f"
integrity sha512-WvHodwtJX2Xxj0D4QBG8KwQ21zpvDjL6rA1lRGbh5TO90p2NMYL+COi2WRqX+5Hj0bQhKcMEmpCQLqdO7Y2u4g==
dependencies:
"@babel/standalone" "^7.0.0"
"@gitlab/vue-toasted" "^1.3.0"
bootstrap-vue "2.13.1"
copy-to-clipboard "^3.0.8"
dompurify "^2.2.0"
dompurify "^2.2.2"
echarts "^4.2.1"
highlight.js "^9.13.1"
js-beautify "^1.8.8"
@ -4181,7 +4181,7 @@ domhandler@^2.3.0:
dependencies:
domelementtype "1"
dompurify@^2.2.0, dompurify@^2.2.2:
dompurify@^2.2.2:
version "2.2.2"
resolved "https://registry.yarnpkg.com/dompurify/-/dompurify-2.2.2.tgz#cb8c2b1a2f3c8a0b565127504ae4eedec176a972"
integrity sha512-BsGR4nDLaC5CNBnyT5I+d5pOeaoWvgVeg6Gq/aqmKYWMPR07131u60I80BvExLAJ0FQEIBQ1BTicw+C5+jOyrg==