diff --git a/doc/administration/audit_event_streaming.md b/doc/administration/audit_event_streaming.md index 5f9f0dbd00b..07979e21038 100644 --- a/doc/administration/audit_event_streaming.md +++ b/doc/administration/audit_event_streaming.md @@ -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: diff --git a/doc/administration/gitaly/configure_gitaly.md b/doc/administration/gitaly/configure_gitaly.md index d3b0304eeaa..6888a2abe9a 100644 --- a/doc/administration/gitaly/configure_gitaly.md +++ b/doc/administration/gitaly/configure_gitaly.md @@ -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//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 diff --git a/doc/ci/environments/deployment_approvals.md b/doc/ci/environments/deployment_approvals.md index 971a62c5dab..23fa5d45196 100644 --- a/doc/ci/environments/deployment_approvals.md +++ b/doc/ci/environments/deployment_approvals.md @@ -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: diff --git a/doc/development/contributing/index.md b/doc/development/contributing/index.md index ea54f36a7e5..8a4b06840a4 100644 --- a/doc/development/contributing/index.md +++ b/doc/development/contributing/index.md @@ -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. diff --git a/doc/user/application_security/dependency_scanning/index.md b/doc/user/application_security/dependency_scanning/index.md index ecb149d61c8..87d49ffa324 100644 --- a/doc/user/application_security/dependency_scanning/index.md +++ b/doc/user/application_security/dependency_scanning/index.md @@ -321,7 +321,7 @@ table.supported-languages ul {

  • - Support for Poetry projects with a poetry.lock file was [added in GitLab 15.0](https://gitlab.com/gitlab-org/gitlab/-/issues/7006). + Support for Poetry projects with a poetry.lock file was added in GitLab 15.0. Support for projects without a poetry.lock file is tracked in issue: Poetry's pyproject.toml support for dependency scanning.

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