Add latest changes from gitlab-org/gitlab@master

9 files changed, 261 insertions, 126 deletions

diff --git a/doc/api/graphql/reference/index.md b/doc/api/graphql/reference/index.md
index cabf55d96ca..c5a53b458cb 100644
--- a/doc/api/graphql/reference/index.md
+++ b/doc/api/graphql/reference/index.md
@@ -20313,6 +20313,18 @@ Returns [`[String!]`](#string).
 | <a id="repositorybranchnamesoffset"></a>`offset` | [`Int!`](#int) | Number of branch names to skip. |
 | <a id="repositorybranchnamessearchpattern"></a>`searchPattern` | [`String!`](#string) | Pattern to search for branch names by. |
 
+##### `Repository.codeOwnersPath`
+
+Path to CODEOWNERS file in a ref.
+
+Returns [`String`](#string).
+
+###### Arguments
+
+| Name | Type | Description |
+| ---- | ---- | ----------- |
+| <a id="repositorycodeownerspathref"></a>`ref` | [`String`](#string) | Name of the ref. |
+
 ##### `Repository.paginatedTree`
 
 Paginated tree of the repository.
diff --git a/doc/api/index.md b/doc/api/index.md
index 110534ceced..46d7629327e 100644
--- a/doc/api/index.md
+++ b/doc/api/index.md
@@ -10,8 +10,8 @@ Automate and interact with GitLab, and integrate with external applications.
 
 - [Integrations](../integration/index.md)
 - [Webhooks](../user/project/integrations/webhooks.md)
-- [Visual Studio Code extension](../user/project/repository/vscode.md)
 - [REST API](rest/index.md)
 - [GraphQL API](graphql/index.md)
-- [Lint `.gitlab-ci.yml`](lint.md)
-- [GitLab as an OAuth2 provider](oauth2.md)
+- [OAuth 2.0 identity provider API](oauth2.md)
+- [GitLab CLI (glab)](../integration/glab/index.md)
+- [Visual Studio Code extension](../user/project/repository/vscode.md)
diff --git a/doc/development/contributing/index.md b/doc/development/contributing/index.md
index e4768bdb97f..c436be5edd1 100644
--- a/doc/development/contributing/index.md
+++ b/doc/development/contributing/index.md
@@ -43,27 +43,10 @@ If you would like to contribute to GitLab:
   slowest tests. These tests are good candidates for improving and checking if any of
   [best practices](../testing_guide/best_practices.md)
   could speed them up.
-- Consult the [Contribution Flow](#contribution-flow) section to learn the process.
 
-### Contribution flow
+For a walkthrough of the contribution process, see [Tutorial: Make a GitLab contribution](first_contribution.md).
 
-The general flow of contributing to GitLab is:
-
-1. [Read about](https://gitlab.com/gitlab-community/meta) and [request access](https://gitlab.com/gitlab-community/meta#request-access-to-community-forks)
-   to the GitLab Community forks. In some cases, you will want to set up the
-   [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit) to
-   [develop against the GitLab community fork](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/index.md#develop-in-your-own-gitlab-fork).
-1. Create a feature branch and make changes in the [GitLab community fork](https://gitlab.com/gitlab-community/gitlab).
-1. When you're ready, [create a new merge request](../../user/project/merge_requests/creating_merge_requests.md).
-1. In the merge request's description:
-   - Ensure you provide complete and accurate information.
-   - Review the provided checklist.
-1. Once you're ready, mark your MR as ready for review with `@gitlab-bot ready`.
-   - This will add the `~"workflow::ready for review"` label, and then automatically assign a merge request coach as reviewer.
-   - If you know a relevant reviewer (for example, someone that was involved a related issue), you can also
-     assign them directly with `@gitlab-bot ready @username`.
-
-#### Review process
+### Review process
 
 When you submit code to GitLab, we really want it to get merged! However, we always review
 submissions carefully, and this takes time. Code submissions will usually be reviewed by two
@@ -95,7 +78,7 @@ Lastly, keep the following in mind when submitting merge requests:
   be merged, as well as some guidance. The maintainers will be open to discussion about how to change
   the code so it can be approved and merged in the future.
 
-#### Getting attention on your merge request
+### Getting attention on your merge request
 
 GitLab will do its best to review community contributions as quickly as possible. Specially
 appointed developers review community contributions daily. Look at the
@@ -119,7 +102,7 @@ This [documentation](issue_workflow.md) outlines the current issue workflow:
 - [Technical and UX debt](../labels/index.md#technical-and-ux-debt)
 - [Technical debt in follow-up issues](issue_workflow.md#technical-debt-in-follow-up-issues)
 
-#### Merge requests workflow
+### Merge requests workflow
 
 This [documentation](merge_request_workflow.md) outlines the current merge request process.
 
diff --git a/doc/development/contributing/merge_request_workflow.md b/doc/development/contributing/merge_request_workflow.md
index f39d93a39bc..a67459e02ed 100644
--- a/doc/development/contributing/merge_request_workflow.md
+++ b/doc/development/contributing/merge_request_workflow.md
@@ -55,66 +55,25 @@ within the MR.
 
 ## Merge request guidelines for contributors
 
-### Getting started
-
-Merge requests should be submitted to the appropriate project at GitLab.com, for example
-[GitLab](https://gitlab.com/gitlab-org/gitlab/-/merge_requests),
-[GitLab Runner](https://gitlab.com/gitlab-org/gitlab-runner/-/merge_requests), or
-[Omnibus GitLab](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests).
-
-To start developing GitLab locally, download the [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit)
-and see the [Development section](../../index.md) for the required guidelines.
-
-NOTE:
-Consider placing your code behind a feature flag if you think it might affect production availability.
-Not sure? Read [When to use feature flags](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags).
-
-If the change is non-trivial, we encourage you to
-start a discussion with [a product manager or a member of the team](https://about.gitlab.com/handbook/product/categories/).
-You can do
-this by tagging them in an MR before submitting the code for review. Talking
-to team members can be helpful when making design decisions. Communicating the
-intent behind your changes can also help expedite merge request reviews.
-
-### Creating a merge request
-
-To create a merge request:
-
-1. [Read about](https://gitlab.com/gitlab-community/meta) and [request access](https://gitlab.com/gitlab-community/meta#request-access-to-community-forks)
-   to the GitLab Community forks. In some cases, you will want to set up the
-   [GitLab Development Kit](https://gitlab.com/gitlab-org/gitlab-development-kit) to
-   [develop against the GitLab community fork](https://gitlab.com/gitlab-org/gitlab-development-kit/-/blob/main/doc/index.md#develop-in-your-own-gitlab-fork).
-1. Create a feature branch in the [GitLab community fork](https://gitlab.com/gitlab-community/gitlab)
-   (don't work off the [default branch](../../user/project/repository/branches/default.md)).
-1. Follow the [commit messages guidelines](#commit-messages-guidelines).
-1. If you have multiple commits, combine them into a few logically organized commits.
-1. Push the commits to your working branch in the fork.
-1. Submit a merge request (MR) against the default branch of the upstream project.
-1. The MR title should describe the change you want to make.
-1. The MR description should give a reason for your change.
-   1. If you are contributing code, fill in the description according to the default
-      template already provided in the "Description" field.
-   1. If you are contributing documentation, choose `Documentation` from the
-      "Choose a template" menu and fill in the description according to the template.
-   1. Use the syntax `Solves #XXX`, `Closes #XXX`, or `Refs #XXX` to mention the issues your merge
-      request addresses. Referenced issues do not [close automatically](../../user/project/issues/managing_issues.md#closing-issues-automatically).
-      You must close them manually once the merge request is merged.
-1. If you're allowed to, set a relevant milestone and [labels](issue_workflow.md).
-   MR labels should generally match the corresponding issue (if there is one).
-   The group label should reflect the group that executed or coached the work,
-   not necessarily the group that owns the feature.
-1. Read and adhere to
-   [The responsibility of the merge request author](../code_review.md#the-responsibility-of-the-merge-request-author).
-1. Read and follow
-   [Having your merge request reviewed](../code_review.md#having-your-merge-request-reviewed).
-1. Make sure the merge request meets the [Definition of done](#definition-of-done).
-
-If you would like quick feedback on your merge request feel free to mention someone
-from the [core team](https://about.gitlab.com/community/core-team/) or one of the
-[merge request coaches](https://about.gitlab.com/company/team/). When having your code reviewed
-and when reviewing merge requests, please keep the [code review guidelines](../code_review.md)
-in mind. And if your code also makes changes to the database, or does expensive queries,
-check the [database review guidelines](../database_review.md).
+For a walkthrough of the contribution process, see [Tutorial: Make a GitLab contribution](first_contribution.md).
+
+### Best practices
+
+- If the change is non-trivial, we encourage you to start a discussion with
+  [a product manager or a member of the team](https://about.gitlab.com/handbook/product/categories/).
+  You can do this by tagging them in an MR before submitting the code for review. Talking
+  to team members can be helpful when making design decisions. Communicating the
+  intent behind your changes can also help expedite merge request reviews.
+
+- Consider placing your code behind a feature flag if you think it might affect production availability.
+  Not sure? Read [When to use feature flags](https://about.gitlab.com/handbook/product-development-flow/feature-flag-lifecycle/#when-to-use-feature-flags).
+
+- If you would like quick feedback on your merge request feel free to mention someone
+  from the [core team](https://about.gitlab.com/community/core-team/) or one of the
+  [merge request coaches](https://about.gitlab.com/company/team/). When having your code reviewed
+  and when reviewing merge requests, please keep the [code review guidelines](../code_review.md)
+  in mind. And if your code also makes changes to the database, or does expensive queries,
+  check the [database review guidelines](../database_review.md).
 
 ### Keep it simple
 
@@ -381,3 +340,8 @@ issue) that are incremental improvements, such as:
 
 Tag a merge request with ~"Stuff that should Just Work" to track work in
 this area.
+
+## Related topics
+
+- [The responsibility of the merge request author](../code_review.md#the-responsibility-of-the-merge-request-author)
+- [Having your merge request reviewed](../code_review.md#having-your-merge-request-reviewed)
diff --git a/doc/development/index.md b/doc/development/index.md
index f4a4a806d58..b8e67748bc9 100644
--- a/doc/development/index.md
+++ b/doc/development/index.md
@@ -13,8 +13,8 @@ Learn how to contribute to the development of the GitLab product.
 This content is intended for GitLab team members as well as members of the wider community.
 
 - [Contribute to GitLab development](contributing/index.md)
-- [Contribute to Omnibus development](https://docs.gitlab.com/omnibus/development/)
-- [Contribute to GitLab Pages development](pages/index.md)
 - [Contribute to GitLab Runner development](https://docs.gitlab.com/runner/development/)
-- [Contribute to Helm chart development](https://docs.gitlab.com/charts/development/)
+- [Contribute to GitLab Pages development](pages/index.md)
+- [Contribute to GitLab distribution development](distribution/index.md)
+- [Contribute to the GitLab Design System](https://design.gitlab.com/get-started/contributing)
 - [Contribute to the GitLab documentation](documentation/index.md)
diff --git a/doc/user/profile/preferences.md b/doc/user/profile/preferences.md
index 9988b4c2d9f..21597236475 100644
--- a/doc/user/profile/preferences.md
+++ b/doc/user/profile/preferences.md
@@ -187,16 +187,15 @@ Open an issue if you notice that using absolute times breaks a layout.
 
 ## Web IDE
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/370139) in GitLab 15.7 [with a flag](../../administration/feature_flags.md) named `vscode_web_ide`. Disabled by default.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/370139) in GitLab 15.7 [with a flag](../../administration/feature_flags.md) named `vscode_web_ide`. Disabled by default.
+> - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/371084) in GitLab 15.7.
+> - [Enabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/115741) in GitLab 15.11.
 
 FLAG:
-On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../../administration/feature_flags.md) named `vscode_web_ide`. On GitLab.com, this feature is available.
+On self-managed GitLab, by default this feature is available. To hide the feature, ask an administrator to [disable the feature flag](../../administration/feature_flags.md) named `vscode_web_ide`. On GitLab.com, this feature is available.
 
 The [Web IDE Beta](../project/web_ide_beta/index.md) is
-the default editing environment when the `vscode_web_ide` feature
-flag is enabled.
-
-To stop using the Web IDE Beta:
+the default editing environment. To stop using the Web IDE Beta:
 
 1. In the **Web IDE** section, select the **Opt out of the Web IDE Beta** checkbox.
 1. Select **Save changes**.
diff --git a/doc/user/project/code_owners.md b/doc/user/project/code_owners.md
index f90b81b06cb..6e2206d27be 100644
--- a/doc/user/project/code_owners.md
+++ b/doc/user/project/code_owners.md
@@ -58,21 +58,11 @@ GitLab shows the Code Owners at the top of the page.
 ## Set up Code Owners
 
 1. Create a `CODEOWNERS` file in your [preferred location](#code-owners-file).
-1. In the file, enter text that follows one of these patterns:
-
-   ```plaintext
-   # Code Owners for a file
-   filename @username1 @username2
-
-   # Code Owners for a directory
-   directoryname/ @username1 @username2
-
-   # All group members as Code Owners for a file
-   filename @groupname
-
-   # All group members as Code Owners for a directory
-   directoryname/ @groupname
-   ```
+1. Define some rules in the file following the [Code Owners syntax reference](#code-owners-syntax-reference).
+   Some suggestions:
+   - Configure [All eligible approvers](merge_requests/approvals/rules.md#code-owners-as-eligible-approvers) approval rule.
+   - [Require Code Owner approval](protected_branches.md#require-code-owner-approval-on-a-protected-branch) on a protected branch.
+1. Commit your changes, and push them up to GitLab.
 
 ### Code Owners file
 
@@ -88,11 +78,6 @@ all others are ignored:
 1. In the `docs` directory: `./docs/CODEOWNERS`.
 1. In the `.gitlab` directory: `./.gitlab/CODEOWNERS`.
 
-### Make Code Owners eligible approvers or require their approval of MRs
-
-- [Add Code Owners as merge request approvers](merge_requests/approvals/rules.md#code-owners-as-eligible-approvers).
-- Set up [Code Owner approval on a protected branch](protected_branches.md#require-code-owner-approval-on-a-protected-branch).
-
 ### Groups as Code Owners
 
 > Group and subgroup hierarchy support was [introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/32432) in GitLab 13.0.
@@ -429,6 +414,203 @@ data-models/ @data-science-team
 README.md  @docs
 ```
 
+## Code Owners syntax reference
+
+### Comments
+
+Lines beginning with `#` are ignored:
+
+```codeowners
+# This is a comment
+```
+
+### Sections
+
+Sections are groups of entries. A section begins with a section heading in square brackets, followed by the entries.
+
+```codeowners
+[Section name]
+/path/of/protected/file.rb @username
+/path/of/protected/dir/ @group
+```
+
+### Section headings
+
+Section headings must always have a name. They can also be made optional, or require a number of approvals. A list of default owners can be added to the section heading line.
+
+```codeowners
+# Required section
+[Section name]
+
+# Optional section
+^[Section name]
+
+# Section requiring 5 approvals
+[Section name][5]
+
+# Section with @username as default owner
+[Section name] @username
+
+# Section with @group and @subgroup as default owners and requiring 2 approvals
+[Section name][2] @group @subgroup
+```
+
+### Section names
+
+Sections names are defined between square brackets.
+Section names are not case-sensitive. [Sections with duplicate names are combined](#sections-with-duplicate-names).
+
+```codeowners
+[Section name]
+```
+
+### Required sections
+
+Required sections do not include `^` before the [section name](#section-names).
+
+```codeowners
+[Required section]
+```
+
+### Optional sections
+
+Optional sections include a `^` before the [section name](#section-names).
+
+```codeowners
+^[Optional section]
+```
+
+### Sections requiring multiple approvals
+
+Sections requiring multiple approvals include the number of approvals in square brackets after the [section name](#section-names).
+
+```codeowners
+[Section requiring 5 approvals][5]
+```
+
+NOTE:
+Optional sections ignore the number of approvals required.
+
+### Sections with default owners
+
+You can define a default owner for the entries in a section by appending the owners to the [section heading](#section-headings).
+
+```codeowners
+# Section with @username as default owner
+[Section name] @username
+
+# Section with @group and @subgroup as default owners and requiring 2 approvals
+[Section name][2] @group @subgroup
+```
+
+### Code Owner entries
+
+Each Code Owner entry includes a path followed by one or more owners.
+
+```codeowners
+README.md @username1
+```
+
+NOTE:
+If an entry is duplicated in a section, [the last entry is used from each section.](#define-more-specific-owners-for-more-specifically-defined-files-or-directories)
+
+### Relative paths
+
+If a path does not start with a `/`, the path is treated as if it starts with a [globstar](#globstar-paths).
+`README.md` is treated the same way as `/**/README.md`
+
+```codeowners
+# This will match /README.md, /internal/README.md, /app/lib/README.md
+README.md @username
+
+# This will match /internal/README.md, /docs/internal/README.md, /docs/api/internal/README.md
+internal/README.md
+```
+
+### Absolute paths
+
+If a path starts with a `/` it matches the root of the repository.
+
+```codeowners
+# Matches only the file named `README.md` in the root of the repository.
+/README.md
+
+# Matches only the file named `README.md` inside the `/docs` directory.
+/docs/README.md
+```
+
+### Directory paths
+
+If a path ends with `/`, the path matches any file in the directory.
+
+```codeowners
+# This is the same as `/docs/**/*`
+/docs/
+```
+
+### Wildcard paths
+
+Wildcards can be used to match one of more characters of a path.
+
+```codeowners
+# Any markdown files in the docs directory
+/docs/*.md @username
+
+# /docs/index file of any filetype
+# For example: /docs/index.md, /docs/index.html, /docs/index.xml
+/docs/index.* @username
+
+# Any file in the docs directory with 'spec' in the name.
+# For example: /docs/qa_specs.rb, /docs/spec_helpers.rb, /docs/runtime.spec
+/docs/*spec* @username
+
+# README.md files one level deep within the docs directory
+# For example: /docs/api/README.md
+/docs/*/README.md @username
+```
+
+### Globstar paths
+
+Globstars (`**`) can be used to match zero or more directories and subdirectories.
+
+```codeowners
+# This will match /docs/index.md, /docs/api/index.md, /docs/api/graphql/index.md
+/docs/**/index.md
+```
+
+### Entry owners
+
+Entries must be followed by one or more owner, these can be groups, subgroups,
+and users. Order of owners is not important.
+
+```codeowners
+/path/to/entry.rb @group
+/path/to/entry.rb @group/subgroup
+/path/to/entry.rb @user
+/path/to/entry.rb @group @group/subgroup @user
+```
+
+### Groups as entry owners
+
+Groups and subgroups can be owners of an entry.
+Each entry can be owned by [one or more owners](#entry-owners).
+For more details see the [Groups as Code Owners section](#groups-as-code-owners).
+
+```codeowners
+/path/to/entry.rb @group
+/path/to/entry.rb @group/subgroup
+/path/to/entry.rb @group @group/subgroup
+```
+
+### Users as entry owners
+
+Users can be owners of an entry. Each entry can be owned by [one or more owners](#entry-owners).
+
+```codeowners
+/path/to/entry.rb @username1
+/path/to/entry.rb @username1 @username2
+```
+
 ## Technical Resources
 
 [Code Owners development guidelines](../../../ee/development/code_owners/index.md)
diff --git a/doc/user/project/remote_development/index.md b/doc/user/project/remote_development/index.md
index 31c0a8eb51c..11c9d8dc129 100644
--- a/doc/user/project/remote_development/index.md
+++ b/doc/user/project/remote_development/index.md
@@ -6,10 +6,12 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Remote development **(FREE)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/95169) in GitLab 15.4 [with a flag](../../../administration/feature_flags.md) named `vscode_web_ide`. Disabled by default.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/95169) in GitLab 15.4 [with a flag](../../../administration/feature_flags.md) named `vscode_web_ide`. Disabled by default.
+> - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/371084) in GitLab 15.7.
+> - [Enabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/115741) in GitLab 15.11.
 
 FLAG:
-On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../../../administration/feature_flags.md) named `vscode_web_ide`. On GitLab.com, this feature is available. The feature is not ready for production use.
+On self-managed GitLab, by default this feature is available. To hide the feature, ask an administrator to [disable the feature flag](../../../administration/feature_flags.md) named `vscode_web_ide`. On GitLab.com, this feature is available. The feature is not ready for production use.
 
 WARNING:
 This feature is in [Alpha](../../../policy/alpha-beta-support.md#alpha-features) and subject to change without notice.
diff --git a/doc/user/project/web_ide_beta/index.md b/doc/user/project/web_ide_beta/index.md
index 1c0a25d8309..3e045b12282 100644
--- a/doc/user/project/web_ide_beta/index.md
+++ b/doc/user/project/web_ide_beta/index.md
@@ -6,10 +6,12 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Web IDE Beta **(FREE)**
 
-> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/95169) in GitLab 15.7 [with a flag](../../../administration/feature_flags.md) named `vscode_web_ide`. Disabled by default.
+> - [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/95169) in GitLab 15.7 [with a flag](../../../administration/feature_flags.md) named `vscode_web_ide`. Disabled by default.
+> - [Enabled on GitLab.com](https://gitlab.com/gitlab-org/gitlab/-/issues/371084) in GitLab 15.7.
+> - [Enabled on self-managed](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/115741) in GitLab 15.11.
 
 FLAG:
-On self-managed GitLab, by default this feature is not available. To make it available, ask an administrator to [enable the feature flag](../../../administration/feature_flags.md) named `vscode_web_ide`. On GitLab.com, this feature is available. The feature is not ready for production use.
+On self-managed GitLab, by default this feature is available. To hide the feature, ask an administrator to [disable the feature flag](../../../administration/feature_flags.md) named `vscode_web_ide`. On GitLab.com, this feature is available.
 
 As announced in [this blog post](https://about.gitlab.com/blog/2022/05/23/the-future-of-the-gitlab-web-ide/),
 the current implementation of the [Web IDE](../web_ide/index.md) is being replaced
@@ -18,15 +20,6 @@ development. For updates, see [this epic](https://gitlab.com/groups/gitlab-org/-
 
 To pair the Web IDE Beta with a Remote Development environment, see [Remote Development](../remote_development/index.md).
 
-## Enable the Web IDE Beta
-
-To use the Web IDE Beta on a self-managed GitLab instance,
-ensure that the `vscode_web_ide` feature flag
-[is enabled](../../../administration/feature_flags.md).
-
-On GitLab.com, this feature is available by default. However, you can
-[stop using it if you choose](#stop-using-the-web-ide-beta).
-
 ## Use the Web IDE Beta
 
 To open the Web IDE Beta from anywhere in the UI: