Welcome to mirror list, hosted at ThFree Co, Russian Federation.

gitlab.com/gitlab-org/gitlab-foss.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
path: root/doc
diff options
context:
space:
mode:
Diffstat (limited to 'doc')
-rw-r--r--doc/development/pipelines/index.md39
-rw-r--r--doc/development/pipelines/internals.md4
-rw-r--r--doc/development/project_templates.md164
-rw-r--r--doc/development/sec/security_report_ingestion_overview.md7
-rw-r--r--doc/development/testing_guide/end_to_end/running_tests_that_require_special_setup.md2
-rw-r--r--doc/development/testing_guide/flaky_tests.md9
-rw-r--r--doc/integration/saml.md2
-rw-r--r--doc/user/application_security/sast/index.md16
-rw-r--r--doc/user/group/saml_sso/index.md62
-rw-r--r--doc/user/project/merge_requests/approvals/rules.md3
10 files changed, 124 insertions, 184 deletions
diff --git a/doc/development/pipelines/index.md b/doc/development/pipelines/index.md
index b56259dbdaf..9fcbe8c55e4 100644
--- a/doc/development/pipelines/index.md
+++ b/doc/development/pipelines/index.md
@@ -150,8 +150,8 @@ This number can be overridden by setting a CI/CD variable named `RSPEC_FAIL_FAST
## Re-run previously failed tests in merge request pipelines
-In order to reduce the feedback time after resolving failed tests for a merge request, the `rspec rspec-pg12-rerun-previous-failed-tests`
-and `rspec rspec-ee-pg12-rerun-previous-failed-tests` jobs run the failed tests from the previous MR pipeline.
+In order to reduce the feedback time after resolving failed tests for a merge request, the `rspec rspec-pg13-rerun-previous-failed-tests`
+and `rspec rspec-ee-pg13-rerun-previous-failed-tests` jobs run the failed tests from the previous MR pipeline.
This was introduced on August 25th 2021, with <https://gitlab.com/gitlab-org/gitlab/-/merge_requests/69053>.
@@ -159,7 +159,7 @@ This was introduced on August 25th 2021, with <https://gitlab.com/gitlab-org/git
1. The `detect-previous-failed-tests` job (`prepare` stage) detects the test files associated with failed RSpec
jobs from the previous MR pipeline.
-1. The `rspec rspec-pg12-rerun-previous-failed-tests` and `rspec rspec-ee-pg12-rerun-previous-failed-tests` jobs
+1. The `rspec rspec-pg13-rerun-previous-failed-tests` and `rspec rspec-ee-pg13-rerun-previous-failed-tests` jobs
will run the test files gathered by the `detect-previous-failed-tests` job.
```mermaid
@@ -169,8 +169,8 @@ graph LR
end
subgraph "test stage";
- B["rspec rspec-pg12-rerun-previous-failed-tests"];
- C["rspec rspec-ee-pg12-rerun-previous-failed-tests"];
+ B["rspec rspec-pg13-rerun-previous-failed-tests"];
+ C["rspec rspec-ee-pg13-rerun-previous-failed-tests"];
end
A --"artifact: list of test files"--> B & C
@@ -483,20 +483,22 @@ This should let us:
### PostgreSQL versions testing
-Our test suite runs against PG12 as GitLab.com runs on PG12 and
-[Omnibus defaults to PG12 for new installs and upgrades](../../administration/package_information/postgresql_versions.md).
+Our test suite runs against PG13 as GitLab.com runs on PG13 and
+[Omnibus defaults to PG13 for new installs and upgrades](../../administration/package_information/postgresql_versions.md).
We do run our test suite against PG13 on nightly scheduled pipelines.
+We also run our test suite against PG13 upon specific database library changes in MRs and `main` pipelines (with the `rspec db-library-code pg13` job).
+
#### Current versions testing
-| Where? | PostgreSQL version | Ruby version |
-|------------------------------------------------------------------------------------------------|--------------------------|-----------------------|
-| Merge requests | 12 (default version) | 3.0 (default version) |
-| `master` branch commits | 12 (default version) | 3.0 (default version) |
-| `maintenance` scheduled pipelines for the `master` branch (every even-numbered hour) | 12 (default version) | 3.0 (default version) |
-| `maintenance` scheduled pipelines for the `ruby2` branch (every odd-numbered hour), see below. | 12 (default version) | 2.7 |
-| `nightly` scheduled pipelines for the `master` branch | 12 (default version), 13 | 3.0 (default version) |
+| Where? | PostgreSQL version | Ruby version |
+|------------------------------------------------------------------------------------------------|-------------------------------------------------|-----------------------|
+| Merge requests | 13 (default version), 12 for DB library changes | 3.0 (default version) |
+| `master` branch commits | 13 (default version), 12 for DB library changes | 3.0 (default version) |
+| `maintenance` scheduled pipelines for the `master` branch (every even-numbered hour) | 13 (default version), 12 for DB library changes | 3.0 (default version) |
+| `maintenance` scheduled pipelines for the `ruby2` branch (every odd-numbered hour), see below. | 13 (default version), 12 for DB library changes | 2.7 |
+| `nightly` scheduled pipelines for the `master` branch | 13 (default version), 12, 14 | 3.0 (default version) |
There are 2 pipeline schedules used for testing Ruby 2.7. One is triggering a
pipeline in `ruby2-sync` branch, which updates the `ruby2` branch with latest
@@ -511,15 +513,6 @@ The `gitlab` job in the `ruby2-sync` branch uses a `gitlab-org/gitlab` project
token with `write_repository` scope and `Maintainer` role with no expiration.
The token is stored in the `RUBY2_SYNC_TOKEN` variable in `gitlab-org/gitlab`.
-#### Long-term plan
-
-We follow the [PostgreSQL versions shipped with Omnibus GitLab](../../administration/package_information/postgresql_versions.md):
-
-| PostgreSQL version | 14.1 (July 2021) | 14.2 (August 2021) | 14.3 (September 2021) | 14.4 (October 2021) | 14.5 (November 2021) | 14.6 (December 2021) |
-| -------------------| ---------------------- | ---------------------- | ---------------------- | ---------------------- | ---------------------- | ---------------------- |
-| PG12 | MRs/`2-hour`/`nightly` | MRs/`2-hour`/`nightly` | MRs/`2-hour`/`nightly` | MRs/`2-hour`/`nightly` | MRs/`2-hour`/`nightly` | MRs/`2-hour`/`nightly` |
-| PG13 | `nightly` | `nightly` | `nightly` | `nightly` | `nightly` | `nightly` |
-
### Redis versions testing
Our test suite runs against Redis 6 as GitLab.com runs on Redis 6 and
diff --git a/doc/development/pipelines/internals.md b/doc/development/pipelines/internals.md
index bd96f2f2872..81b95eb204f 100644
--- a/doc/development/pipelines/internals.md
+++ b/doc/development/pipelines/internals.md
@@ -136,10 +136,10 @@ that are scoped to a single [configuration keyword](../../ci/yaml/index.md#job-k
| `.qa-cache` | Allows a job to use a default `cache` definition suitable for QA tasks. |
| `.yarn-cache` | Allows a job to use a default `cache` definition suitable for frontend jobs that do a `yarn install`. |
| `.assets-compile-cache` | Allows a job to use a default `cache` definition suitable for frontend jobs that compile assets. |
-| `.use-pg12` | Allows a job to use the `postgres` 12 and `redis` services (see [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml) for the specific versions of the services). |
-| `.use-pg12-ee` | Same as `.use-pg12` but also use an `elasticsearch` service (see [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml) for the specific version of the service). |
| `.use-pg13` | Allows a job to use the `postgres` 13 and `redis` services (see [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml) for the specific versions of the services). |
| `.use-pg13-ee` | Same as `.use-pg13` but also use an `elasticsearch` service (see [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml) for the specific version of the service). |
+| `.use-pg14` | Allows a job to use the `postgres` 14 and `redis` services (see [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml) for the specific versions of the services). |
+| `.use-pg14-ee` | Same as `.use-pg14` but also use an `elasticsearch` service (see [`.gitlab/ci/global.gitlab-ci.yml`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/.gitlab/ci/global.gitlab-ci.yml) for the specific version of the service). |
| `.use-kaniko` | Allows a job to use the `kaniko` tool to build Docker images. |
| `.as-if-foss` | Simulate the FOSS project by setting the `FOSS_ONLY='1'` CI/CD variable. |
| `.use-docker-in-docker` | Allows a job to use Docker in Docker. |
diff --git a/doc/development/project_templates.md b/doc/development/project_templates.md
index 31537b21527..cc53ef77c62 100644
--- a/doc/development/project_templates.md
+++ b/doc/development/project_templates.md
@@ -8,110 +8,63 @@ info: "To determine the technical writer assigned to the Stage/Group associated
## Adding a new built-in project template
-This page provides instructions about how to contribute a
-[built-in project template](../user/project/index.md#create-a-project-from-a-built-in-template).
-
-To contribute a built-in project template, you must complete the following tasks:
-
-1. [Create a project template for GitLab review](#create-a-project-template-for-review)
-1. [Add the template SVG icon to GitLab SVGs](#add-the-template-svg-icon-to-gitlab-svgs)
-1. [Create a merge request with vendor details](#create-a-merge-request-with-vendor-details)
-
-You can contribute the following types of project templates:
-
-- Enterprise: For users with GitLab Premium and above.
-- Non-enterprise: For users with GitLab Free and above.
-
-### Prerequisites
-
-To add or update an existing template, you must have the following tools
-installed:
-
-- `wget`
-- `tar`
-
-### Create a project template for review
-
-1. In your selected namespace, create a public project.
-1. Add the project content you want to use in the template. Do not include unnecessary assets or dependencies. For an example,
-[see this project](https://gitlab.com/gitlab-org/project-templates/dotnetcore).
-1. When the project is ready for review, [create an issue](https://gitlab.com/gitlab-org/gitlab/-/issues) with a link to your project.
- In your issue, mention the Create:Source Code [Backend Engineering Manager and Product Manager](https://about.gitlab.com/handbook/product/categories/#source-code-group)
- for the Templates feature.
-
-### Add the template SVG icon to GitLab SVGs
-
-If the project template has an SVG icon, you must add it to the
-[GitLab SVGs project](https://gitlab.com/gitlab-org/gitlab-svgs/-/blob/main/README.md#adding-icons-or-illustrations)
-before you can create a merge request with vendor details.
-
-### Create a merge request with vendor details
-
-Before GitLab can implement the project template, you must [create a merge request](../user/project/merge_requests/creating_merge_requests.md) in [`gitlab-org/gitlab`](https://gitlab.com/gitlab-org/gitlab) that includes vendor details about the project.
-
-1. [Export the project](../user/project/settings/import_export.md#export-a-project-and-its-data)
- and save the file as `<name>.tar.gz`, where `<name>` is the short name of the project.
- Move this file to the root directory of `gitlab-org/gitlab`.
-1. In `gitlab-org/gitlab`, create and check out a new branch.
-1. Edit the following files to include the project template:
- - For **non-Enterprise** project templates:
- - In `lib/gitlab/project_template.rb`, add details about the template
- in the `localized_templates_table` method. In the following example,
- the short name of the project is `hugo`:
-
- ```ruby
- ProjectTemplate.new('hugo', 'Pages/Hugo', _('Everything you need to create a GitLab Pages site using Hugo'), 'https://gitlab.com/pages/hugo', 'illustrations/logos/hugo.svg'),
- ```
-
- If the project doesn't have an SVG icon, exclude `, 'illustrations/logos/hugo.svg'`.
-
- - In `spec/support/helpers/project_template_test_helper.rb`, append the short name
- of the template in the `all_templates` method.
- - In `app/assets/javascripts/projects/default_project_templates.js`,
- add details of the template. For example:
-
- ```javascript
- hugo: {
- text: s__('ProjectTemplates|Pages/Hugo'),
- icon: '.template-option .icon-hugo',
- },
- ```
-
- If the project doesn't have an SVG icon, use `.icon-gitlab_logo`
- instead.
- - For **Enterprise** project templates:
- - In `ee/lib/ee/gitlab/project_template.rb`, in the `localized_ee_templates_table` method, add details about the template. For example:
-
- ```ruby
- ::Gitlab::ProjectTemplate.new('hipaa_audit_protocol', 'HIPAA Audit Protocol', _('A project containing issues for each audit inquiry in the HIPAA Audit Protocol published by the U.S. Department of Health & Human Services'), 'https://gitlab.com/gitlab-org/project-templates/hipaa-audit-protocol', 'illustrations/logos/asklepian.svg')
- ```
-
- - In `ee/spec/lib/gitlab/project_template_spec.rb`, add the short name
- of the template in the `.all` test.
- - In `ee/app/assets/javascripts/projects/default_project_templates.js`,
- add the template details. For example:
-
- ```javascript
- hipaa_audit_protocol: {
- text: s__('ProjectTemplates|HIPAA Audit Protocol'),
- icon: '.template-option .icon-hipaa_audit_protocol',
- },
- ```
-
-1. Run the following Rake task, where `<path>/<name>` is the
- name you gave the template in `lib/gitlab/project_template.rb`:
+If you'd like to contribute a new built-in project template to be distributed with GitLab, please do the following:
+
+1. Create a new public project with the project content you'd like to contribute in a namespace of your choosing. You can view a working example [here](https://gitlab.com/gitlab-org/project-templates/dotnetcore).
+ - Projects should be as simple as possible and free of any unnecessary assets or dependencies.
+1. When the project is ready for review, please create a new issue in [GitLab](https://gitlab.com/gitlab-org/gitlab/issues) with a link to your project.
+ - In your issue, `@` mention the relevant Backend Engineering Manager and Product Manager for the [Create:Source Code group](https://about.gitlab.com/handbook/product/categories/#source-code-group).
+
+To make the project template available when creating a new project, the vendoring process will have to be completed:
+
+1. Create a working template ([example](https://gitlab.com/gitlab-org/project-templates/dotnetcore))
+ - 2 types of built-in templates are available within GitLab:
+ - **Normal templates**: Available in GitLab Core, Starter and above (this is the most common type of built-in template).
+ - To contribute a normal template:
+ - Add details of the template in the `localized_templates_table` method in `gitlab/lib/gitlab/project_template.rb`,
+ - Add details of the template in `spec/lib/gitlab/project_template_spec.rb`, in the test for the `all` method, and
+ - Add details of the template in `gitlab/app/assets/javascripts/projects/default_project_templates.js`.
+ - See MR [!25318](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25318) for an example
+ - **Enterprise templates**: Introduced in GitLab 12.10, that are available only in GitLab Gold & Ultimate.
+ - To contribute an Enterprise template:
+ - Add details of the template in the `localized_ee_templates_table` method in `gitlab/ee/lib/ee/gitlab/project_template.rb`,
+ - Add details of the template in `gitlab/ee/spec/lib/gitlab/project_template_spec.rb`, in the `enterprise_templates` method, and
+ - Add details of the template in `gitlab/ee/app/assets/javascripts/projects/default_project_templates.js`.
+ - See MR [!28187](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/28187) for an example.
+
+1. Run the following in the `gitlab` project, where `$name` is the name you gave the template in `gitlab/project_template.rb`:
```shell
- bin/rake gitlab:update_project_templates\[<path>/<name>\]
+ bin/rake gitlab:update_project_templates[$name]
```
-1. Regenerate `gitlab.pot`:
-
- ```shell
- bin/rake gettext:regenerate
- ```
-
-1. After you run the scripts, there is one new file in `vendor/project_templates/` and four changed files. Commit all changes and push your branch to update the merge request. For an example, see this [merge request](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25318).
+1. Run the `bundle_repo` script. Make sure to pass the correct arguments, or the script may damage the folder structure.
+1. Add exported project (`$name.tar.gz`) to `gitlab/vendor/project_templates` and remove the resulting build folders `tar-base` and `project`.
+1. Run `bin/rake gettext:regenerate` in the `gitlab` project and commit new `.pot` file.
+1. Add a changelog entry in the commit message (for example, `Changelog: added`).
+ For more information, see [Changelog entries](changelog.md).
+1. Add an icon to [`gitlab-svgs`](https://gitlab.com/gitlab-org/gitlab-svgs), as shown in
+ [this example](https://gitlab.com/gitlab-org/gitlab-svgs/merge_requests/195). If a logo
+ is not available for the project, use the default 'Tanuki' logo instead.
+1. Run `yarn run svgs` on `gitlab-svgs` project and commit result.
+1. Forward changes in `gitlab-svgs` project to master. This involves:
+ - Merging your MR in `gitlab-svgs`
+ - [The bot](https://gitlab.com/gitlab-org/frontend/renovate-gitlab-bot/)
+ will pick the new release up and create an MR in `gitlab-org/gitlab`.
+1. Once the bot-created MR created above is merged, you can rebase your template MR onto the updated `master` to pick up the new svgs.
+1. Test everything is working.
+
+### Contributing an improvement to an existing template
+
+Existing templates are available in the [project-templates](https://gitlab.com/gitlab-org/project-templates)
+group.
+
+To contribute a change, please open a merge request in the relevant project
+and mention `@gitlab-org/manage/import/backend` when you are ready for a review.
+
+Then, if your merge request gets accepted, either open an issue on
+`gitlab` to ask for it to get updated, or open a merge request updating
+the vendored template using [these instructions](rake_tasks.md#update-project-templates).
### Test your built-in project with the GitLab Development Kit
@@ -124,17 +77,6 @@ Complete the following steps to test the project template in your own GitLab Dev
bin/rake gitlab:update_project_templates\[<path>/<name>\]
```
-## Contribute an improvement to an existing template
-
-To update an existing built-in project template, changes are usually made to the existing template, found in the [project-templates](https://gitlab.com/gitlab-org/project-templates) group. A merge request is made directly against the template and the Create:Source Code [Backend Engineering Manager and Product Manager](https://about.gitlab.com/handbook/product/categories/#source-code-group) pinged for review.
-
-Sometimes it is necessary to completely replace the template files. In this case the process would be:
-
-1. Create a merge request in the relevant project of the `project-templates` and `pages` group and mention `@gitlab-org/manage/import/backend` when you are ready for a review.
-1. If your merge request is accepted, either:
- - [Create an issue](https://gitlab.com/gitlab-org/gitlab/-/issues) to ask for the template to get updated.
- - [Create a merge request with vendor details](#create-a-merge-request-with-vendor-details) to update the template.
-
## For GitLab team members
Please ensure the merge request has been reviewed by the Security Counterpart before merging.
diff --git a/doc/development/sec/security_report_ingestion_overview.md b/doc/development/sec/security_report_ingestion_overview.md
index 688986e0eb1..f2b4f100c8b 100644
--- a/doc/development/sec/security_report_ingestion_overview.md
+++ b/doc/development/sec/security_report_ingestion_overview.md
@@ -28,9 +28,10 @@ Assumptions:
1. GitLab CI runs a new pipeline for that branch.
1. Pipeline status transitions to any of [`::Ci::Pipeline.completed_statuses`](https://gitlab.com/gitlab-org/gitlab/-/blob/354261b2fe4fc5b86d1408467beadd90e466ce0a/app/models/concerns/ci/has_status.rb#L12).
1. `Security::StoreScansWorker` is called and it schedules `Security::StoreScansService`.
-1. `Security::StoreScansService` calls `Security::StoreGroupedScansService`.
+1. `Security::StoreScansService` calls `Security::StoreGroupedScansService` and schedules `ScanSecurityReportSecretsWorker`.
1. `Security::StoreGroupedScansService` calls `Security::StoreScanService`.
1. `Security::StoreScanService` calls `Security::StoreFindingsService`.
+1. `ScanSecurityReportSecretsWorker` calls `Security::TokenRevocationService` to revoke any leaked keys.
1. At this point we have `Security::Finding` objects **only**.
At this point, the following things can happen to the `Security::Finding`:
@@ -41,8 +42,8 @@ At this point, the following things can happen to the `Security::Finding`:
If the pipeline ran on the default branch then the following, additional steps are done:
-1. `Security::StoreScansService` gets called and schedules `Security::StoreSecurityReportsWorker`.
-1. `Security::StoreSecurityReportsWorker` executes `Security::Ingestion::IngestReportsService`.
+1. `Security::StoreScansService` gets called and schedules `StoreSecurityReportsWorker`.
+1. `StoreSecurityReportsWorker` executes `Security::Ingestion::IngestReportsService`.
1. `Security::Ingestion::IngestReportsService` takes all reports from a given Pipeline and calls `Security::Ingestion::IngestReportService` and then calls `Security::Ingestion::MarkAsResolvedService`.
1. `Security::Ingestion::IngestReportService` calls `Security::Ingestion::IngestReportSliceService` which executes a number of tasks for a report slice.
diff --git a/doc/development/testing_guide/end_to_end/running_tests_that_require_special_setup.md b/doc/development/testing_guide/end_to_end/running_tests_that_require_special_setup.md
index 0d6d7a161c7..bf4d750423d 100644
--- a/doc/development/testing_guide/end_to_end/running_tests_that_require_special_setup.md
+++ b/doc/development/testing_guide/end_to_end/running_tests_that_require_special_setup.md
@@ -428,6 +428,8 @@ For instructions on how to run these tests using the `gitlab-qa` gem, please ref
Tests that are tagged with `:mobile` can be run against specified mobile devices using cloud emulator/simulator services.
+These tests run in the [nightly pipeline](https://gitlab.com/gitlab-org/quality/nightly/-/pipelines) in the `ce:remote_mobile_safari` job.
+
### How to run mobile tests with Sauce Labs
Running directly against an environment like staging is not recommended because Sauce Labs test logs expose credentials. Therefore, it is best practice and the default to use a tunnel.
diff --git a/doc/development/testing_guide/flaky_tests.md b/doc/development/testing_guide/flaky_tests.md
index c626a4fa81c..4f4ba71aac5 100644
--- a/doc/development/testing_guide/flaky_tests.md
+++ b/doc/development/testing_guide/flaky_tests.md
@@ -150,7 +150,7 @@ usually a good idea.
## Quarantined tests
-When a test frequently fails in `master`,
+When a test fails in `master`,
create [a ~"failure::flaky-test" issue](https://about.gitlab.com/handbook/engineering/workflow/#broken-master).
If the test cannot be fixed in a timely fashion, there is an impact on the
@@ -158,6 +158,7 @@ productivity of all the developers, so it should be quarantined. There are two w
### RSpec
+Add the corresponding category and group labels to issue using [`feature_category` metadata](../feature_categorization/index.md#rspec-examples).
For RSpec tests, you can use the `:quarantine` metadata with the issue URL.
```ruby
@@ -300,6 +301,12 @@ If a spec hangs, it might be caused by a [bug in Rails](https://github.com/rails
- <https://gitlab.com/gitlab-org/gitlab/-/merge_requests/81112>
- <https://gitlab.com/gitlab-org/gitlab/-/issues/337039>
+## Suggestions
+
+### Split the test file
+
+It could help to split the large RSpec files in multiple files in order to narrow down the context and identify the problematic tests.
+
## Resources
- [Flaky Tests: Are You Sure You Want to Rerun Them?](https://semaphoreci.com/blog/2017/04/20/flaky-tests.html)
diff --git a/doc/integration/saml.md b/doc/integration/saml.md
index 888dd47a968..195ca6bd904 100644
--- a/doc/integration/saml.md
+++ b/doc/integration/saml.md
@@ -699,7 +699,7 @@ When configuring the Google Workspace SAML application, record the following inf
| | Value | Description |
|-------------|--------------|-----------------------------------------------------------------------------------|
| SSO URL | Depends | Google Identity Provider details. Set to the GitLab `idp_sso_target_url` setting. |
-| Certificate | Downloadable | Run `openssl x509 -in <your_certificate.crt> -noout -fingerprint` to generate the SHA1 fingerprint that can be used in the `idp_cert_fingerprint` setting. |
+| Certificate | Downloadable | Run `openssl x509 -in <your_certificate.crt> -noout -fingerprint -sha1` to generate the SHA1 fingerprint that can be used in the `idp_cert_fingerprint` setting. |
Google Workspace Administrator also provides the IdP metadata, Entity ID, and SHA-256
fingerprint. However, GitLab does not need this information to connect to the
diff --git a/doc/user/application_security/sast/index.md b/doc/user/application_security/sast/index.md
index 82ceaad244d..5776072f77b 100644
--- a/doc/user/application_security/sast/index.md
+++ b/doc/user/application_security/sast/index.md
@@ -79,20 +79,20 @@ For more information about our plans for language support in SAST, see the [cate
|------------------------------|--------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------|
| .NET Core | [Security Code Scan](https://gitlab.com/gitlab-org/security-products/analyzers/security-code-scan) | 11.0 |
| .NET Framework<sup>1</sup> | [Security Code Scan](https://gitlab.com/gitlab-org/security-products/analyzers/security-code-scan) | 13.0 |
-| .NET (all versions, C# only) | [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep) with GitLab-managed rules | 15.4 |
+| .NET (all versions, C# only) | [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep) with [GitLab-managed rules](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/blob/main/RULES.md) | 15.4 |
| Apex (Salesforce) | [PMD](https://gitlab.com/gitlab-org/security-products/analyzers/pmd-apex) | 12.1 |
-| C | [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep) with GitLab-managed rules | 14.2 |
+| C | [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep) with [GitLab-managed rules](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/blob/main/RULES.md) | 14.2 |
| C/C++ | [Flawfinder](https://gitlab.com/gitlab-org/security-products/analyzers/flawfinder) | 10.7 |
| Elixir (Phoenix) | [Sobelow](https://gitlab.com/gitlab-org/security-products/analyzers/sobelow) | 11.1 |
| Go<sup>3</sup> | [Gosec](https://gitlab.com/gitlab-org/security-products/analyzers/gosec) | 10.7 |
-| Go | [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep) with GitLab-managed rules | 14.4 |
+| Go | [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep) with [GitLab-managed rules](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/blob/main/RULES.md) | 14.4 |
| Groovy<sup>2</sup> | [SpotBugs](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs) with the find-sec-bugs plugin | 11.3 (Gradle) & 11.9 (Maven, SBT) |
| Helm Charts | [Kubesec](https://gitlab.com/gitlab-org/security-products/analyzers/kubesec) | 13.1 |
-| Java (any build system) | [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep) with GitLab-managed rules | 14.10 |
+| Java (any build system) | [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep) with [GitLab-managed rules](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/blob/main/RULES.md) | 14.10 |
| Java<sup>2, 3</sup> | [SpotBugs](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs) with the find-sec-bugs plugin | 10.6 (Maven), 10.8 (Gradle) & 11.9 (SBT) |
| Java (Android) | [MobSF (beta)](https://gitlab.com/gitlab-org/security-products/analyzers/mobsf) | 13.5 |
| JavaScript<sup>3</sup> | [ESLint security plugin](https://gitlab.com/gitlab-org/security-products/analyzers/eslint) | 11.8 |
-| JavaScript | [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep) with GitLab-managed rules | 13.10 |
+| JavaScript | [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep) with [GitLab-managed rules](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/blob/main/RULES.md) | 13.10 |
| Kotlin (Android) | [MobSF (beta)](https://gitlab.com/gitlab-org/security-products/analyzers/mobsf) | 13.5 |
| Kotlin (General)<sup>2</sup> | [SpotBugs](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs) with the find-sec-bugs plugin | 13.11 |
| Kubernetes manifests | [Kubesec](https://gitlab.com/gitlab-org/security-products/analyzers/kubesec) | 12.6 |
@@ -100,15 +100,15 @@ For more information about our plans for language support in SAST, see the [cate
| Objective-C (iOS) | [MobSF (beta)](https://gitlab.com/gitlab-org/security-products/analyzers/mobsf) | 13.5 |
| PHP | [phpcs-security-audit](https://gitlab.com/gitlab-org/security-products/analyzers/phpcs-security-audit) | 10.8 |
| Python<sup>3</sup> | [bandit](https://gitlab.com/gitlab-org/security-products/analyzers/bandit) | 10.3 |
-| Python | [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep) with GitLab-managed rules | 13.9 |
+| Python | [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep) with [GitLab-managed rules](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/blob/main/RULES.md) | 13.9 |
| React<sup>3</sup> | [ESLint react plugin](https://gitlab.com/gitlab-org/security-products/analyzers/eslint) | 12.5 |
-| React | [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep) with GitLab-managed rules | 13.10 |
+| React | [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep) with [GitLab-managed rules](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/blob/main/RULES.md) | 13.10 |
| Ruby | [brakeman](https://gitlab.com/gitlab-org/security-products/analyzers/brakeman) | 13.9 |
| Ruby on Rails | [brakeman](https://gitlab.com/gitlab-org/security-products/analyzers/brakeman) | 10.3 |
| Scala<sup>2</sup> | [SpotBugs](https://gitlab.com/gitlab-org/security-products/analyzers/spotbugs) with the find-sec-bugs plugin | 11.0 (SBT) & 11.9 (Gradle, Maven) |
| Swift (iOS) | [MobSF (beta)](https://gitlab.com/gitlab-org/security-products/analyzers/mobsf) | 13.5 |
| TypeScript<sup>3</sup> | [ESLint security plugin](https://gitlab.com/gitlab-org/security-products/analyzers/eslint) | 11.9, [merged](https://gitlab.com/gitlab-org/gitlab/-/issues/36059) with ESLint in 13.2 |
-| TypeScript | [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep) with GitLab-managed rules | 13.10 |
+| TypeScript | [Semgrep](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep) with [GitLab-managed rules](https://gitlab.com/gitlab-org/security-products/analyzers/semgrep/-/blob/main/RULES.md) | 13.10 |
1. .NET 4 support is limited. The analyzer runs in a Linux container and does not have access to Windows-specific libraries or features. Use the Semgrep-based scanner if you need .NET 4 support.
1. The SpotBugs-based analyzer supports [Gradle](https://gradle.org/), [Maven](https://maven.apache.org/), and [SBT](https://www.scala-sbt.org/). It can also be used with variants like the
diff --git a/doc/user/group/saml_sso/index.md b/doc/user/group/saml_sso/index.md
index 347b8cd0a2d..f7e6ea610fe 100644
--- a/doc/user/group/saml_sso/index.md
+++ b/doc/user/group/saml_sso/index.md
@@ -183,6 +183,33 @@ To find this URL:
Check your identity provider's documentation to see if it supports the GitLab metadata URL.
+### Manage the identity provider
+
+After you have set up your identity provider, you can:
+
+- Change the identity provider.
+- Change email domains.
+
+#### Change the identity provider
+
+You can change to a different identity provider. During the change process,
+users cannot access any of the SAML groups. To mitigate this, you can disable
+[SSO enforcement](#sso-enforcement).
+
+To change identity providers:
+
+1. [Configure](#configure-your-identity-provider) the group with the new identity provider.
+1. Optional. If the **NameID** is not identical, [change the **NameID** for users](#change-nameid-for-one-or-more-users).
+
+#### Change email domains
+
+To migrate users to a new email domain, tell users to:
+
+1. Add their new email as the primary email to their accounts and verify it.
+1. Optional. Remove their old email from the account.
+
+If the **NameID** is configured with the email address, [change the **NameID** for users](#change-nameid-for-one-or-more-users).
+
### User attributes
To create users with the correct information for improved [user access and management](#user-access-and-management),
@@ -294,41 +321,6 @@ immediately. If the user:
- Is signed out, they cannot access the group after being removed from the
identity provider.
-### Change the SAML app
-
-After you have configured your identity provider, you can:
-
-- Change the identity provider users sign in with.
-- Migrate to a different identity provider.
-- Change email domains.
-
-#### Change the identity provider
-
-To change the identity provider:
-
-- If the **NameID** value is not identical in the existing and new identity providers, [change the **NameID** for users](#change-nameid-for-one-or-more-users).
-- If the **NameID** value is identical, users do not have to make any changes.
-
-#### Migrate to a different identity provider
-
-You can migrate to a different identity provider. During the migration process,
-users cannot access any of the SAML groups. To mitigate this, you can disable
-[SSO enforcement](#sso-enforcement).
-
-To migrate identity providers:
-
-1. [Configure](#configure-your-identity-provider) the group with the new identity provider.
-1. [Change the **NameID** for users](#change-nameid-for-one-or-more-users).
-
-#### Change email domains
-
-To migrate users to a new email domain, tell users to:
-
-1. Add their new email as the primary email to their accounts and verify it.
-1. Optional. Remove their old email from the account.
-
-If the **NameID** is configured with the email address, [change the **NameID** for users](#change-nameid-for-one-or-more-users).
-
## User access and management
> - SAML user provisioning [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/268142) in GitLab 13.7.
diff --git a/doc/user/project/merge_requests/approvals/rules.md b/doc/user/project/merge_requests/approvals/rules.md
index 0a5e7c29860..7ffb05cb4f1 100644
--- a/doc/user/project/merge_requests/approvals/rules.md
+++ b/doc/user/project/merge_requests/approvals/rules.md
@@ -106,6 +106,9 @@ reduces the number of approvals left (the **Approvals** column) for all rules th
![Approvals premium merge request widget](img/approvals_premium_mr_widget_v13_3.png)
+<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
+For an overview, see [Multiple Approvers](https://www.youtube.com/watch?v=8JQJ5821FrA).
+
## Eligible approvers
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/10294) in GitLab 13.3, when an eligible approver comments on a merge request, it appears in the **Commented by** column of the Approvals widget.
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-04 13:26:08 +0300