Add latest changes from gitlab-org/gitlab@master

9 files changed, 126 insertions, 94 deletions

diff --git a/doc/.vale/gitlab/spelling-exceptions.txt b/doc/.vale/gitlab/spelling-exceptions.txt
index de7fb45490d..09fb21f0e30 100644
--- a/doc/.vale/gitlab/spelling-exceptions.txt
+++ b/doc/.vale/gitlab/spelling-exceptions.txt
@@ -125,6 +125,7 @@ colocated
 colocating
 compilable
 composable
+composables
 Conda
 Consul
 Contentful
diff --git a/doc/administration/audit_event_streaming.md b/doc/administration/audit_event_streaming.md
index 18070942813..1e87b3c65bf 100644
--- a/doc/administration/audit_event_streaming.md
+++ b/doc/administration/audit_event_streaming.md
@@ -506,3 +506,52 @@ X-Gitlab-Audit-Event-Type: audit_operation
   "event_type": "audit_operation"
 }
 ```
+
+## Audit event streaming on merge request create actions
+
+> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/90911) in GitLab 15.2.
+
+Stream audit events that relate to merge request create actions using the `/logs` endpoint.
+
+Send API requests that contain the `X-Gitlab-Audit-Event-Type` header with value `merge_request_create`. GitLab responds with JSON payloads with an
+`event_type` field set to `merge_request_create`.
+
+### Headers
+
+Headers are formatted as follows:
+
+```plaintext
+POST /logs HTTP/1.1
+Host: <DESTINATION_HOST>
+Content-Type: application/x-www-form-urlencoded
+X-Gitlab-Audit-Event-Type: merge_request_create
+X-Gitlab-Event-Streaming-Token: <DESTINATION_TOKEN>
+```
+
+### Example payload
+
+```json
+{
+  "id": 1,
+  "author_id": 1,
+  "entity_id": 24,
+  "entity_type": "Project",
+  "details": {
+    "author_name": "example_user",
+    "target_id": 132,
+    "target_type": "MergeRequest",
+    "target_details": "Update test.md",
+    "custom_message": "Added merge request",
+    "ip_address": "127.0.0.1",
+    "entity_path": "example-group/example-project"
+  },
+  "ip_address": "127.0.0.1",
+  "author_name": "Administrator",
+  "entity_path": "example-group/example-project",
+  "target_details": "Update test.md",
+  "created_at": "2022-07-04T00:19:22.675Z",
+  "target_type": "MergeRequest",
+  "target_id": 132,
+  "event_type": "merge_request_create"
+}
+```
diff --git a/doc/administration/troubleshooting/defcon.md b/doc/administration/troubleshooting/defcon.md
index 292b4b13967..f2554f523f0 100644
--- a/doc/administration/troubleshooting/defcon.md
+++ b/doc/administration/troubleshooting/defcon.md
@@ -1,35 +1,11 @@
 ---
-stage: Systems
-group: Distribution
-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: reference
+redirect_to: '../../ci/troubleshooting.md#disaster-recovery'
+remove_date: '2022-10-04'
 ---
 
-# Disaster recovery **(FREE SELF)**
+This document was moved to [another location](../../ci/troubleshooting.md#disaster-recovery).
 
-This document describes a feature that allows you to disable some important but computationally
-expensive parts of the application to relieve stress on the database during an ongoing downtime.
-
-## `ci_queueing_disaster_recovery_disable_fair_scheduling`
-
-This feature flag, if temporarily enabled, disables fair scheduling on shared runners.
-This can help to reduce system resource usage on the `jobs/request` endpoint
-by significantly reducing the computations being performed.
-
-Side effects:
-
-- In case of a large backlog of jobs, the jobs are processed in the order
-  they were put in the system, instead of balancing the jobs across many projects.
-
-## `ci_queueing_disaster_recovery_disable_quota`
-
-This feature flag, if temporarily enabled, disables enforcing CI/CD minutes quota
-on shared runners. This can help to reduce system resource usage on the
-`jobs/request` endpoint by significantly reducing the computations being
-performed.
-
-Side effects:
-
-- Projects which are out of quota will be run. This affects
-  only jobs created during the last hour, as prior jobs are canceled
-  by a periodic background worker (`StuckCiJobsWorker`).
+<!-- This redirect file can be deleted after <2022-10-04>. -->
+<!-- Redirects that point to other docs in the same project expire in three months. -->
+<!-- Redirects that point to docs in a different project or site (for example, link is not relative and starts with `https:`) expire in one year. -->
+<!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/redirects.html -->
diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index 9b13c8303b0..4e62d0bf5d3 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -19245,6 +19245,7 @@ User permission on groups.
 | Value | Description |
 | ----- | ----------- |
 | <a id="grouppermissioncreate_projects"></a>`CREATE_PROJECTS` | Groups where the user can create projects. |
+| <a id="grouppermissiontransfer_projects"></a>`TRANSFER_PROJECTS` | Groups where the user can transfer projects to. |
 
 ### `HealthStatus`
 
diff --git a/doc/ci/pipeline_editor/index.md b/doc/ci/pipeline_editor/index.md
index d87b336224c..4fb2ec94d60 100644
--- a/doc/ci/pipeline_editor/index.md
+++ b/doc/ci/pipeline_editor/index.md
@@ -98,7 +98,7 @@ where:
 - [YAML `!reference` tags](../yaml/yaml_optimization.md#reference-tags) are also replaced
   with the linked configuration.
 
-Using `!refence` tags can cause nested configuration that display with
+Using `!reference` tags can cause nested configuration that display with
 multiple hyphens (`-`) in the expanded view. This behavior is expected, and the extra
 hyphens do not affect the job's execution. For example, this configuration and
 fully expanded version are both valid:
diff --git a/doc/ci/troubleshooting.md b/doc/ci/troubleshooting.md
index 8d8afbffab9..0230aaf7113 100644
--- a/doc/ci/troubleshooting.md
+++ b/doc/ci/troubleshooting.md
@@ -361,6 +361,29 @@ When you visit the job log page for a running job, there could be a delay of up
 60 seconds before the log updates. The default refresh time is 60 seconds, but after
 the log is viewed in the UI, the following log updates should occur every 3 seconds.
 
+## Disaster recovery
+
+You can disable some important but computationally expensive parts of the application
+to relieve stress on the database during ongoing downtime.
+
+### Disable fair scheduling on shared runners
+
+When clearing a large backlog of jobs, you can temporarily enable the `ci_queueing_disaster_recovery_disable_fair_scheduling`
+[feature flag](../administration/feature_flags.md). This flag disables fair scheduling
+on shared runners, which reduces system resource usage on the `jobs/request` endpoint.
+
+When enabled, jobs are processed in the order they were put in the system, instead of
+balanced across many projects.
+
+### Disable CI/CD minutes quota enforcement
+
+To disable the enforcement of CI/CD minutes quotas on shared runners, you can temporarily
+enable the `ci_queueing_disaster_recovery_disable_quota` [feature flag](../administration/feature_flags.md).
+This flag reduces system resource usage on the `jobs/request` endpoint.
+
+When enabled, jobs created in the last hour can run in projects which are out of quota.
+Earlier jobs are already canceled by a periodic background worker (`StuckCiJobsWorker`).
+
 ## How to get help
 
 If you are unable to resolve pipeline issues, you can get help from:
diff --git a/doc/development/documentation/styleguide/index.md b/doc/development/documentation/styleguide/index.md
index 700d64c30d1..219b393afc4 100644
--- a/doc/development/documentation/styleguide/index.md
+++ b/doc/development/documentation/styleguide/index.md
@@ -1096,14 +1096,15 @@ copy of `https://gitlab.com/gitlab-org/gitlab`, run in a terminal:
 
 ### Animated images
 
-Sometimes an image with animation (such as an animated GIF)
-can help the reader understand a complicated interaction with the user interface.
+Avoid using animated images (such as animated GIFs). They can be distracting
+and annoying for users.
 
-However, you should use them sparingly and avoid them when you can.
-Do not use them to replace written descriptions of processes or the product.
+If you're describing a complicated interaction in the user interface and want to
+include a visual representation to help readers understand it, you can:
 
-If you include an animated image, follow the same size and naming conventions we use for images. If the animated image loops, add at least a three
-second pause to the end of the loop.
+- Use a static image (screenshot) and if necessary, add callouts to emphasize an
+  an area of the screen.
+- Create a short video of the interaction and link to it.
 
 ## Videos
 
diff --git a/doc/development/fe_guide/vue.md b/doc/development/fe_guide/vue.md
index 4372e9203a1..7943ae119be 100644
--- a/doc/development/fe_guide/vue.md
+++ b/doc/development/fe_guide/vue.md
@@ -19,8 +19,8 @@ What is described in the following sections can be found in these examples:
 ## Vue architecture
 
 All new features built with Vue.js must follow a [Flux architecture](https://facebook.github.io/flux/).
-The main goal we are trying to achieve is to have only one data flow and only one data entry.
-In order to achieve this goal we use [Vuex](#vuex).
+The main goal we are trying to achieve is to have only one data flow, and only one data entry.
+To achieve this goal we use [Vuex](#vuex).
 
 You can also read about this architecture in Vue documentation about
 [state management](https://vuejs.org/v2/guide/state-management.html#Simple-State-Management-from-Scratch)
@@ -48,8 +48,8 @@ Let's look into each of them:
 
 ### An `index.js` file
 
-This is the index file of your new feature. This is where the root Vue instance
-of the new feature should be.
+This file is the index file of your new feature. The root Vue instance
+of the new feature should be here.
 
 The Store and the Service should be imported and initialized in this file and
 provided as a prop to the main component.
@@ -62,17 +62,16 @@ Be sure to read about [page-specific JavaScript](performance.md#page-specific-ja
 
 While mounting a Vue application, you might need to provide data from Rails to JavaScript.
 To do that, you can use the `data` attributes in the HTML element and query them while mounting the application.
-
 You should only do this while initializing the application, because the mounted element is replaced
 with a Vue-generated DOM.
 
 The advantage of providing data from the DOM to the Vue instance through `props` or
 `provide` in the `render` function, instead of querying the DOM inside the main Vue
-component, is that you avoid the need to create a fixture or an HTML element in the unit test.
+component, is that you avoid creating a fixture or an HTML element in the unit test.
 
-##### provide/inject
+##### `provide` and `inject`
 
-Vue supports dependency injection through [provide/inject](https://vuejs.org/v2/api/#provide-inject).
+Vue supports dependency injection through [`provide` and `inject`](https://vuejs.org/v2/api/#provide-inject).
 In the component the `inject` configuration accesses the values `provide` passes down.
 This example of a Vue app initialization shows how the `provide` configuration passes a value from HAML to the component:
 
@@ -119,13 +118,16 @@ Using dependency injection to provide values from HAML is ideal when:
 
 - The injected value doesn't need an explicit validation against its data type or contents.
 - The value doesn't need to be reactive.
-- There are multiple components in the hierarchy that need access to this value where
+- Multiple components exist in the hierarchy that need access to this value where
   prop-drilling becomes an inconvenience. Prop-drilling when the same prop is passed
   through all components in the hierarchy until the component that is genuinely using it.
 
-Dependency injection can potentially break a child component (either an immediate child or multiple levels deep) if the value declared in the `inject` configuration doesn't have defaults defined and the parent component has not provided the value using the `provide` configuration.
+Dependency injection can potentially break a child component (either an immediate child or multiple levels deep) if both conditions are true:
+
+- The value declared in the `inject` configuration doesn't have defaults defined.
+- The parent component has not provided the value using the `provide` configuration.
 
-- A [default value](https://vuejs.org/guide/components/provide-inject.html#injection-default-values) might be useful in contexts where it makes sense.
+A [default value](https://vuejs.org/guide/components/provide-inject.html#injection-default-values) might be useful in contexts where it makes sense.
 
 ##### props
 
@@ -155,7 +157,8 @@ return new Vue({
 });
 ```
 
-> When adding an `id` attribute to mount a Vue application, please make sure this `id` is unique
+NOTE:
+When adding an `id` attribute to mount a Vue application, make sure this `id` is unique
 across the codebase.
 
 For more information on why we explicitly declare the data being passed into the Vue app,
@@ -165,9 +168,9 @@ refer to our [Vue style guide](style/vue.md#basic-rules).
 
 When composing a form with Rails, the `name`, `id`, and `value` attributes of form inputs are generated
 to match the backend. It can be helpful to have access to these generated attributes when converting
-a Rails form to Vue, or when [integrating components (datepicker, project selector, etc)](https://gitlab.com/gitlab-org/gitlab/-/blob/8956ad767d522f37a96e03840595c767de030968/app/assets/javascripts/access_tokens/index.js#L15) into it.
+a Rails form to Vue, or when [integrating components](https://gitlab.com/gitlab-org/gitlab/-/blob/8956ad767d522f37a96e03840595c767de030968/app/assets/javascripts/access_tokens/index.js#L15) (such as a date picker or project selector) into it.
 The [`parseRailsFormFields`](https://gitlab.com/gitlab-org/gitlab/-/blob/fe88797f682c7ff0b13f2c2223a3ff45ada751c1/app/assets/javascripts/lib/utils/forms.js#L107) utility can be used to parse the generated form input attributes so they can be passed to the Vue application.
-This allows us to easily integrate Vue components without changing how the form submits.
+This enables us to integrate Vue components without changing how the form submits.
 
 ```haml
 -# form.html.haml
@@ -245,7 +248,7 @@ export default {
 
 We query the `gl` object for data that doesn't change during the application's life
 cycle in the same place we query the DOM. By following this practice, we can
-avoid the need to mock the `gl` object, which makes tests easier. It should be done while
+avoid mocking the `gl` object, which makes tests easier. It should be done while
 initializing our Vue instance, and the data should be provided as `props` to the main component:
 
 ```javascript
@@ -263,8 +266,8 @@ return new Vue({
 
 #### Accessing feature flags
 
-Use Vue's [provide/inject](https://vuejs.org/v2/api/#provide-inject) mechanism
-to make feature flags available to any descendant components in a Vue
+Use the [`provide` and `inject`](https://vuejs.org/v2/api/#provide-inject) mechanisms
+in Vue to make feature flags available to any descendant components in a Vue
 application. The `glFeatures` object is already provided in `commons/vue.js`, so
 only the mixin is required to use the flags:
 
@@ -303,14 +306,14 @@ This approach has a few benefits:
   });
   ```
 
-- No need to access a global variable, except in the application's
+- Accessing a global variable is not required, except in the application's
   [entry point](#accessing-the-gl-object).
 
 ### A folder for Components
 
 This folder holds all components that are specific to this new feature.
-If you need to use or create a component that is likely to be used somewhere
-else, please refer to `vue_shared/components`.
+To use or create a component that is likely to be used somewhere
+else, refer to `vue_shared/components`.
 
 A good guideline to know when you should create a component is to think if
 it could be reusable elsewhere.
@@ -330,7 +333,7 @@ Check this [page](vuex.md) for more details.
 ### Mixing Vue and jQuery
 
 - Mixing Vue and jQuery is not recommended.
-- If you need to use a specific jQuery plugin in Vue, [create a wrapper around it](https://vuejs.org/v2/examples/select2.html).
+- To use a specific jQuery plugin in Vue, [create a wrapper around it](https://vuejs.org/v2/examples/select2.html).
 - It is acceptable for Vue to listen to existing jQuery events using jQuery event listeners.
 - It is not recommended to add new jQuery events for Vue to interact with jQuery.
 
@@ -356,17 +359,17 @@ cannot use primitives or objects.
 
 #### Why
 
-There are additional reasons why having a JavaScript class presents maintainability issues on a huge codebase:
+Additional reasons why having a JavaScript class presents maintainability issues on a huge codebase:
 
 - After a class is created, it can be extended in a way that can infringe Vue reactivity and best practices.
 - A class adds a layer of abstraction, which makes the component API and its inner workings less clear.
 - It makes it harder to test. Because the class is instantiated by the component data function, it is
 harder to 'manage' component and class separately.
-- Adding Object Oriented Principles (OOP) to a functional codebase adds yet another way of writing code, reducing consistency and clarity.
+- Adding Object Oriented Principles (OOP) to a functional codebase adds another way of writing code, reducing consistency and clarity.
 
 ## Style guide
 
-Please refer to the Vue section of our [style guide](style/vue.md)
+Refer to the Vue section of our [style guide](style/vue.md)
 for best practices while writing and testing your Vue components and templates.
 
 ## Composition API
@@ -437,11 +440,11 @@ Common naming convention in Vue for composables is to prefix them with `use` and
 
 #### Avoid lifecycle pitfalls
 
-When building a composable, we should aim to keep it as simple as possible. Lifecycle hooks add complexity to composables and might lead to unexpected side effects. In order to avoid that we should follow these principles:
+When building a composable, we should aim to keep it as simple as possible. Lifecycle hooks add complexity to composables and might lead to unexpected side effects. To avoid that we should follow these principles:
 
-- minimize lifecycle hooks usage whenever possible, prefer accepting/returning callbacks instead;
-- if you need to have lifecycle hooks in the composable, make sure this composable also performs a cleanup: if we are adding a listener on `onMounted`, we should remove it on `onUnmounted` within the same composable;
-- always set up lifecycle hooks immediately:
+- Minimize lifecycle hooks usage whenever possible, prefer accepting/returning callbacks instead.
+- If your composable needs lifecycle hooks, make sure it also performs a cleanup. If we add a listener on `onMounted`, we should remove it on `onUnmounted` within the same composable.
+- Always set up lifecycle hooks immediately:
 
 ```javascript
 // bad
@@ -473,7 +476,7 @@ const useAsyncLogic = () => {
 
 #### Avoid escape hatches
 
-It might be tempting to write a composable that does everything as a black box with a help of some of the escape hatches that Vue provides. But for most of the cases this makes them too complex and hard to maintain. One of these escape hatches is `getCurrentInstance` method which returns an instance of a current rendering component. Instead of using that method you should prefer passing down the data or methods to a composable via arguments.
+It might be tempting to write a composable that does everything as a black box, using some of the escape hatches that Vue provides. But for most of the cases this makes them too complex and hard to maintain. One escape hatch is the `getCurrentInstance` method. This method returns an instance of a current rendering component. Instead of using that method, you should prefer passing down the data or methods to a composable via arguments.
 
 ```javascript
 const useSomeLogic = () => {
@@ -493,7 +496,7 @@ const useSomeLogic = (done) => {
 
 #### Composables and Vuex
 
-We should always prefer to avoid using Vuex state in composables. In case it's not possible we should use props to receive that state and emit events from the `setup` to update the Vuex state. A parent component should be responsible to get that state from Vuex and mutate it on events emitted from a child. You should **never mutate a state that's coming down from a prop**. If a composable needs to mutate a Vuex state it should use a callback to emit an event.
+We should always prefer to avoid using Vuex state in composables. In case it's not possible, we should use props to receive that state, and emit events from the `setup` to update the Vuex state. A parent component should be responsible to get that state from Vuex, and mutate it on events emitted from a child. You should **never mutate a state that's coming down from a prop**. If a composable must mutate a Vuex state, it should use a callback to emit an event.
 
 ```javascript
 const useAsyncComposable = ({ state, update }) => {
@@ -520,7 +523,7 @@ const ComponentWithComposable = {
 
 ## Testing Vue Components
 
-Please refer to the [Vue testing style guide](style/vue.md#vue-testing)
+Refer to the [Vue testing style guide](style/vue.md#vue-testing)
 for guidelines and best practices for testing your Vue components.
 
 Each Vue component has a unique output. This output is always present in the render function.
@@ -649,8 +652,8 @@ component under test, with the `computed` property, for example). Remember to us
 
 ### Events
 
-We should test for events emitted in response to an action in our component. This is used to
-verify the correct events are being fired with the correct arguments.
+We should test for events emitted in response to an action in our component. This testing
+verifies the correct events are being fired with the correct arguments.
 
 For any DOM events we should use [`trigger`](https://v1.test-utils.vuejs.org/api/wrapper/#trigger)
 to fire out event.
@@ -668,8 +671,7 @@ it('should fire the click event', () => {
 })
 ```
 
-When we need to fire a Vue event, we should use [`emit`](https://vuejs.org/v2/guide/components-custom-events.html)
-to fire our event.
+When firing a Vue event, use [`emit`](https://vuejs.org/v2/guide/components-custom-events.html).
 
 ```javascript
 wrapper = shallowMount(DropdownItem);
diff --git a/doc/user/clusters/agent/troubleshooting.md b/doc/user/clusters/agent/troubleshooting.md
index 14c09656bfa..0596755ec74 100644
--- a/doc/user/clusters/agent/troubleshooting.md
+++ b/doc/user/clusters/agent/troubleshooting.md
@@ -187,27 +187,6 @@ Alternatively, you can mount the certificate file at a different location and sp
 This error occurs when the project where you keep your manifests is not public. To fix it, make sure your project is public or your manifest files
 are stored in the repository where the agent is configured.
 
-## Failed to perform vulnerability scan on workload: Service account not found
-
-```json
-{
-  "level": "error",
-  "time": "2022-06-17T15:15:02.665Z",
-  "msg": "Failed to perform vulnerability scan on workload",
-  "mod_name": "starboard_vulnerability",
-  "error": "getting service account by name: gitlab-agent/gitlab-agent: serviceaccounts \"gitlab-agent\" not found"
-}
-```
-
-The GitLab agent for Kubernetes has been able to run [vulnerability scans](vulnerabilities.md) since GitLab 15.0. However, the agent
-cannot detect the service account name. Refer to [issue 361972](https://gitlab.com/gitlab-org/gitlab/-/issues/361972) for more
-information. As a workaround you can pass the `--set serviceAccount.name=gitlab-agent` parameter
-to the Helm command when [installing the agent](install/#install-the-agent-in-the-cluster), or manually create a service account.
-
-```shell
-kubectl create serviceaccount gitlab-agent -n gitlab-agent
-```
-
 ## Failed to perform vulnerability scan on workload: jobs.batch already exists
 
 ```json