Add latest changes from gitlab-org/gitlab@master

5 files changed, 76 insertions, 7 deletions

diff --git a/doc/administration/postgresql/replication_and_failover.md b/doc/administration/postgresql/replication_and_failover.md
index e9b607ad5d4..37471a4f491 100644
--- a/doc/administration/postgresql/replication_and_failover.md
+++ b/doc/administration/postgresql/replication_and_failover.md
@@ -996,7 +996,7 @@ You can switch an exiting database cluster to use Patroni instead of repmgr with
 
 ### Upgrading PostgreSQL major version in a Patroni cluster
 
-As of GitLab 13.3, PostgreSQL 11.7 and 12.3 are both shipped with Omnibus GitLab by default. As of GitLab 13.7, PostgreSQL 12 is the default. If you want to upgrade to PostgreSQL 12 in versions prior to GitLab 13.7, you must ask for it explicitly.
+As of GitLab 14.1, PostgreSQL 12.6 and 13.3 are both shipped with Omnibus GitLab by default. As of GitLab 15.0, PostgreSQL 13 is the default. If you want to upgrade to PostgreSQL 13 in versions prior to GitLab 15.0, you must ask for it explicitly.
 
 WARNING:
 The procedure for upgrading PostgreSQL in a Patroni cluster is different than when upgrading using repmgr.
@@ -1046,7 +1046,7 @@ Considering these, you should carefully plan your PostgreSQL upgrade:
 1. Upgrade PostgreSQL on **the leader node** and make sure that the upgrade is completed successfully:
 
    ```shell
-   sudo gitlab-ctl pg-upgrade -V 12
+   sudo gitlab-ctl pg-upgrade -V 13
    ```
 
    NOTE:
@@ -1073,7 +1073,7 @@ Considering these, you should carefully plan your PostgreSQL upgrade:
 1. Upgrade PostgreSQL **on replicas** (you can do this in parallel on all of them):
 
    ```shell
-   sudo gitlab-ctl pg-upgrade -V 12
+   sudo gitlab-ctl pg-upgrade -V 13
    ```
 
 NOTE:
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index 5c179e18a4b..5b38f524ede 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -5655,6 +5655,7 @@ Input type: `WorkItemUpdateInput`
 | <a id="mutationworkitemupdateid"></a>`id` | [`WorkItemID!`](#workitemid) | Global ID of the work item. |
 | <a id="mutationworkitemupdatestateevent"></a>`stateEvent` | [`WorkItemStateEvent`](#workitemstateevent) | Close or reopen a work item. |
 | <a id="mutationworkitemupdatetitle"></a>`title` | [`String`](#string) | Title of the work item. |
+| <a id="mutationworkitemupdateweightwidget"></a>`weightWidget` | [`WorkItemWidgetWeightInput`](#workitemwidgetweightinput) | Input for weight widget. |
 
 #### Fields
 
@@ -18518,6 +18519,17 @@ Represents a hierarchy widget.
 | <a id="workitemwidgethierarchyparent"></a>`parent` | [`WorkItem`](#workitem) | Parent work item. |
 | <a id="workitemwidgethierarchytype"></a>`type` | [`WorkItemWidgetType`](#workitemwidgettype) | Widget type. |
 
+### `WorkItemWidgetWeight`
+
+Represents a weight widget.
+
+#### Fields
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="workitemwidgetweighttype"></a>`type` | [`WorkItemWidgetType`](#workitemwidgettype) | Widget type. |
+| <a id="workitemwidgetweightweight"></a>`weight` | [`Int`](#int) | Weight of the work item. |
+
 ## Enumeration types
 
 Also called _Enums_, enumeration types are a special kind of scalar that
@@ -20372,6 +20384,7 @@ Type of a work item widget.
 | <a id="workitemwidgettypeassignees"></a>`ASSIGNEES` | Assignees widget. |
 | <a id="workitemwidgettypedescription"></a>`DESCRIPTION` | Description widget. |
 | <a id="workitemwidgettypehierarchy"></a>`HIERARCHY` | Hierarchy widget. |
+| <a id="workitemwidgettypeweight"></a>`WEIGHT` | Weight widget. |
 
 ## Scalar types
 
@@ -21593,6 +21606,7 @@ Implementations:
 - [`WorkItemWidgetAssignees`](#workitemwidgetassignees)
 - [`WorkItemWidgetDescription`](#workitemwidgetdescription)
 - [`WorkItemWidgetHierarchy`](#workitemwidgethierarchy)
+- [`WorkItemWidgetWeight`](#workitemwidgetweight)
 
 ##### Fields
 
@@ -22082,6 +22096,7 @@ A time-frame defined as a closed inclusive range of two dates.
 | <a id="workitemupdatedtaskinputid"></a>`id` | [`WorkItemID!`](#workitemid) | Global ID of the work item. |
 | <a id="workitemupdatedtaskinputstateevent"></a>`stateEvent` | [`WorkItemStateEvent`](#workitemstateevent) | Close or reopen a work item. |
 | <a id="workitemupdatedtaskinputtitle"></a>`title` | [`String`](#string) | Title of the work item. |
+| <a id="workitemupdatedtaskinputweightwidget"></a>`weightWidget` | [`WorkItemWidgetWeightInput`](#workitemwidgetweightinput) | Input for weight widget. |
 
 ### `WorkItemWidgetDescriptionInput`
 
@@ -22090,3 +22105,11 @@ A time-frame defined as a closed inclusive range of two dates.
 | Name | Type | Description |
 | ---- | ---- | ----------- |
 | <a id="workitemwidgetdescriptioninputdescription"></a>`description` | [`String!`](#string) | Description of the work item. |
+
+### `WorkItemWidgetWeightInput`
+
+#### Arguments
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="workitemwidgetweightinputweight"></a>`weight` | [`Int!`](#int) | Weight of the work item. |
diff --git a/doc/ci/cloud_deployment/ecs/deploy_to_aws_ecs.md b/doc/ci/cloud_deployment/ecs/deploy_to_aws_ecs.md
index 5356ebb84f1..5894efa95ab 100644
--- a/doc/ci/cloud_deployment/ecs/deploy_to_aws_ecs.md
+++ b/doc/ci/cloud_deployment/ecs/deploy_to_aws_ecs.md
@@ -248,9 +248,13 @@ set `CI_AWS_ECS_WAIT_FOR_ROLLOUT_COMPLETE_DISABLED` to a non-empty value.
 
 ## Set up Review Apps
 
-In order to use [Review Apps](../../../development/testing_guide/review_apps.md) with ECS, you should create another
-[service](#create-an-ecs-service) and specify its name using the `CI_AWS_ECS_SERVICE` variable scoped to `review/*`.
-Since this service is shared by all review apps, there is a limitation that only one Review App can be deployed at a time.
+To use [Review Apps](../../../development/testing_guide/review_apps.md) with ECS:
+
+1. Set up a new [service](#create-an-ecs-service).
+1. Use the `CI_AWS_ECS_SERVICE` variable to set the name.
+1. Set the environment scope to `review/*`. 
+
+Only one Review App at a time can be deployed because this service is shared by all review apps.
 
 ## Set up Security Testing
 
@@ -275,6 +279,20 @@ include:
   - template: Security/DAST.gitlab-ci.yml
 ```
 
+To use DAST on the default branch:
+
+1. Set up a new [service](#create-an-ecs-service). This service will be used to deploy a temporary
+DAST environment. 
+1. Use the `CI_AWS_ECS_SERVICE` variable to set the name.
+1. Set the scope to the `dast-default` environment. 
+1. Add the following to your `.gitlab-ci.yml` file:
+
+```yaml
+include:
+  - template: Security/DAST.gitlab-ci.yml
+  - template: Jobs/DAST-Default-Branch-Deploy.gitlab-ci.yml
+```
+
 For more details and configuration options, see the [DAST documentation](../../../user/application_security/dast/index.md).
 
 ## Further reading
diff --git a/doc/development/integrations/secure.md b/doc/development/integrations/secure.md
index 1a51ee88c58..a68c0630b18 100644
--- a/doc/development/integrations/secure.md
+++ b/doc/development/integrations/secure.md
@@ -451,7 +451,7 @@ The `identifiers` array describes the detected vulnerability. An identifier obje
 `value` fields are used to tell if two identifiers are the same. The user interface uses the
 object's `name` and `url` fields to display the identifier.
 
-It is recommended to reuse the identifiers the GitLab scanners already define:
+We recommend that you use the identifiers the GitLab scanners already define:
 
 | Identifier | Type | Example value |
 |------------|------|---------------|
diff --git a/doc/user/application_security/generate_test_vulnerabilities/index.md b/doc/user/application_security/generate_test_vulnerabilities/index.md
new file mode 100644
index 00000000000..aafbebb91cd
--- /dev/null
+++ b/doc/user/application_security/generate_test_vulnerabilities/index.md
@@ -0,0 +1,28 @@
+---
+type: reference, howto
+stage: Secure
+group: Threat Insights
+info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#assignments
+---
+
+# Generate test vulnerabilities
+
+You can generate test vulnerabilities when you work on the [Vulnerability Report](../vulnerability_report/index.md).
+
+1. Go to `/-/profile/personal_access_tokens` and generate a personal access token with `api` permissions.
+1. Go to your project page and find the project ID. You can find the project ID below the project title.
+1. Open a terminal and go to the `gitlab/qa` directory.
+1. Run the following command:
+
+```shell
+GITLAB_QA_ACCESS_TOKEN=<your_personal_access_token> GITLAB_URL="http://localhost:3000" bundle exec rake vulnerabilities:setup\[<your_project_id>,<vulnerability_count>\] --trace
+```
+
+Make sure you do the following:
+
+- Replace `<your_personal_access_token>` with the token you generated in step one.
+- Double check the `GITLAB_URL`. It should point to the running local instance.
+- Replace `<your_project_id>` with the ID you obtained in step two.
+- Replace `<vulnerability_count>` with the number of vulnerabilities you'd like to generate.
+
+The script creates the specified amount of vulnerabilities in the project.