Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
parent
d963ae70e2
commit
8a735cc806
|
@ -156,10 +156,11 @@ the destination's value when [listing streaming destinations](#list-streaming-de
|
|||
|
||||
## Audit event streaming on Git operations
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/332747) in GitLab 14.9 [with a flag](../administration/feature_flags.md) named `audit_event_streaming_git_operations`. Disabled by default.
|
||||
> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/332747) in GitLab 14.9 [with a flag](../administration/feature_flags.md) named `audit_event_streaming_git_operations`. Disabled by default.
|
||||
> - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/357211) in GitLab 15.0.
|
||||
|
||||
FLAG:
|
||||
On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](feature_flags.md) named `audit_event_streaming_git_operations`. On GitLab.com, this feature is not available.
|
||||
On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](feature_flags.md) named `audit_event_streaming_git_operations`. On GitLab.com, this feature is available.
|
||||
|
||||
Streaming audit events can be sent when signed-in users push or pull a project's remote Git repositories:
|
||||
|
||||
|
|
|
@ -826,7 +826,6 @@ information, see the [relevant documentation](monitoring.md#monitor-gitaly-concu
|
|||
## Control groups
|
||||
|
||||
> - Introduced in GitLab 13.10.
|
||||
> - New version of the configuration was introduced in GitLab 15.0.
|
||||
|
||||
Gitaly shells out to Git for many of its operations. Git can consume a lot of resources for certain operations,
|
||||
especially for large repositories.
|
||||
|
@ -857,11 +856,7 @@ Using cgroups allows the kernel to kill these operations before they hog up all
|
|||
|
||||
### Configure cgroups in Gitaly
|
||||
|
||||
How you configure cgroups in Gitaly depends on what version of GitLab you use.
|
||||
|
||||
#### GitLab 13.10 to GitLab 14.10
|
||||
|
||||
To configure cgroups in Gitaly for GitLab versions 13.10 to 14.10, add `gitaly['cgroups']` to `/etc/gitlab/gitlab.rb`. For
|
||||
To configure cgroups in Gitaly, add `gitaly['cgroups']` to `/etc/gitlab/gitlab.rb`. For
|
||||
example:
|
||||
|
||||
```ruby
|
||||
|
@ -892,69 +887,6 @@ gitaly['cgroups_cpu_enabled'] = true
|
|||
which represents 100% of CPU.
|
||||
which represents 100% of CPU.
|
||||
|
||||
#### GitLab 15.0 and later
|
||||
|
||||
To configure cgroups in Gitaly for GitLab versions 15.0 and later, add `gitaly['cgroups']` to `/etc/gitlab/gitlab.rb`. For
|
||||
example:
|
||||
|
||||
```ruby
|
||||
# in /etc/gitlab/gitlab.rb
|
||||
gitaly['cgroups_mountpoint'] = "/sys/fs/cgroup"
|
||||
gitaly['cgroups_hierarchy_root'] =>"gitaly"
|
||||
gitaly['cgroups_memory_bytes'] = 64424509440, # 60gb
|
||||
gitaly['cgroups_cpu_shares'] = 1024
|
||||
gitaly['cgroups_repositories_count'] => 1000,
|
||||
gitaly['cgroups_repositories_memory_bytes'] => 32212254720 # 20gb
|
||||
gitaly['cgroups_repositories_cpu_shares'] => 512
|
||||
```
|
||||
|
||||
- `cgroups_mountpoint` is where the parent cgroup directory is mounted. Defaults to `/sys/fs/cgroup`.
|
||||
- `cgroups_hierarchy_root` is the parent cgroup under which Gitaly creates groups, and
|
||||
is expected to be owned by the user and group Gitaly runs as. Omnibus GitLab
|
||||
creates the set of directories `mountpoint/<cpu|memory>/hierarchy_root`
|
||||
when Gitaly starts.
|
||||
- `cgroups_memory_bytes` is the total memory limit that is imposed collectively on all
|
||||
Git processes that Gitaly spawns. 0 implies no limit.
|
||||
- `cgroups_cpu_shares` is the CPU limit that is imposed collectively on all Git
|
||||
processes that Gitaly spawns. 0 implies no limit. The maximum is 1024 shares,
|
||||
which represents 100% of CPU.
|
||||
- `cgroups_repositories_count` is the number of cgroups in the cgroups pool. Each time a new Git
|
||||
command is spawned, Gitaly assigns it to one of these cgroups based
|
||||
on the repository the command is for. A circular hashing algorithm assigns
|
||||
Git commands to these cgroups, so a Git command for a repository is
|
||||
always assigned to the same cgroup.
|
||||
- `cgroups_repositories_memory_bytes` is the total memory limit that is imposed collectively on all
|
||||
Git processes that Gitaly spawns. 0 implies no limit. This value cannot exceed
|
||||
that of the top level `cgroups_memory_bytes`.
|
||||
- `cgroups_repositories_cpu_shares` is the CPU limit that is imposed collectively on all Git
|
||||
processes Gitaly spawns. 0 implies no limit. The maximum is 1024 shares,
|
||||
which represents 100% of CPU. This value cannot exceed that of the top
|
||||
level`cgroups_cpu_shares`.
|
||||
|
||||
The difference in the cgroups configuration in GitLab 15.0 and later is that we create a pool of cgroups that are isolated
|
||||
based on the repository used in the Git command to be placed under one of these cgroups.
|
||||
|
||||
### Configuring oversubscription
|
||||
|
||||
In the previous example configuration for GitLab 15.0 and later:
|
||||
|
||||
- The top level memory limit is capped at 60gb.
|
||||
- Each of the 1000 cgroups in the repositories pool is capped at 20gb.
|
||||
|
||||
This is called "oversubscription". Each cgroup in the pool has a much larger capacity than 1/1000th
|
||||
of the top-level memory limit.
|
||||
|
||||
This strategy has two main benefits:
|
||||
|
||||
- It gives the host protection from overall memory starvation (OOM), because the top-level
|
||||
cgroup's memory limit can be set to a threshold smaller than the host's
|
||||
capacity. Processes outside of that cgroup are not at risk of OOM.
|
||||
- It allows each individual cgroup in the pool to burst up to a generous upper
|
||||
bound (in this example 20 GB) that is smaller than the parent cgroup's limit,
|
||||
but substantially larger than 1/N of the parent's limit. In this example, up
|
||||
to 3 child cgroups can concurrently burst up to their max. In general, all
|
||||
1000 cgroups would use much less than the 20 GB.
|
||||
|
||||
## Background Repository Optimization
|
||||
|
||||
Empty directories and unneeded configuration settings may accumulate in a repository and
|
||||
|
|
|
@ -139,7 +139,9 @@ To approve or reject a deployment to a protected environment using the UI:
|
|||
|
||||
1. On the top bar, select **Menu > Projects** and find your project.
|
||||
1. On the left sidebar, select **Deployments > Environments**.
|
||||
1. Select the environment's name.
|
||||
1. In the deployment's row, select **Approval options** (**{thumb-up}**).
|
||||
1. Optional. Add a comment which describes your reason for approving or rejecting the deployment.
|
||||
1. Select **Approve** or **Reject**.
|
||||
|
||||
NOTE:
|
||||
|
|
|
@ -33,9 +33,8 @@ GitLab Inc engineers should refer to the [engineering workflow document](https:/
|
|||
|
||||
## Security vulnerability disclosure
|
||||
|
||||
Report suspected security vulnerabilities in private to
|
||||
`support@gitlab.com`, also see the
|
||||
[disclosure section on the GitLab.com website](https://about.gitlab.com/security/disclosure/).
|
||||
Report suspected security vulnerabilities by following the
|
||||
[disclosure process on the GitLab.com website](https://about.gitlab.com/security/disclosure/).
|
||||
|
||||
WARNING:
|
||||
Do **NOT** create publicly viewable issues for suspected security vulnerabilities.
|
||||
|
|
|
@ -321,7 +321,7 @@ table.supported-languages ul {
|
|||
<li>
|
||||
<a id="notes-regarding-supported-languages-and-package-managers-4"></a>
|
||||
<p>
|
||||
Support for <a href="https://python-poetry.org/">Poetry</a> projects with a <code>poetry.lock</code> file was [added in GitLab 15.0](https://gitlab.com/gitlab-org/gitlab/-/issues/7006).
|
||||
Support for <a href="https://python-poetry.org/">Poetry</a> projects with a <code>poetry.lock</code> file was <a href="https://gitlab.com/gitlab-org/gitlab/-/issues/7006">added in GitLab 15.0</a>.
|
||||
Support for projects without a <code>poetry.lock</code> file is tracked in issue:
|
||||
<a href="https://gitlab.com/gitlab-org/gitlab/-/issues/32774">Poetry's pyproject.toml support for dependency scanning.</a>
|
||||
</p>
|
||||
|
@ -346,9 +346,10 @@ The following package managers use lockfiles that GitLab analyzers are capable o
|
|||
| Composer | N/A | [1.x](https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium/-/blob/master/qa/fixtures/php-composer/default/composer.lock) |
|
||||
| Conan | 0.4 | [1.x](https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium/-/blob/master/qa/fixtures/c-conan/default/conan.lock) |
|
||||
| Go | N/A | [1.x](https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium/-/blob/master/qa/fixtures/go-modules/default/go.sum) |
|
||||
| NuGet | v1 | [4.9](https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium/-/blob/master/qa/fixtures/csharp-nuget-dotnetcore/default/src/web.api/packages.lock.json#L2) |j
|
||||
| NuGet | v1 | [4.9](https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium/-/blob/master/qa/fixtures/csharp-nuget-dotnetcore/default/src/web.api/packages.lock.json#L2) |
|
||||
| npm | v1, v2 | [6.x](https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium/-/blob/master/qa/fixtures/js-npm/default/package-lock.json#L4), [7.x](https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium/-/blob/master/qa/fixtures/js-npm/lockfileVersion2/package-lock.json#L4) |
|
||||
| yarn | v1 | [1.x](https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium/-/blob/master/qa/fixtures/js-yarn/default/yarn.lock#L2) |
|
||||
| Poetry | v1 | [1.x](https://gitlab.com/gitlab-org/security-products/analyzers/gemnasium-python/-/blob/v3/qa/fixtures/python-poetry/default/poetry.lock) |
|
||||
|
||||
#### Obtaining dependency information by running a package manager to generate a parsable file
|
||||
|
||||
|
|
Loading…
Reference in New Issue