kotovalexarian-likes-gitlab
/
gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2022-07-07 00:09:59 +00:00
parent f71db8c5f0
commit db30e094f2
29 changed files with 181 additions and 132 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
GITALY_SERVER_VERSION
View File

@ -1 +1 @@
6944c95243e2b6ed8f783ae903cb9b03ad50e0f9
2284c7b59150b6847ae4860744881d91b89a739c

9
db/migrate/20220705145349_add_project_import_level_to_namespace_settings.rb Normal file
View File

@ -0,0 +1,9 @@
# frozen_string_literal: true
class AddProjectImportLevelToNamespaceSettings < Gitlab::Database::Migration[2.0]
enable_lock_retries!
def change
add_column :namespace_settings, :project_import_level, :smallint, default: 0, null: false
end
end

1
db/schema_migrations/20220705145349 Normal file
View File

@ -0,0 +1 @@
7f5288a47ce5d548bf47fbcd107e31f5448ec1d730ce5b13a760c155c50b44fb

1
db/structure.sql
View File

@ -17574,6 +17574,7 @@ CREATE TABLE namespace_settings (
enabled_git_access_protocol smallint DEFAULT 0 NOT NULL,
unique_project_download_limit smallint DEFAULT 0 NOT NULL,
unique_project_download_limit_interval_in_seconds integer DEFAULT 0 NOT NULL,
project_import_level smallint DEFAULT 0 NOT NULL,
CONSTRAINT check_0ba93c78c7 CHECK ((char_length(default_branch_name) <= 255))
);

7
doc/.vale/gitlab/Uppercase.yml
View File

@ -16,6 +16,7 @@ second: '(?:\b[A-Z][a-z]+ )+\(([A-Z]{3,5})\)'
exceptions:
- ACL
- AJAX
- AMI
- ANSI
- APAC
- API
@ -23,6 +24,7 @@ exceptions:
- ARM
- ARN
- ASCII
- ASG
- AWS
- BMP
- BSD
@ -58,11 +60,13 @@ exceptions:
- DSL
- DVCS
- DVD
- EBS
- ECDSA
- ECS
- EFS
- EKS
- ELB
- ENA
- EOL
- EWM
- EXIF
@ -88,6 +92,7 @@ exceptions:
- GPG
- GPL
- GPS
- GPT
- GPU
- GUI
- HAML
@ -125,10 +130,12 @@ exceptions:
- LSIF
- LTM
- LTS
- LVM
- MIME
- MIT
- MITRE
- MVC
- NAS
- NAT
- NDA
- NFS

1
doc/.vale/gitlab/spelling-exceptions.txt
View File

@ -240,6 +240,7 @@ Fortinet
Fugit
fuzzer
Gantt
Gbps
Gemfile
Gemnasium
Gemojione

61
doc/administration/gitaly/configure_gitaly.md
View File

@ -130,57 +130,49 @@ Install Gitaly on each Gitaly server using either Omnibus GitLab or install it f
- To install from source, follow the steps at
[Install Gitaly](../../install/installation.md#install-gitaly).
### Configure authentication
### Configure Gitaly servers
To configure Gitaly servers, you must:
- Configure authentication.
- Configure storage paths.
- Enable the network listener.
The `git` user must be able to read, write, and set permissions on the configured storage path.
To avoid downtime while rotating Gitaly's token, you can temporarily disable authentication using the `gitaly['auth_transitioning']` setting. For more information, see the documentation on
[enabling "auth transitioning mode"](#enable-auth-transitioning-mode).
#### Configure authentication
Gitaly and GitLab use two shared secrets for authentication:
- One to authenticate gRPC requests to Gitaly.
- A second for authentication callbacks from GitLab Shell to the GitLab internal API.
- _Gitaly token_: used to authenticate gRPC requests to Gitaly
- _GitLab Shell token_: used for authentication callbacks from GitLab Shell to the GitLab internal API
**For Omnibus GitLab**
To configure the Gitaly token:
1. On the Gitaly clients, edit `/etc/gitlab/gitlab.rb`:
```ruby
gitlab_rails['gitaly_token'] = 'abc123secret'
```
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. On the Gitaly server, edit `/etc/gitlab/gitlab.rb`:
To configure the _Gitaly token_, edit `/etc/gitlab/gitlab.rb`:
```ruby
gitaly['auth_token'] = 'abc123secret'
```
There are two ways to configure the _GitLab Shell token_.
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
Method 1 (recommended):
There are two ways to configure the GitLab Shell token.
Method 1:
1. Copy `/etc/gitlab/gitlab-secrets.json` from the Gitaly client to same path on the Gitaly servers
Copy `/etc/gitlab/gitlab-secrets.json` from the Gitaly client to same path on the Gitaly servers
(and any other Gitaly clients).
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure) on Gitaly servers.
Method 2:
1. On the Gitaly clients, edit `/etc/gitlab/gitlab.rb`:
Edit `/etc/gitlab/gitlab.rb`:
```ruby
gitlab_shell['secret_token'] = 'shellsecret'
```
1. Save the file and [reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
1. On the Gitaly servers, edit `/etc/gitlab/gitlab.rb`:
```ruby
gitlab_shell['secret_token'] = 'shellsecret'
```
1. [Reconfigure GitLab](../restart_gitlab.md#omnibus-gitlab-reconfigure).
**For installations from source**
1. Copy `/home/git/gitlab/.gitlab_shell_secret` from the Gitaly client to the same path on the
@ -203,14 +195,7 @@ Method 2:
1. Save the file and [restart GitLab](../restart_gitlab.md#installations-from-source).
### Configure Gitaly servers
On the Gitaly servers, you must configure storage paths and enable the network listener.
The Gitaly server must be able to read, write, and set permissions on the configured path.
If you want to reduce the risk of downtime when you enable authentication, you can temporarily
disable enforcement. For more information, see the documentation on configuring
[Gitaly authentication](https://gitlab.com/gitlab-org/gitaly/blob/master/doc/configuration/README.md#authentication).
#### Configure Gitaly server
**For Omnibus GitLab**

2
doc/administration/index.md
View File

@ -215,7 +215,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
- [GitLab application limits](instance_limits.md)
- [Responding to security incidents](../security/responding_to_security_incidents.md)
### Support Team Docs
### Support Team Documentation
The GitLab Support Team has collected a lot of information about troubleshooting GitLab.
The following documents are used by the Support Team or by customers

4
doc/administration/package_information/deprecation_policy.md
View File

@ -41,7 +41,7 @@ We can differentiate two different types of configuration:
installation usable (like a change in default project/group settings, or
miscommunication with other components)
We also need to differentiate deprecation and removal procedure.
We must also differentiate deprecation and removal procedure.
#### Deprecating configuration
@ -78,7 +78,7 @@ The final comment in the issue **has to have**:
1. Text snippet for the release blog post section
1. Documentation MR ( or snippet ) for introducing the change
1. Draft MR removing the configuration OR details on what needs to be done. See [Adding deprecation messages](https://docs.gitlab.com/omnibus/development/adding-deprecation-messages.html) for more on this
1. Draft MR removing the configuration or details on what must be done. See [Adding deprecation messages](https://docs.gitlab.com/omnibus/development/adding-deprecation-messages.html) for more on this
## Example

10
doc/administration/package_information/postgresql_versions.md
View File

@ -29,18 +29,18 @@ Read more about update policies and warnings in the PostgreSQL
| GitLab version | PostgreSQL versions | Default version for fresh installs | Default version for upgrades | Notes |
| -------------- | --------------------- | ---------------------------------- | ---------------------------- | ----- |
| 15.0 | 12.10, 13.6 | 13.6 | 12.10 | For upgrades, users can manually upgrade to 13.6 following the [upgrade docs](https://docs.gitlab.com/omnibus/settings/database.html#gitlab-150-and-later). |
| 15.0 | 12.10, 13.6 | 13.6 | 12.10 | For upgrades, users can manually upgrade to 13.6 following the [upgrade documentation](https://docs.gitlab.com/omnibus/settings/database.html#gitlab-150-and-later). |
| 14.1 | 12.7, 13.3 | 12.7 | 12.7 | PostgreSQL 13 available for fresh installations if not using [Geo](../geo/index.md#requirements-for-running-geo) or [Patroni](../postgresql/index.md#postgresql-replication-and-failover-with-omnibus-gitlab).
| 14.0 | 12.7 | 12.7 | 12.7 | HA installations with repmgr are no longer supported and are prevented from upgrading to Omnibus GitLab 14.0 |
| 13.8 | 11.9, 12.4 | 12.4 | 12.4 | Package upgrades automatically performed PostgreSQL upgrade for nodes that are not part of a Geo or HA cluster.). |
| 13.7 | 11.9, 12.4 | 12.4 | 11.9 | For upgrades users can manually upgrade to 12.4 following the [upgrade docs](https://docs.gitlab.com/omnibus/settings/database.html#gitlab-133-and-later). |
| 13.7 | 11.9, 12.4 | 12.4 | 11.9 | For upgrades users can manually upgrade to 12.4 following the [upgrade documentation](https://docs.gitlab.com/omnibus/settings/database.html#gitlab-133-and-later). |
| 13.4 | 11.9, 12.4 | 11.9 | 11.9 | Package upgrades aborted if users not running PostgreSQL 11 already |
| 13.3 | 11.7, 12.3 | 11.7 | 11.7 | Package upgrades aborted if users not running PostgreSQL 11 already |
| 13.0 | 11.7 | 11.7 | 11.7 | Package upgrades aborted if users not running PostgreSQL 11 already |
| 12.10 | 9.6.17, 10.12, and 11.7 | 11.7 | 11.7 | Package upgrades automatically performed PostgreSQL upgrade for nodes that are not part of a Geo or repmgr cluster. |
| 12.8 | 9.6.17, 10.12, and 11.7 | 10.12 | 10.12 | Users can manually upgrade to 11.7 following the upgrade docs. |
| 12.8 | 9.6.17, 10.12, and 11.7 | 10.12 | 10.12 | Users can manually upgrade to 11.7 following the upgrade documentation. |
| 12.0 | 9.6.11 and 10.7 | 10.7 | 10.7 | Package upgrades automatically performed PostgreSQL upgrade. |
| 11.11 | 9.6.11 and 10.7 | 9.6.11 | 9.6.11 | Users can manually upgrade to 10.7 following the upgrade docs. |
| 11.11 | 9.6.11 and 10.7 | 9.6.11 | 9.6.11 | Users can manually upgrade to 10.7 following the upgrade documentation. |
| 10.0 | 9.6.3 | 9.6.3 | 9.6.3 | Package upgrades aborted if users still on 9.2. |
| 9.0 | 9.2.18 and 9.6.1 | 9.6.1 | 9.6.1 | Package upgrades automatically performed PostgreSQL upgrade. |
| 8.14 | 9.2.18 and 9.6.1 | 9.2.18 | 9.2.18 | Users can manually upgrade to 9.6 following the upgrade docs. |
| 8.14 | 9.2.18 and 9.6.1 | 9.2.18 | 9.2.18 | Users can manually upgrade to 9.6 following the upgrade documentation. |

36
doc/administration/package_information/supported_os.md
View File

@ -15,27 +15,27 @@ page](https://about.gitlab.com/install/).
The following lists the currently supported OSs and their possible EOL dates.
| OS Version | First supported GitLab version | Arch | Install Docs | OS EOL | Details |
| OS Version | First supported GitLab version | Arch | Install Documentation | OS EOL | Details |
| ------------------------------------------------------------ | ------------------------------ | --------------- | :----------------------------------------------------------: | ---------- | ------------------------------------------------------------ |
| AlmaLinux 8 | GitLab CE / GitLab EE 14.5.0 | x86_64, aarch64 | [AlmaLinux Install Docs](https://about.gitlab.com/install/#almalinux-8) | 2029 | <https://almalinux.org/> |
| CentOS 7 | GitLab CE / GitLab EE 7.10.0 | x86_64 | [CentOS Install Docs](https://about.gitlab.com/install/#centos-7) | June 2024 | <https://wiki.centos.org/About/Product> |
| Debian 9 | GitLab CE / GitLab EE 9.3.0 | amd64 | [Debian Install Docs](https://about.gitlab.com/install/#debian) | 2022 | <https://wiki.debian.org/LTS> |
| Debian 10 | GitLab CE / GitLab EE 12.2.0 | amd64, arm64 | [Debian Install Docs](https://about.gitlab.com/install/#debian) | 2024 | <https://wiki.debian.org/LTS> |
| Debian 11 | GitLab CE / GitLab EE 14.6.0 | amd64, arm64 | [Debian Install Docs](https://about.gitlab.com/install/#debian) | 2026 | <https://wiki.debian.org/LTS> |
| OpenSUSE 15.3 | GitLab CE / GitLab EE 14.5.0 | x86_64, aarch64 | [OpenSUSE Install Docs](https://about.gitlab.com/install/#opensuse-leap-15-3) | Nov 2022 | <https://en.opensuse.org/Lifetime> |
| RHEL 8 | GitLab CE / GitLab EE 12.8.1 | x86_64, arm64 | [Use CentOS Install Docs](https://about.gitlab.com/install/#centos-7) | May 2024 | [RHEL Details](https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates) |
| SLES 12 | GitLab EE 9.0.0 | x86_64 | [Use OpenSUSE Install Docs](https://about.gitlab.com/install/#opensuse-leap-15-3) | Oct 2027 | <https://www.suse.com/lifecycle/> |
| Oracle Linux | GitLab CE / GitLab EE 8.14.0 | x86_64 | [Use CentOS Install Docs](https://about.gitlab.com/install/#centos-7) | Jul 2024 | <https://www.oracle.com/a/ocom/docs/elsp-lifetime-069338.pdf> |
| Scientific Linux | GitLab CE / GitLab EE 8.14.0 | x86_64 | [Use CentOS Install Docs](https://about.gitlab.com/install/#centos-7) | June 2024 | <https://scientificlinux.org/downloads/sl-versions/sl7/> |
| Ubuntu 18.04 | GitLab CE / GitLab EE 10.7.0 | amd64 | [Ubuntu Install Docs](https://about.gitlab.com/install/#ubuntu) | April 2023 | <https://wiki.ubuntu.com/Releases> |
| Ubuntu 20.04 | GitLab CE / GitLab EE 13.2.0 | amd64, arm64 | [Ubuntu Install Docs](https://about.gitlab.com/install/#ubuntu) | April 2025 | <https://wiki.ubuntu.com/Releases> |
| Amazon Linux 2 | GitLab CE / GitLab EE 14.9.0 | amd64, arm64 | [Amazon Linux 2 Install Docs](https://about.gitlab.com/install/#amazonlinux-2) | June 2023 | <https://aws.amazon.com/amazon-linux-2/faqs/> |
| Raspberry Pi OS (Buster) (formerly known as Raspbian Buster) | GitLab CE 12.2.0 | armhf | [Raspberry Pi Install Docs](https://about.gitlab.com/install/#raspberry-pi-os) | 2024 | [Raspberry Pi Details](https://www.raspberrypi.com/news/new-old-functionality-with-raspberry-pi-os-legacy/) |
| AlmaLinux 8 | GitLab CE / GitLab EE 14.5.0 | x86_64, aarch64 | [AlmaLinux Install Documentation](https://about.gitlab.com/install/#almalinux-8) | 2029 | <https://almalinux.org/> |
| CentOS 7 | GitLab CE / GitLab EE 7.10.0 | x86_64 | [CentOS Install Documentation](https://about.gitlab.com/install/#centos-7) | June 2024 | <https://wiki.centos.org/About/Product> |
| Debian 9 | GitLab CE / GitLab EE 9.3.0 | amd64 | [Debian Install Documentation](https://about.gitlab.com/install/#debian) | 2022 | <https://wiki.debian.org/LTS> |
| Debian 10 | GitLab CE / GitLab EE 12.2.0 | amd64, arm64 | [Debian Install Documentation](https://about.gitlab.com/install/#debian) | 2024 | <https://wiki.debian.org/LTS> |
| Debian 11 | GitLab CE / GitLab EE 14.6.0 | amd64, arm64 | [Debian Install Documentation](https://about.gitlab.com/install/#debian) | 2026 | <https://wiki.debian.org/LTS> |
| OpenSUSE 15.3 | GitLab CE / GitLab EE 14.5.0 | x86_64, aarch64 | [OpenSUSE Install Documentation](https://about.gitlab.com/install/#opensuse-leap-15-3) | Nov 2022 | <https://en.opensuse.org/Lifetime> |
| RHEL 8 | GitLab CE / GitLab EE 12.8.1 | x86_64, arm64 | [Use CentOS Install Documentation](https://about.gitlab.com/install/#centos-7) | May 2024 | [RHEL Details](https://access.redhat.com/support/policy/updates/errata/#Life_Cycle_Dates) |
| SLES 12 | GitLab EE 9.0.0 | x86_64 | [Use OpenSUSE Install Documentation](https://about.gitlab.com/install/#opensuse-leap-15-3) | Oct 2027 | <https://www.suse.com/lifecycle/> |
| Oracle Linux | GitLab CE / GitLab EE 8.14.0 | x86_64 | [Use CentOS Install Documentation](https://about.gitlab.com/install/#centos-7) | Jul 2024 | <https://www.oracle.com/a/ocom/docs/elsp-lifetime-069338.pdf> |
| Scientific Linux | GitLab CE / GitLab EE 8.14.0 | x86_64 | [Use CentOS Install Documentation](https://about.gitlab.com/install/#centos-7) | June 2024 | <https://scientificlinux.org/downloads/sl-versions/sl7/> |
| Ubuntu 18.04 | GitLab CE / GitLab EE 10.7.0 | amd64 | [Ubuntu Install Documentation](https://about.gitlab.com/install/#ubuntu) | April 2023 | <https://wiki.ubuntu.com/Releases> |
| Ubuntu 20.04 | GitLab CE / GitLab EE 13.2.0 | amd64, arm64 | [Ubuntu Install Documentation](https://about.gitlab.com/install/#ubuntu) | April 2025 | <https://wiki.ubuntu.com/Releases> |
| Amazon Linux 2 | GitLab CE / GitLab EE 14.9.0 | amd64, arm64 | [Amazon Linux 2 Install Documentation](https://about.gitlab.com/install/#amazonlinux-2) | June 2023 | <https://aws.amazon.com/amazon-linux-2/faqs/> |
| Raspberry Pi OS (Buster) (formerly known as Raspbian Buster) | GitLab CE 12.2.0 | armhf | [Raspberry Pi Install Documentation](https://about.gitlab.com/install/#raspberry-pi-os) | 2024 | [Raspberry Pi Details](https://www.raspberrypi.com/news/new-old-functionality-with-raspberry-pi-os-legacy/) |
NOTE:
CentOS 8 was EOL on December 31, 2021. In GitLab 14.5 and later,
[CentOS builds work in AlmaLinux](https://gitlab.com/gitlab-org/distribution/team-tasks/-/issues/954#note_730198505).
We will officially support all distributions that are binary compatible with Red Hat Enterprise Linux.
We officially support all distributions that are binary compatible with Red Hat Enterprise Linux.
This gives users a path forward for their CentOS 8 builds at its end of life.
## Update GitLab package sources after upgrading the OS
@ -47,7 +47,7 @@ If your package manager reports that no further updates are available,
although [new versions have been released](https://about.gitlab.com/releases/categories/releases/), repeat the
"Add the GitLab package repository" instructions
of the [Linux package install guide](https://about.gitlab.com/install/#content).
Future GitLab upgrades will now be fetched according to your upgraded OS.
Future GitLab upgrades are fetched according to your upgraded OS.
## Packages for ARM64
@ -64,7 +64,7 @@ running GitLab on ARM.
## OS Versions that are no longer supported
GitLab provides omnibus packages for operating systems only until their
EOL (End-Of-Life). After the EOL date of the OS, GitLab will stop releasing
EOL (End-Of-Life). After the EOL date of the OS, GitLab stops releasing
official packages. The list of deprecated operating systems and the final GitLab
release for them can be found below:

2
doc/administration/raketasks/check.md
View File

@ -211,7 +211,7 @@ secrets file (`gitlab-secrets.json`).
Automatic resolution is not yet implemented. If you have values that
cannot be decrypted, you can follow steps to reset them, see our
docs on what to do [when the secrets file is lost](../../raketasks/backup_restore.md#when-the-secrets-file-is-lost).
documentation on what to do [when the secrets file is lost](../../raketasks/backup_restore.md#when-the-secrets-file-is-lost).
This can take a very long time, depending on the size of your
database, as it checks all rows in all tables.

2
doc/development/backend/ruby_style_guide.md
View File

@ -16,7 +16,7 @@ document the new rule. For every new guideline, add it in a new section and link
[version history note](../documentation/versions.md#add-a-version-history-item)
to provide context and serve as a reference.
Just because something is listed here does not mean it cannot be reopened for discussion.
Everything listed here can be [reopened for discussion](https://about.gitlab.com/handbook/values/#disagree-commit-and-disagree).
## Instance variable access using `attr_reader`

2
doc/development/documentation/styleguide/index.md
View File

@ -49,7 +49,7 @@ GitLab adds all troubleshooting information to the documentation, no matter how
unlikely a user is to encounter a situation.
GitLab Support maintains their own
[troubleshooting content](../../../administration/index.md#support-team-docs)
[troubleshooting content](../../../administration/index.md#support-team-documentation)
in the GitLab documentation.
### The documentation includes all media types

30
doc/development/geo.md
View File

@ -25,6 +25,20 @@ Geo handles replication for different components:
With the exception of the Database replication, on a *secondary* site, everything is coordinated
by the [Geo Log Cursor](#geo-log-cursor-daemon).
### Replication states
The following diagram illustrates how the replication works. Some allowed transitions are omitted for clarity.
```mermaid
stateDiagram-v2
Pending --> Started
Started --> Synced
Started --> Failed
Synced --> Pending: Mark for resync
Failed --> Pending: Mark for resync
Failed --> Started: Retry
```
### Geo Log Cursor daemon
The [Geo Log Cursor daemon](#geo-log-cursor-daemon) is a separate process running on
@ -426,6 +440,22 @@ ignores items in object storage. Either:
## Verification
### Verification states
The following diagram illustrates how the verification works. Some allowed transitions are omitted for clarity.
```mermaid
stateDiagram-v2
Pending --> Started
Pending --> Disabled: No primary checksum
Disabled --> Started: Primary checksum succeeded
Started --> Succeeded
Started --> Failed
Succeeded --> Pending: Mark for reverify
Failed --> Pending: Mark for reverify
Failed --> Started: Retry
```
### Repository verification
Repositories are verified with a checksum.

16
doc/install/aws/gitlab_sre_for_aws.md
View File

@ -23,15 +23,15 @@ If you would like to understand the underlying rationale on why GitLab had to in
### Gitaly and Praefect elections
As part of Gitaly cluster consistency, Praefect nodes will occasionally need to vote on what data copy is the most accurate. This requires an uneven number of Praefect nodes to avoid stalemates. This means that for HA, Gitaly and Praefect require a minimum of three nodes.
As part of Gitaly cluster consistency, Praefect nodes must occasionally vote on what data copy is the most accurate. This requires an uneven number of Praefect nodes to avoid stalemates. This means that for HA, Gitaly and Praefect require a minimum of three nodes.
### Gitaly performance monitoring
Complete performance metrics should be collected for Gitaly instances for identification of bottlenecks, as they could have to do with disk IO, network IO or memory.
Complete performance metrics should be collected for Gitaly instances for identification of bottlenecks, as they could have to do with disk IO, network IO, or memory.
### Gitaly performance guidelines
Gitaly functions as the primary Git Repository Storage in GitLab. However, it's not simply a streaming file server. It also does a lot of demanding computing work, such as preparing and caching Git pack files which informs some of the performance recommendations below.
Gitaly functions as the primary Git Repository Storage in GitLab. However, it's not a streaming file server. It also does a lot of demanding computing work, such as preparing and caching Git pack files which informs some of the performance recommendations below.
NOTE:
All recommendations are for production configurations, including performance testing. For test configurations, like training or functional testing, you can use less expensive options. However, you should adjust or rebuild if performance is an issue.
@ -45,7 +45,7 @@ All recommendations are for production configurations, including performance tes
#### CPU and memory recommendations
- The general GitLab Gitaly node recommendations for CPU and Memory assume relatively even loading across repositories. GPT testing of any non-characteristic repositories and/or SRE monitoring of Gitaly metrics may inform when to choose memory and/or CPU higher than general recommendations.
- The general GitLab Gitaly node recommendations for CPU and Memory assume relatively even loading across repositories. GitLab Performance Tool (GPT) testing of any non-characteristic repositories and/or SRE monitoring of Gitaly metrics may inform when to choose memory and/or CPU higher than general recommendations.
**To accommodate:**
@ -54,9 +54,9 @@ All recommendations are for production configurations, including performance tes
#### Disk I/O recommendations
- Use only SSD storage and the [class of EBS storage](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html) that suites your durability and speed requirements.
- Use only SSD storage and the [class of Elastic Block Store (EBS) storage](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ebs-volume-types.html) that suites your durability and speed requirements.
- When not using provisioned EBS IO, EBS volume size determines the I/O level, so provisioning volumes that are much larger than needed can be the least expensive way to improve EBS IO.
- If Gitaly performance monitoring shows signs of disk stress then one of the provisioned IOPs levels can be chosen. Note that EBS IOPs levels also have enhanced durability which may be appealing for some implementations aside from performance considerations.
- If Gitaly performance monitoring shows signs of disk stress then one of the provisioned IOPs levels can be chosen. EBS IOPs levels also have enhanced durability which may be appealing for some implementations aside from performance considerations.
**To accommodate:**
@ -66,7 +66,7 @@ All recommendations are for production configurations, including performance tes
#### Network I/O recommendations
- Use only instance types [from the list of ones that support ENA advanced networking]( https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#instance-type-summary-table) to ensure that cluster replication latency is not due to instance level network I/O bottlenecks.
- Use only instance types [from the list of ones that support Elastic Network Adapter (ENA) advanced networking](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instance-types.html#instance-type-summary-table) to ensure that cluster replication latency is not due to instance level network I/O bottlenecks.
- Choose instances with sizes with more than 10 Gbps - but only if needed and only when having proven a node level network bottleneck with monitoring and/or stress testing.
**To accommodate:**
@ -93,4 +93,4 @@ The [AWS GitLab Cloud Native Hybrid on EKS Quick Start](gitlab_hybrid_on_aws.md#
### Gitaly long term management
Gitaly node disk sizes will need to be monitored and increased to accommodate Git repository growth and Gitaly temporary and caching storage needs. The storage configuration on all nodes should be kept identical.
Gitaly node disk sizes must be monitored and increased to accommodate Git repository growth and Gitaly temporary and caching storage needs. The storage configuration on all nodes should be kept identical.

22
doc/install/aws/index.md
View File

@ -11,7 +11,7 @@ type: index
GitLab [Reference Architectures](../../administration/reference_architectures/index.md) give qualified and tested guidance on the recommended ways GitLab can be configured to meet the performance requirements of various workloads. Reference Architectures are purpose-designed to be non-implementation specific so they can be extrapolated to as many environments as possible. This generally means they have a highly-granular "machine" to "server role" specification and focus on system elements that impact performance. This is what enables Reference Architectures to be adaptable to the broadest number of supported implementations.
Implementation patterns are built on the foundational information and testing done for Reference Architectures and allow architects and implementers at GitLab, GitLab Customers, and GitLab Partners to build out deployments with less experimentation and a higher degree of confidence that the results will perform as expected. A more thorough discussion of implementation patterns is below in [Additional details on implementation patterns](#additional-details-on-implementation-patterns).
Implementation patterns are built on the foundational information and testing done for Reference Architectures and allow architects and implementers at GitLab, GitLab Customers, and GitLab Partners to build out deployments with less experimentation and a higher degree of confidence that the results perform as expected. A more thorough discussion of implementation patterns is below in [Additional details on implementation patterns](#additional-details-on-implementation-patterns).
## AWS Implementation patterns information
@ -19,7 +19,7 @@ The following are the currently available implementation patterns for GitLab whe
### GitLab Site Reliability Engineering (SRE) for AWS
[GitLab Site Reliability Engineering (SRE) for AWS](gitlab_sre_for_aws.md) - information for planning, implementing, upgrading and long term management of GitLab instances and runners on AWS.
[GitLab Site Reliability Engineering (SRE) for AWS](gitlab_sre_for_aws.md) - information for planning, implementing, upgrading, and long term management of GitLab instances and runners on AWS.
### Patterns to Install GitLab Cloud Native Hybrid on AWS EKS (HA)
@ -33,7 +33,7 @@ The following are the currently available implementation patterns for GitLab whe
[EKS Cluster Provisioning Patterns](eks_clusters_aws.md) - considerations for setting up EKS cluster for runners and for integrating.
### Patterns for Scaling HA GitLab Runner on AWS EC2 ASG
### Patterns for Scaling HA GitLab Runner on AWS EC2 Auto Scaling group (ASG)
The following repository is self-contained in regard to enabling this pattern: [GitLab HA Scaling Runner Vending Machine for AWS EC2 ASG](https://gitlab.com/guided-explorations/aws/gitlab-runner-autoscaling-aws-asg/). The [feature list for this implementation pattern](https://gitlab.com/guided-explorations/aws/gitlab-runner-autoscaling-aws-asg/-/blob/main/FEATURES.md) is good to review to understand the complete value it can deliver.
@ -47,23 +47,23 @@ The following repository is self-contained in regard to enabling this pattern: [
## AWS known issues list
Known issues are gathered from within GitLab and from customer reported issues. Customers successfully implement GitLab with a variety of "as a Service" components that GitLab has not specifically been designed for, nor has ongoing testing for. While GitLab does take partner technologies very seriously, the highlighting of known issues here is a convenience for implementers and it does not imply that GitLab has targeted compatibility with, nor carries any type of guarantee of running on the partner technology where the issues occur. Please consult individual issues to understand GitLabs stance and plans on any given known issue.
Known issues are gathered from within GitLab and from customer reported issues. Customers successfully implement GitLab with a variety of "as a Service" components that GitLab has not specifically been designed for, nor has ongoing testing for. While GitLab does take partner technologies very seriously, the highlighting of known issues here is a convenience for implementers and it does not imply that GitLab has targeted compatibility with, nor carries any type of guarantee of running on the partner technology where the issues occur. Consult individual issues to understand the GitLab stance and plans on any given known issue.
See the [GitLab AWS known issues list](https://gitlab.com/gitlab-com/alliances/aws/public-tracker/-/issues?label_name%5B%5D=AWS+Known+Issue) for a complete list.
## Official GitLab releases as AMIs
GitLab produces AMI images during the regular release process. The AMIs can be used for single instance GitLab installation or, by configuring `/etc/gitlab/gitlab.rb`, can be specialized for specific GitLab service roles (for example a Gitaly server). Older releases remain available and can be used to migrate an older GitLab server to AWS.
GitLab produces Amazon Machine Images (AMI) during the regular release process. The AMIs can be used for single instance GitLab installation or, by configuring `/etc/gitlab/gitlab.rb`, can be specialized for specific GitLab service roles (for example a Gitaly server). Older releases remain available and can be used to migrate an older GitLab server to AWS.
Currently the Amazon AMI uses the Amazon prepared Ubuntu AMI (x86 and ARM are available) as its starting point.
NOTE:
When deploying a GitLab instance using the official AMI, the root password to the instance will be the EC2 **Instance** ID (NOT the AMI ID). This way of setting the root account password is specific to official GitLab published AMIs ONLY.
When deploying a GitLab instance using the official AMI, the root password to the instance is the EC2 **Instance** ID (not the AMI ID). This way of setting the root account password is specific to official GitLab published AMIs ONLY.
Instances running on Community Edition (CE) require a migration to Enterprise Edition (EE) in order to subscribe to the GitLab Premium or Ultimate plan. If you want to pursue a subscription, using the Free-forever plan of Enterprise Edition is the least disruptive method.
Instances running on Community Edition (CE) require a migration to Enterprise Edition (EE) to subscribe to the GitLab Premium or Ultimate plan. If you want to pursue a subscription, using the Free-forever plan of Enterprise Edition is the least disruptive method.
NOTE:
Since any given GitLab upgrade might involve data disk updates or database schema upgrades, simply swapping out the AMI is not sufficient for taking upgrades.
Because any given GitLab upgrade might involve data disk updates or database schema upgrades, swapping out the AMI is not sufficient for taking upgrades.
1. Log in to the AWS Web Console, so that clicking the links in the following step take you directly to the AMI list.
1. Pick the edition you want:
@ -72,9 +72,9 @@ Since any given GitLab upgrade might involve data disk updates or database schem
- [GitLab Community Edition](https://console.aws.amazon.com/ec2/v2/home?region=us-east-1#Images:visibility=public-images;ownerAlias=782774275127;search=GitLab%20CE;sort=desc:name): The open source version of GitLab.
- [GitLab Premium or Ultimate Marketplace (Prelicensed)](https://console.aws.amazon.com/ec2/v2/home?region=us-east-1#Images:visibility=public-images;source=Marketplace;search=GitLab%20EE;sort=desc:name): 5 user license built into per-minute billing.
1. AMI IDs are unique per region, so once you've loaded one of the above, select the desired target region in the upper right of the console to see the appropriate AMIs.
1. AMI IDs are unique per region, so after you've loaded one of the above, select the desired target region in the upper right of the console to see the appropriate AMIs.
1. After the console is loaded, you can add additional search criteria to narrow further. For instance, type `13.` to find only 13.x versions.
1. To launch an EC2 Machine with one of the listed AMIs, check the box at the start of the relevant row, and select the "Launch" button near the top of left of the page.
1. To launch an EC2 Machine with one of the listed AMIs, check the box at the start of the relevant row, and select **Launch** near the top of left of the page.
NOTE:
If you are trying to restore from an older version of GitLab while moving to AWS, find the
@ -88,7 +88,7 @@ GitLab implementation patterns build upon [GitLab Reference Architectures](../..
Testing-backed architectural qualification is a fundamental concept behind implementation patterns:
- Implementation patterns maintain GitLab Reference Architecture compliance and provide [GitLab Performance Tool](https://gitlab.com/gitlab-org/quality/performance) (gpt) reports to demonstrate adherence to them.
- Implementation patterns maintain GitLab Reference Architecture compliance and provide [GitLab Performance Tool](https://gitlab.com/gitlab-org/quality/performance) (GPT) reports to demonstrate adherence to them.
- Implementation patterns may be qualified by and/or contributed to by the technology vendor. For instance, an implementation pattern for AWS may be officially reviewed by AWS.
- Implementation patterns may specify and test Cloud Platform PaaS services for suitability for GitLab. This testing can be coordinated and help qualify these technologies for Reference Architectures. For instance, qualifying compatibility with and availability of runtime versions of top level PaaS such as those for PostgreSQL and Redis.
- Implementation patterns can provided qualified testing for platform limitations, for example, ensuring Gitaly Cluster can work correctly on specific Cloud Platform availability zone latency and throughput characteristics or qualifying what levels of available platform partner local disk performance is workable for Gitaly server to operate with integrity.

34
doc/install/installation.md
View File

@ -27,20 +27,20 @@ following the
## Consider the Omnibus package installation
Since an installation from source is a lot of work and error prone we strongly recommend the fast and reliable [Omnibus package installation](https://about.gitlab.com/install/) (deb/rpm).
Because an installation from source is a lot of work and error prone we strongly recommend the fast and reliable [Omnibus package installation](https://about.gitlab.com/install/) (deb/rpm).
One reason the Omnibus package is more reliable is its use of runit to restart any of the GitLab processes in case one crashes.
On heavily used GitLab instances the memory usage of the Sidekiq background worker grows over time.
Omnibus packages solve this by [letting the Sidekiq terminate gracefully](../administration/operations/sidekiq_memory_killer.md) if it uses too much memory.
After this termination runit detects Sidekiq is not running and starts it.
Since installations from source don't use runit for process supervision, Sidekiq
Because installations from source don't use runit for process supervision, Sidekiq
can't be terminated and its memory usage grows over time.
## Select a version to install
Make sure you view [this installation guide](https://gitlab.com/gitlab-org/gitlab/-/blob/master/doc/install/installation.md) from the branch (version) of GitLab you would like to install (for example, `11-7-stable`).
You can select the branch in the version dropdown in the top left corner of GitLab (below the menu bar).
You can select the branch in the version dropdown list in the top left corner of GitLab (below the menu bar).
If the highest number stable branch is unclear, check the [GitLab blog](https://about.gitlab.com/blog/) for installation guide links by version.
@ -51,7 +51,7 @@ If the highest number stable branch is unclear, check the [GitLab blog](https://
| [Ruby](#2-ruby) | `2.7` | From GitLab 13.6, Ruby 2.7 is required. Ruby 3.0 is not supported yet (see [the relevant epic](https://gitlab.com/groups/gitlab-org/-/epics/5149) for the current status). You must use the standard MRI implementation of Ruby. We love [JRuby](https://www.jruby.org/) and [Rubinius](https://github.com/rubinius/rubinius#the-rubinius-language-platform), but GitLab needs several Gems that have native extensions. |
| [Go](#3-go) | `1.16` | |
| [Git](#git) | `2.33.x` | From GitLab 14.4, Git 2.33.x and later is required. It's highly recommended that you use the [Git version provided by Gitaly](#git). |
| [Node.js](#4-node) | `14.15.0` | GitLab uses [webpack](https://webpack.js.org/) to compile frontend assets. Node.js 16.x is recommended, as it's faster. You can check which version you're running with `node -v`. You need to update it to a newer version if needed. |
| [Node.js](#4-node) | `14.15.0` | GitLab uses [webpack](https://webpack.js.org/) to compile frontend assets. Node.js 16.x is recommended, as it's faster. You can check which version you're running with `node -v`. You must update it to a newer version if needed. |
## GitLab directory structure
@ -179,7 +179,7 @@ the Git path:
### GraphicsMagick
For the [Custom Favicon](../user/admin_area/appearance.md#favicon) to work, GraphicsMagick
needs to be installed.
must be installed.
```shell
sudo apt-get install -y graphicsmagick
@ -187,7 +187,7 @@ sudo apt-get install -y graphicsmagick
### Mail server
In order to receive mail notifications, make sure to install a mail server.
To receive mail notifications, make sure to install a mail server.
By default, Debian is shipped with `exim4` but this
[has problems](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/12754) while
Ubuntu does not ship with one. The recommended mail server is `postfix` and you
@ -264,7 +264,7 @@ requirements for these are:
In many distributions,
the versions provided by the official package repositories are out of date, so
we need to install through the following commands:
we must install through the following commands:
```shell
# install node v16.x
@ -298,7 +298,7 @@ In GitLab 12.1 and later, only PostgreSQL is supported. In GitLab 14.0 and later
```
For Ubuntu 18.04 and earlier, the available PostgreSQL doesn't meet the minimum
version requirement. You need to add PostgreSQL's repository:
version requirement. You must add PostgreSQL's repository:
```shell
wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | sudo apt-key add -
@ -426,7 +426,7 @@ sudo usermod -aG redis git
### Supervise Redis with systemd
If your distribution uses systemd init and the output of the following command is `notify`,
you do not need to make any changes:
you must not make any changes:
```shell
systemctl show --value --property=Type redis-server.service
@ -678,7 +678,7 @@ sudo -u git -H bundle exec rake "gitlab:indexer:install[/home/git/gitlab-elastic
```
The source code first is fetched to the path specified by the first parameter. Then a binary is built under its `bin` directory.
You then need to update `gitlab.yml`'s `production -> elasticsearch -> indexer_path` setting to point to that binary.
You must then update `gitlab.yml`'s `production -> elasticsearch -> indexer_path` setting to point to that binary.
### Install GitLab Pages
@ -740,7 +740,7 @@ sudo systemctl daemon-reload
The units provided by GitLab make very little assumptions about where you are running Redis and PostgreSQL.
If you installed GitLab in another directory or as a user other than the default, you need to change these values in the units as well.
If you installed GitLab in another directory or as a user other than the default, you must change these values in the units as well.
For example, if you're running Redis and PostgreSQL on the same machine as GitLab, you should:
@ -853,7 +853,7 @@ sudo -u git -H bundle exec rake gitlab:setup RAILS_ENV=production force=yes
# When done, you see 'Administrator account created:'
```
You can set the Administrator/root password and email by supplying them in environmental variables, `GITLAB_ROOT_PASSWORD` and `GITLAB_ROOT_EMAIL` respectively, as seen below. If you don't set the password (and it is set to the default one), wait to expose GitLab to the public internet until the installation is done and you've logged into the server the first time. During the first login, you'll be forced to change the default password. An Enterprise Edition license may also be installed at this time by supplying a full path in the `GITLAB_LICENSE_FILE` environment variable.
You can set the Administrator/root password and email by supplying them in environmental variables, `GITLAB_ROOT_PASSWORD` and `GITLAB_ROOT_EMAIL` respectively, as seen below. If you don't set the password (and it is set to the default one), wait to expose GitLab to the public internet until the installation is done and you've logged into the server the first time. During the first login, you are forced to change the default password. An Enterprise Edition license may also be installed at this time by supplying a full path in the `GITLAB_LICENSE_FILE` environment variable.
```shell
sudo -u git -H bundle exec rake gitlab:setup RAILS_ENV=production GITLAB_ROOT_PASSWORD=yourpassword GITLAB_ROOT_EMAIL=youremail GITLAB_LICENSE_FILE="/path/to/license"
@ -942,7 +942,7 @@ to use. Read all about the needed configuration at the
If you want to use HTTPS, replace the `gitlab` NGINX configuration with `gitlab-ssl`. See [Using HTTPS](#using-https) for HTTPS configuration details.
For the NGINX to be able to read the GitLab-Workhorse socket, you need to make sure, that the `www-data` user can read the socket, which will be owned by the GitLab user. This is most easily achieved, if it is world-readable, for example that it has permissions `0755`, which is the default. `www-data` also needs to be able to list the parent directories.
For the NGINX to be able to read the GitLab-Workhorse socket, you must make sure, that the `www-data` user can read the socket, which is owned by the GitLab user. This is achieved, if it is world-readable, for example that it has permissions `0755`, which is the default. `www-data` also must be able to list the parent directories.
### Test Configuration
@ -999,8 +999,8 @@ Supply the `SANITIZE=true` environment variable to `gitlab:check` to omit projec
Visit YOUR_SERVER in your web browser for your first GitLab login.
If you didn't [provide a root password during setup](#initialize-database-and-activate-advanced-features),
you'll be redirected to a password reset screen to provide the password for the
initial administrator account. Enter your desired password and you'll be
you are redirected to a password reset screen to provide the password for the
initial administrator account. Enter your desired password and you are
redirected back to the login screen.
The default account's username is **root**. Provide the password you created
@ -1114,7 +1114,7 @@ host localhost # Give your setup a name (here: override localhost)
hostname 127.0.0.1; # Your server name or IP
```
You also need to change the corresponding options (for example, `ssh_user`, `ssh_host`, `admin_uri`) in the `config/gitlab.yml` file.
You must also change the corresponding options (for example, `ssh_user`, `ssh_host`, `admin_uri`) in the `config/gitlab.yml` file.
### Additional Markup Styles
@ -1123,7 +1123,7 @@ Apart from the always supported Markdown style, there are other rich text files
### Using Sidekiq instead of Sidekiq Cluster
As of GitLab 12.10, Source installations are using `bin/sidekiq-cluster` for managing Sidekiq processes.
Using Sidekiq directly is still supported until 14.0. So if you're experiencing issues, please:
Using Sidekiq directly is still supported until 14.0. So if you're experiencing issues:
1. Edit the system `init.d` script to remove the `SIDEKIQ_WORKERS` flag. If you have `/etc/default/gitlab`, then you should edit it instead.
1. Restart GitLab.

16
doc/install/requirements.md
View File

@ -26,16 +26,16 @@ For the installation options, see [the main installation page](index.md).
- macOS
Installation of GitLab on these operating systems is possible, but not supported.
Please see the [installation from source guide](installation.md) and the [installation guides](https://about.gitlab.com/install/) for more information.
See the [installation from source guide](installation.md) and the [installation guides](https://about.gitlab.com/install/) for more information.
Please see [OS versions that are no longer supported](../administration/package_information/supported_os.md#os-versions-that-are-no-longer-supported) for Omnibus installs page
See [OS versions that are no longer supported](../administration/package_information/supported_os.md#os-versions-that-are-no-longer-supported) for Omnibus installs page
for a list of supported and unsupported OS versions as well as the last support GitLab version for that OS.
### Microsoft Windows
GitLab is developed for Linux-based operating systems.
It does **not** run on Microsoft Windows, and we have no plans to support it in the near future. For the latest development status view this [issue](https://gitlab.com/gitlab-org/gitlab/-/issues/22337).
Please consider using a virtual machine to run GitLab.
Consider using a virtual machine to run GitLab.
## Software requirements
@ -61,7 +61,7 @@ Apart from a local hard drive you can also mount a volume that supports the netw
If you have enough RAM and a recent CPU the speed of GitLab is mainly limited by hard drive seek times. Having a fast drive (7200 RPM and up) or a solid state drive (SSD) improves the responsiveness of GitLab.
NOTE:
Since file system performance may affect the overall performance of GitLab,
Because file system performance may affect the overall performance of GitLab,
[we don't recommend using cloud-based file systems for storage](../administration/nfs.md#avoid-using-cloud-based-file-systems).
NOTE:
@ -251,9 +251,9 @@ works.
### Puma per worker maximum memory
By default, each Puma worker will be limited to 1024 MB of memory.
By default, each Puma worker is limited to 1024 MB of memory.
This setting [can be adjusted](../administration/operations/puma.md#change-the-memory-limit-setting) and should be considered
if you need to increase the number of Puma workers.
if you must increase the number of Puma workers.
## Redis and Sidekiq
@ -279,7 +279,7 @@ to install GitLab on. Depending on how you decide to configure GitLab Runner and
what tools you use to exercise your application in the CI environment, GitLab
Runner can consume significant amount of available memory.
Memory consumption calculations, that are available above, won't be valid if
Memory consumption calculations, that are available above, are not valid if
you decide to run GitLab Runner and the GitLab Rails application on the same
machine.
@ -295,7 +295,7 @@ The GitLab Runner server requirements depend on:
- Resources required to run build jobs.
- Job concurrency settings.
Since the nature of the jobs varies for each use case, you need to experiment by adjusting the job concurrency to get the optimum setting.
Because the nature of the jobs varies for each use case, you must experiment by adjusting the job concurrency to get the optimum setting.
For reference, the [SaaS runners on Linux](../ci/runners/saas/linux_saas_runner.md)
are configured so that a **single job** runs in a **single instance** with:

9
doc/user/application_security/index.md
View File

@ -476,17 +476,16 @@ GitLab provides two methods of accomplishing this, each with advantages and disa
- [Compliance framework pipelines](../project/settings/#compliance-pipeline-configuration)
are recommended when:
- Scan execution enforcement is required for SAST or Secret Detection scans that use custom rulesets.
- Scan execution enforcement is required for SAST IaC, Dependency Scanning,
- Scan execution enforcement is required for any scanner that uses a GitLab template, such as SAST IaC, DAST, Dependency Scanning,
License Compliance, API Fuzzing, or Coverage-guided Fuzzing.
- Scan execution enforcement is required for scanners external to GitLab.
- Enforced execution is required for custom jobs other than security scans.
- Scan execution enforcement is required for custom jobs other than security scans.
- [Scan execution policies](policies/scan-execution-policies.md)
are recommended when:
- Scan execution enforcement is required for DAST.
- Scan execution enforcement is required for Container Scanning with project-specific variable
- Scan execution enforcement is required for DAST which uses a DAST site or scan profile.
- Scan execution enforcement is required for SAST, Secret Detection, or Container Scanning with project-specific variable
customizations. To accomplish this, users must create a separate security policy per project.
- Scans are required to run on a regular, scheduled cadence.

7
doc/user/application_security/vulnerabilities/index.md
View File

@ -206,7 +206,12 @@ To enable security training for vulnerabilities in your project:
> [Introduced](https://gitlab.com/groups/gitlab-org/-/epics/6176) in GitLab 14.9.
If security training is enabled, the vulnerability page includes a training link relevant to the detected vulnerability.
The vulnerability page may include a training link relevant to the detected vulnerability if security training is enabled.
The availability of training depends on whether the enabled training vendor has content matching the particular vulnerability.
Training content is requested based on the [vulnerability identifiers](../../../development/integrations/secure.md#identifiers).
The identifier given to a vulnerability will vary from one vulnerability to the next. The available training
content varies between vendors. This means some vulnerabilities will display no training content.
Vulnerabilities with a CWE are most likely to return a training result.
To view the security training for a vulnerability:

6
doc/user/project/merge_requests/approvals/settings.md
View File

@ -55,7 +55,7 @@ this setting, unless you configure one of these options:
> Moved to GitLab Premium in 13.9.
By default, users who commit to a merge request can still approve it. At both
the project level or [instance level](../../../admin_area/merge_requests_approvals.md)
the project level or [instance level](../../../admin_area/merge_requests_approvals.md),
you can prevent committers from approving merge requests that are partially
their own. To do this:
@ -82,7 +82,7 @@ read the official Git documentation for an explanation.
## Prevent editing approval rules in merge requests
By default, users can override the approval rules you [create for a project](rules.md)
on a per-merge request basis. If you don't want users to change approval rules
on a per-merge-request basis. If you don't want users to change approval rules
on merge requests, you can disable this setting:
1. Go to your project and select **Settings > General**.
@ -119,7 +119,7 @@ when more changes are added to it:
1. Select the **Remove all approvals when commits are added to the source branch** checkbox.
1. Select **Save changes**.
Approvals aren't reset when a merge request is [rebased from the UI](../methods/index.md#rebasing-in-semi-linear-merge-methods)
Approvals aren't reset when a merge request is [rebased from the UI](../methods/index.md#rebasing-in-semi-linear-merge-methods).
However, approvals are reset if the target branch is changed.
## Code coverage check approvals

2
qa/qa/resource/ssh_key.rb
View File

@ -10,7 +10,7 @@ module QA
attribute :id
def_delegators :key, :private_key, :public_key, :md5_fingerprint
def_delegators :key, :private_key, :public_key, :md5_fingerprint, :sha256_fingerprint
def initialize
self.title = Time.now.to_f

9
qa/qa/runtime/feature.rb
View File

@ -59,7 +59,14 @@ module QA
feature['state'] == 'conditional' && scopes.present? && enabled_scope?(feature['gates'], **scopes)
else
# The feature wasn't found via the API so we check for a default value.
pattern = "#{File.expand_path('../{ee/,}config/feature_flags', QA::Runtime::Path.qa_root)}/**/#{key}.yml"
# We expand the path include both ee and jh.
pattern = if GitlabEdition.jh?
"#{File.expand_path('../{ee/,jh/,}config/feature_flags', QA::Runtime::Path.qa_root)}/**/#{key}.yml"
else
"#{File.expand_path('../{ee/,}config/feature_flags', QA::Runtime::Path.qa_root)}/**/#{key}.yml"
end
file = Dir.glob(pattern).first
raise UnknownFeatureFlagError, "No feature flag found named '#{key}'" unless file

10
qa/qa/runtime/key/base.rb
View File

@ -4,7 +4,7 @@ module QA
module Runtime
module Key
class Base
attr_reader :name, :bits, :private_key, :public_key, :md5_fingerprint
attr_reader :name, :bits, :private_key, :public_key, :md5_fingerprint, :sha256_fingerprint
def initialize(name, bits)
@name = name
@ -26,11 +26,15 @@ module QA
Service::Shellout.shell(cmd)
end
def fingerprint(path, hash_alg)
`ssh-keygen -l -E #{hash_alg} -f #{path} | cut -d' ' -f2 | cut -d: -f2-`.chomp
end
def populate_key_data(path)
@private_key = ::File.binread(path)
@public_key = ::File.binread("#{path}.pub")
@md5_fingerprint =
`ssh-keygen -l -E md5 -f #{path} | cut -d' ' -f2 | cut -d: -f2-`.chomp
@md5_fingerprint = fingerprint(path, :md5)
@sha256_fingerprint = fingerprint(path, :sha256)
end
end
end

2
qa/qa/specs/features/browser_ui/3_create/repository/push_over_ssh_spec.rb
View File

@ -2,7 +2,7 @@
module QA
RSpec.describe 'Create' do
describe 'SSH key support', :skip_fips_env do
describe 'SSH key support' do
# Note: If you run these tests against GDK make sure you've enabled sshd
# See: https://gitlab.com/gitlab-org/gitlab-qa/blob/master/docs/run_qa_against_gdk.md

6
qa/qa/specs/features/browser_ui/3_create/repository/ssh_key_support_spec.rb
View File

@ -2,7 +2,7 @@
module QA
RSpec.describe 'Create' do
describe 'SSH keys support', :smoke, :skip_fips_env do
describe 'SSH keys support', :smoke do
key_title = "key for ssh tests #{Time.now.to_f}"
key = nil
@ -16,7 +16,7 @@ module QA
end
expect(page).to have_content(key.title)
expect(page).to have_content(key.md5_fingerprint)
expect(page).to have_content(key.sha256_fingerprint)
end
# Note this context ensures that the example it contains is executed after the example above. Be aware of the order of execution if you add new examples in either context.
@ -29,7 +29,7 @@ module QA
end
expect(page).not_to have_content("Title: #{key.title}")
expect(page).not_to have_content(key.md5_fingerprint)
expect(page).not_to have_content(key.sha256_fingerprint)
end
end
end

2
qa/qa/specs/features/browser_ui/3_create/snippet/clone_push_pull_personal_snippet_spec.rb
View File

@ -2,7 +2,7 @@
module QA
RSpec.describe 'Create' do
describe 'Version control for personal snippets', :skip_fips_env do
describe 'Version control for personal snippets' do
let(:new_file) { 'new_snippet_file' }
let(:changed_content) { 'changes' }
let(:commit_message) { 'Changes to snippets' }

2
qa/qa/specs/features/browser_ui/3_create/snippet/clone_push_pull_project_snippet_spec.rb
View File

@ -2,7 +2,7 @@
module QA
RSpec.describe 'Create' do
describe 'Version control for project snippets', :skip_fips_env do
describe 'Version control for project snippets' do
let(:new_file) { 'new_snippet_file' }
let(:changed_content) { 'changes' }
let(:commit_message) { 'Changes to snippets' }