Add latest changes from gitlab-org/gitlab@master

9 files changed, 88 insertions, 49 deletions

diff --git a/doc/development/README.md b/doc/development/README.md
index 3d5335feb11..c25782dbf84 100644
--- a/doc/development/README.md
+++ b/doc/development/README.md
@@ -287,6 +287,7 @@ See [database guidelines](database/index.md).
 ## Domain-specific guides
 
 - [CI/CD development documentation](cicd/index.md)
+- [AppSec development documentation](appsec/index.md)
 
 ## Other Development guides
 
diff --git a/doc/development/appsec/index.md b/doc/development/appsec/index.md
new file mode 100644
index 00000000000..e8ce885e75d
--- /dev/null
+++ b/doc/development/appsec/index.md
@@ -0,0 +1,32 @@
+---
+stage: Secure, Protect
+group: all
+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
+type: index, dev, reference
+---
+
+# Application Security development documentation
+
+Development guides that are specific to the stages that work on Application Security features are listed here.
+
+Please go to [Application Security](../../user/application_security/index.md) if you are looking for documentation on how to use those features.
+
+## Namespaces
+
+Application Security code in the Rails monolith is organized into the following namespaces, which generally follows
+the feature categories in the [Secure](https://about.gitlab.com/stages-devops-lifecycle/secure/) and [Protect](https://about.gitlab.com/stages-devops-lifecycle/protect/) stages.
+
+- `AppSec`: shared code.
+  - `AppSec::ContainerScanning`: Container Scanning code.
+  - `AppSec::Dast`: DAST code.
+  - `AppSec::DependencyScanning`: Dependency Scanning code.
+  - `AppSec::Fuzzing::Api`: API Fuzzing code.
+  - `AppSec::Fuzzing::Coverage`: Coverage Fuzzing code.
+  - `AppSec::Fuzzing`: Shared fuzzing code.
+  - `AppSec::LicenseCompliance`: License Compliance code.
+  - `AppSec::Sast`: SAST code.
+  - `AppSec::SecretDetection`: Secret Detection code.
+  - `AppSec::VulnMgmt`: Vulnerability Management code.
+
+Most AppSec code does not conform to these namespace guidelines. When developing, make an effort
+to move existing code into the appropriate namespace whenever possible.
diff --git a/doc/development/database/index.md b/doc/development/database/index.md
index 367ef455898..870ae1542bd 100644
--- a/doc/development/database/index.md
+++ b/doc/development/database/index.md
@@ -69,3 +69,4 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 ## Miscellaneous
 
 - [Maintenance operations](maintenance_operations.md)
+- [Update multiple database objects](setting_multiple_values.md)
diff --git a/doc/development/database/setting_multiple_values.md b/doc/development/database/setting_multiple_values.md
index 54870380047..0f23aae9f79 100644
--- a/doc/development/database/setting_multiple_values.md
+++ b/doc/development/database/setting_multiple_values.md
@@ -4,24 +4,22 @@ group: Database
 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
 ---
 
-# Setting Multiple Values
+# Update multiple database objects
 
 > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32921) in GitLab 13.5.
 
-There's often a need to update multiple objects with new values for one
-or more columns. One method of doing this is using `Relation#update_all`:
+You can update multiple database objects with new values for one or more columns.
+One method is to use `Relation#update_all`:
 
 ```ruby
 user.issues.open.update_all(due_date: 7.days.from_now) # (1)
 user.issues.update_all('relative_position = relative_position + 1') # (2)
 ```
 
-But what do you do if you cannot express the update as either a static value (1)
-or as a calculation (2)?
-
-Thankfully we can use `UPDATE FROM` to express the need to update multiple rows
-with distinct values in a single query. One can either use a temporary table, or
-a Common Table Expression (CTE), and then use that as the source of the updates:
+If you cannot express the update as either a static value (1) or as a calculation (2),
+use `UPDATE FROM` to express the need to update multiple rows with distinct values
+in a single query. Create a temporary table, or a Common Table Expression (CTE),
+and use it as the source of the updates:
 
 ```sql
 with updates(obj_id, new_title, new_weight) as (
@@ -34,23 +32,22 @@ update issues
   where id = obj_id
 ```
 
-The bad news: there is no way to express this in ActiveRecord or even dropping
-down to ARel. The `UpdateManager` does not support `update from`, so this
-is not expressible.
-
-The good news: we supply an abstraction to help you generate these kinds of
-updates, called `Gitlab::Database::BulkUpdate`. This constructs queries such as the
-above, and uses binding parameters to avoid SQL injection.
+You can't express this in ActiveRecord, or by dropping down to [Arel](https://api.rubyonrails.org/v6.1.0/classes/Arel.html),
+because the `UpdateManager` does not support `update from`. However, we supply
+an abstraction to help you generate these kinds of updates: `Gitlab::Database::BulkUpdate`.
+This abstraction constructs queries like the previous example, and uses
+binding parameters to avoid SQL injection.
 
 ## Usage
 
-To use this, we need:
+To use `Gitlab::Database::BulkUpdate`, we need:
 
-- the list of columns to update
-- a mapping from object/ID to the new values to set for that object
-- a way to determine the table for each object
+- The list of columns to update.
+- A mapping from the object (or ID) to the new values to set for that object.
+- A way to determine the table for each object.
 
-For example, we can express the query above as:
+For example, we can express the example query in a way that determines the
+table by calling `object.class.table_name`:
 
 ```ruby
 issue_a = Issue.find(..)
@@ -63,10 +60,7 @@ issue_b = Issue.find(..)
 })
 ```
 
-Here the table can be determined automatically, from calling
-`object.class.table_name`, so we don't need to provide anything.
-
-We can even pass heterogeneous sets of objects, if the updates all make sense
+You can even pass heterogeneous sets of objects, if the updates all make sense
 for them:
 
 ```ruby
@@ -82,8 +76,8 @@ merge_request = MergeRequest.find(..)
 })
 ```
 
-If your objects do not return the correct model class (perhaps because they are
-part of a union), then we need to specify this explicitly in a block:
+If your objects do not return the correct model class, such as if they are part
+of a union, then specify the model class explicitly in a block:
 
 ```ruby
 bazzes = params
@@ -103,7 +97,10 @@ end
 
 ## Caveats
 
-Note that this is a **very low level** tool, and operates on the raw column
-values. Enumerations and state fields must be translated into their underlying
-representations, for example, and nested associations are not supported. No
-validations or hooks are called.
+This tool is **very low level**, and operates directly on the raw column
+values. You should consider these issues if you implement it:
+
+- Enumerations and state fields must be translated into their underlying
+  representations.
+- Nested associations are not supported.
+- No validations or hooks are called.
diff --git a/doc/development/fe_guide/vuex.md b/doc/development/fe_guide/vuex.md
index cc1d9ccab77..d44ab64ae5d 100644
--- a/doc/development/fe_guide/vuex.md
+++ b/doc/development/fe_guide/vuex.md
@@ -440,12 +440,11 @@ components, we need to include the store and provide the correct state:
 //component_spec.js
 import Vue from 'vue';
 import Vuex from 'vuex';
-import { mount, createLocalVue } from '@vue/test-utils';
+import { mount } from '@vue/test-utils';
 import { createStore } from './store';
 import Component from './component.vue'
 
-const localVue = createLocalVue();
-localVue.use(Vuex);
+Vue.use(Vuex);
 
 describe('component', () => {
   let store;
@@ -455,7 +454,6 @@ describe('component', () => {
     store = createStore();
 
     wrapper = mount(Component, {
-      localVue,
       store,
     });
   };
@@ -483,6 +481,11 @@ describe('component', () => {
 });
 ```
 
+Some test files may still use the
+[deprecated `createLocalVue` function](https://gitlab.com/gitlab-org/gitlab/-/issues/220482)
+from `@vue/test-utils` and `localVue.use(Vuex)`. This is unnecessary, and should be
+avoided or removed when possible.
+
 ### Two way data binding
 
 When storing form data in Vuex, it is sometimes necessary to update the value stored. The store
diff --git a/doc/development/migration_style_guide.md b/doc/development/migration_style_guide.md
index e1205346585..759b19db36f 100644
--- a/doc/development/migration_style_guide.md
+++ b/doc/development/migration_style_guide.md
@@ -605,9 +605,10 @@ When adding a foreign-key constraint to an existing column in a non-empty table,
 we have to employ `add_concurrent_foreign_key` and `add_concurrent_index`
 instead of `add_reference`.
 
-For an empty table (such as a fresh one), it is recommended to use
-`add_reference` in a single-transaction migration, combining it with other
-operations that don't require `disable_ddl_transaction!`.
+If you have a new or empty table that doesn't reference a
+[high-traffic table](https://gitlab.com/gitlab-org/gitlab/-/blob/master/rubocop/rubocop-migrations.yml#L3),
+we recommend that you use `add_reference` in a single-transaction migration. You can
+combine it with other operations that don't require `disable_ddl_transaction!`.
 
 You can read more about adding [foreign key constraints to an existing column](database/add_foreign_key_to_existing_column.md).
 
diff --git a/doc/user/project/merge_requests/img/comment-on-any-diff-line.png b/doc/user/project/merge_requests/img/comment-on-any-diff-line.png
deleted file mode 100644
index cff5acb98ef..00000000000
--- a/doc/user/project/merge_requests/img/comment-on-any-diff-line.png
+++ /dev/null
diff --git a/doc/user/project/merge_requests/img/comment-on-any-diff-line_v13_10.png b/doc/user/project/merge_requests/img/comment-on-any-diff-line_v13_10.png
new file mode 100644
index 00000000000..a31fea85be9
--- /dev/null
+++ b/doc/user/project/merge_requests/img/comment-on-any-diff-line_v13_10.png
diff --git a/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md b/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md
index d7f7c3da000..406a79217d0 100644
--- a/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md
+++ b/doc/user/project/merge_requests/reviewing_and_managing_merge_requests.md
@@ -187,27 +187,31 @@ Feature.disable(:local_file_reviews)
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/issues/13950) in GitLab 11.5.
 
 In a merge request, you can leave comments in any part of the file being changed.
-In the Merge Request Diff UI, click the **{comment}** **comment** icon in the gutter
-to expand the diff lines and leave a comment, just as you would for a changed line.
+In the Merge Request Diff UI, you can:
 
-![Comment on any diff file line](img/comment-on-any-diff-line.png)
+- **Comment on a single line**: Click the **{comment}** **comment** icon in the
+  gutter to expand the diff lines and display a comment box.
+- [**Comment on multiple lines**](#commenting-on-multiple-lines).
 
 ### Commenting on multiple lines
 
 > - [Introduced](https://gitlab.com/gitlab-org/ux-research/-/issues/870) in GitLab 13.2.
+> - [Added](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/49875) click-and-drag features in GitLab 13.8.
 > - [Feature flag removed](https://gitlab.com/gitlab-org/gitlab/-/issues/299121) in GitLab 13.9.
 
-GitLab provides a way to select which lines of code a comment refers to. After starting a comment
-a dropdown selector is shown to select the first line that this comment refers to.
-The last line is the line that the comment icon was initially clicked on.
+When commenting on a diff, you can select which lines of code your comment refers
+to by either:
 
-New comments default to single line comments by having the first and last lines
-the same. Selecting a different starting line turns this into a multiline comment.
+![Comment on any diff file line](img/comment-on-any-diff-line_v13_10.png)
 
-![Multiline comment selection highlighted](img/multiline-comment-highlighted.png)
+- Clicking and dragging the **{comment}** **comment** icon in the gutter to highlight
+  lines in the diff. GitLab expands the diff lines and displays a comment box.
+- After starting a comment by clicking the **{comment}** **comment** icon in the
+  gutter, select the first line number your comment refers to in the **Commenting on lines**
+  select box. New comments default to single-line comments, unless you select
+  a different starting line.
 
-Once a multiline comment is saved the lines of code pertaining to that comment are listed directly
-above it.
+Multiline comments display the comment's line numbers above the body of the comment:
 
 ![Multiline comment selection displayed above comment](img/multiline-comment-saved.png)