Add latest changes from gitlab-org/gitlab@master

doc/.vale/gitlab/spelling-exceptions.txt

@@ -191,6 +191,7 @@ http
 https
 idempotence
 idmapper
+inclusivity
 Ingress
 initializer
 initializers

doc/user/application_security/dast/index.md

@@ -460,9 +460,9 @@ DAST can be [configured](#customizing-the-dast-settings) using environment varia
 | `DAST_REQUEST_HEADERS` | string | Set to a comma-separated list of request header names and values. Headers will be added to every request made by DAST. For example, `Cache-control: no-cache,User-Agent: DAST/1.0` |
 | `DAST_DEBUG` | boolean | Enable debug message output. Default: `false` |
 | `DAST_SPIDER_MINS` | number | The maximum duration of the spider scan in minutes. Set to `0` for unlimited. Default: One minute, or unlimited when the scan is a full scan. |
-| `DAST_HTML_REPORT` | string | The file name of the HTML report written at the end of a scan. |
-| `DAST_MARKDOWN_REPORT` | string | The file name of the Markdown report written at the end of a scan. |
-| `DAST_XML_REPORT` | string | The file name of the XML report written at the end of a scan. |
+| `DAST_HTML_REPORT` | string | The filename of the HTML report written at the end of a scan. |
+| `DAST_MARKDOWN_REPORT` | string | The filename of the Markdown report written at the end of a scan. |
+| `DAST_XML_REPORT` | string | The filename of the XML report written at the end of a scan. |
 | `DAST_INCLUDE_ALPHA_VULNERABILITIES` | boolean | Set to `true` to include alpha passive and active scan rules. Default: `false` |
 | `DAST_USE_AJAX_SPIDER` | boolean | Set to `true` to use the AJAX spider in addition to the traditional spider, useful for crawling sites that require JavaScript. Default: `false` |
 | `DAST_ZAP_CLI_OPTIONS` | string | ZAP server command-line options. For example, `-Xmx3072m` would set the Java maximum memory allocation pool size. |

doc/user/project/releases/index.md

@@ -53,25 +53,26 @@ Read more about [Release permissions](../../../user/permissions.md#project-membe
 
 You can create a release in the user interface, or by using the
 [Releases API](../../../api/releases/index.md#create-a-release).
-We recommend using the API to add release notes as one of the last steps in your CI/CD release pipeline.
+We recommend using the API to create releases as one of the last steps in your
+CI/CD pipeline.
 
 To create a new release through the GitLab UI:
 
-1. Navigate to **Project overview > Releases** and click the **New release** button.
+1. Navigate to **Project overview > Releases** and click the **New release**
+   button.
 1. In the [**Tag name**](#tag-name) box, enter a name.
-1. In the **Create from** list, select the branch or enter a tag or commit SHA.
-1. In the **Message** box, enter a message associated with the tag.
-1. Optionally, in the [**Release notes**](#release-notes-description)
-   field, enter the release's description. You can use Markdown and drag and drop files to this field.
-   - If you leave this field empty, only a tag will be created.
-   - If you populate it, both a tag and a release will be created.
-1. Click **Create tag**.
 
-If you created a release, you can view it at **Project overview > Releases**.
-If you created a tag, you can view it at **Repository > Tags**.
+   NOTE: **Note:**
+   Creating a release based on an existing tag using the user
+   interface is not yet supported. However, this is possible using the
+   [Releases API](../../../api/releases/index.md#create-a-release).
 
-You can now edit the release to [add milestones](#associate-milestones-with-a-release)
-and [release assets](#release-assets).
+1. In the **Create from** list, select a branch, tag, or commit SHA to use when
+   creating the new tag.
+1. Optionally, fill out any additional information about the release, such as its
+   [title](#title), [milestones](#associate-milestones-with-a-release),
+   [release notes](#release-notes-description), or [assets links](#links).
+1. Click **Create release**.
 
 ### Schedule a future release
 
@@ -218,6 +219,21 @@ For more information, see [Deployment safety](../../../ci/environments/deploymen
 
 The following fields are available when you create or edit a release.
 
+### Title
+
+The release title can be customized using the **Release title** field when
+creating or editing a release. If no title is provided, the release's tag name
+will be used instead.
+
+NOTE: **Note:**
+Guest users of private projects are allowed to view the **Releases** page
+but are _not_ allowed to view details about the Git repository (in particular,
+tag names). Because of this, release titles will be replaced with a generic
+title like "Release-1234" for Guest users to avoid leaking tag name information.
+
+See the [Permissions](../../permissions.md#project-members-permissions) page for
+more information about permissions.
+
 ### Tag name
 
 The release tag name should include the release version. GitLab uses [Semantic Versioning](https://semver.org/)