Add latest changes from gitlab-org/gitlab@14-3-stable-eev14.3.0-rc42

1 files changed, 4 insertions, 199 deletions

diff --git a/doc/development/documentation/index.md b/doc/development/documentation/index.md
index 59a1b8c7b99..a597ea512c6 100644
--- a/doc/development/documentation/index.md
+++ b/doc/development/documentation/index.md
@@ -131,10 +131,10 @@ The following metadata should be added when a page is moved to another location:
 
 - `redirect_to`: The relative path and filename (with an `.md` extension) of the
   location to which visitors should be redirected for a moved page.
-  [Learn more](#move-or-rename-a-page).
+  [Learn more](redirects.md).
 - `disqus_identifier`: Identifier for Disqus commenting system. Used to keep
   comments with a page that's been moved to a new URL.
-  [Learn more](#redirections-for-pages-with-disqus-comments).
+  [Learn more](redirects.md#redirections-for-pages-with-disqus-comments).
 
 ### Comments metadata
 
@@ -156,133 +156,7 @@ Nanoc layout), which is displayed at the top of the page if defined.
 
 ## Move or rename a page
 
-Moving or renaming a document is the same as changing its location. Be sure to
-assign a technical writer to any merge request that renames or moves a page.
-Technical Writers can help with any questions and can review your change.
-
-When moving or renaming a page, you must redirect browsers to the new page.
-This ensures users find the new page, and have the opportunity to update their
-bookmarks.
-
-There are two types of redirects:
-
-- Redirect codes added into the documentation files themselves, for users who
-  view the docs in `/help` on self-managed instances. For example,
-  [`/help` on GitLab.com](https://gitlab.com/help).
-- [GitLab Pages redirects](../../user/project/pages/redirects.md),
-  for users who view the docs on [`docs.gitlab.com`](https://docs.gitlab.com).
-
-The Technical Writing team manages the [process](https://gitlab.com/gitlab-org/technical-writing/-/blob/main/.gitlab/issue_templates/tw-monthly-tasks.md)
-to regularly update the [`redirects.yaml`](https://gitlab.com/gitlab-org/gitlab-docs/-/blob/main/content/_data/redirects.yaml)
-file.
-
-To add a redirect:
-
-1. In the repository (`gitlab`, `gitlab-runner`, `omnibus-gitlab`, or `charts`),
-   create a new documentation file. Don't delete the old one. The easiest
-   way is to copy it. For example:
-
-   ```shell
-   cp doc/user/search/old_file.md doc/api/new_file.md
-   ```
-
-1. Add the redirect code to the old documentation file by running the
-   following Rake task. The first argument is the path of the old file,
-   and the second argument is the path of the new file:
-
-   - To redirect to a page in the same project, use relative paths and
-     the `.md` extension. Both old and new paths start from the same location.
-     In the following example, both paths are relative to `doc/`:
-
-     ```shell
-     bundle exec rake "gitlab:docs:redirect[doc/user/search/old_file.md, doc/api/new_file.md]"
-     ```
-
-   - To redirect to a page in a different project or site, use the full URL (with `https://`) :
-
-     ```shell
-     bundle exec rake "gitlab:docs:redirect[doc/user/search/old_file.md, https://example.com]"
-     ```
-
-   Alternatively, you can omit the arguments and be asked to enter their values:
-
-   ```shell
-   bundle exec rake gitlab:docs:redirect
-   ```
-
-   If you don't want to use the Rake task, you can use the following template.
-   However, the file paths must be relative to the `doc` or `docs` directory.
-
-   Replace the value of `redirect_to` with the new file path and `YYYY-MM-DD`
-   with the date the file should be removed.
-
-   Redirect files that link to docs in internal documentation projects
-   are removed after three months. Redirect files that link to external sites are
-   removed after one year:
-
-   ```markdown
-   ---
-   redirect_to: '../newpath/to/file/index.md'
-   remove_date: 'YYYY-MM-DD'
-   ---
-
-   This document was moved to [another location](../path/to/file/index.md).
-
-   <!-- This redirect file can be deleted after <YYYY-MM-DD>. -->
-   <!-- Before deletion, see: https://docs.gitlab.com/ee/development/documentation/#move-or-rename-a-page -->
-   ```
-
-1. If the documentation page being moved has any Disqus comments, follow the steps
-   described in [Redirections for pages with Disqus comments](#redirections-for-pages-with-disqus-comments).
-1. Open a merge request with your changes. If a documentation page
-   you're removing includes images that aren't used
-   with any other documentation pages, be sure to use your merge request to delete
-   those images from the repository.
-1. Assign the merge request to a technical writer for review and merge.
-1. Search for links to the old documentation file. You must find and update all
-   links that point to the old documentation file:
-
-   - In <https://gitlab.com/gitlab-com/www-gitlab-com>, search for full URLs:
-     `grep -r "docs.gitlab.com/ee/path/to/file.html" .`
-   - In <https://gitlab.com/gitlab-org/gitlab-docs/-/tree/master/content/_data>,
-     search the navigation bar configuration files for the path with `.html`:
-     `grep -r "path/to/file.html" .`
-   - In any of the four internal projects, search for links in the docs
-     and codebase. Search for all variations, including full URL and just the path.
-     For example, go to the root directory of the `gitlab` project and run:
-
-     ```shell
-     grep -r "docs.gitlab.com/ee/path/to/file.html" .
-     grep -r "path/to/file.html" .
-     grep -r "path/to/file.md" .
-     grep -r "path/to/file" .
-     ```
-
-     You may need to try variations of relative links, such as `../path/to/file` or
-     `../file` to find every case.
-
-### Redirections for pages with Disqus comments
-
-If the documentation page being relocated already has Disqus comments,
-we need to preserve the Disqus thread.
-
-Disqus uses an identifier per page, and for <https://docs.gitlab.com>, the page identifier
-is configured to be the page URL. Therefore, when we change the document location,
-we need to preserve the old URL as the same Disqus identifier.
-
-To do that, add to the front matter the variable `disqus_identifier`,
-using the old URL as value. For example, let's say we moved the document
-available under `https://docs.gitlab.com/my-old-location/README.html` to a new location,
-`https://docs.gitlab.com/my-new-location/index.html`.
-
-Into the **new document** front matter, we add the following information. You must
-include the filename in the `disqus_identifier` URL, even if it's `index.html` or `README.html`.
-
-```yaml
----
-disqus_identifier: 'https://docs.gitlab.com/my-old-location/README.html'
----
-```
+See [redirects](redirects.md).
 
 ## Merge requests for GitLab documentation
 
@@ -405,76 +279,7 @@ on how the left-side navigation menu is built and updated.
 
 ## Previewing the changes live
 
-NOTE:
-To preview your changes to documentation locally, follow this
-[development guide](https://gitlab.com/gitlab-org/gitlab-docs/blob/main/README.md#development-when-contributing-to-gitlab-documentation) or [these instructions for GDK](https://gitlab.com/gitlab-org/gitlab-development-kit/blob/main/doc/howto/gitlab_docs.md).
-
-The live preview is currently enabled for the following projects:
-
-- [`gitlab`](https://gitlab.com/gitlab-org/gitlab)
-- [`omnibus-gitlab`](https://gitlab.com/gitlab-org/omnibus-gitlab)
-- [`gitlab-runner`](https://gitlab.com/gitlab-org/gitlab-runner)
-
-If your merge request has docs changes, you can use the manual `review-docs-deploy` job
-to deploy the docs review app for your merge request.
-
-![Manual trigger a docs build](img/manual_build_docs.png)
-
-You must push a branch to those repositories, as it doesn't work for forks.
-
-The `review-docs-deploy*` job:
-
-1. Triggers a cross project pipeline and build the docs site with your changes.
-
-In case the review app URL returns 404, this means that either the site is not
-yet deployed, or something went wrong with the remote pipeline. Give it a few
-minutes and it should appear online, otherwise you can check the status of the
-remote pipeline from the link in the merge request's job output.
-If the pipeline failed or got stuck, drop a line in the `#docs` chat channel.
-
-NOTE:
-Someone with no merge rights to the GitLab projects (think of forks from
-contributors) cannot run the manual job. In that case, you can
-ask someone from the GitLab team who has the permissions to do that for you.
-
-### Troubleshooting review apps
-
-In case the review app URL returns 404, follow these steps to debug:
-
-1. **Did you follow the URL from the merge request widget?** If yes, then check if
-   the link is the same as the one in the job output.
-1. **Did you follow the URL from the job output?** If yes, then it means that
-   either the site is not yet deployed or something went wrong with the remote
-   pipeline. Give it a few minutes and it should appear online, otherwise you
-   can check the status of the remote pipeline from the link in the job output.
-   If the pipeline failed or got stuck, drop a line in the `#docs` chat channel.
-
-### Technical aspects
-
-If you want to know the in-depth details, here's what's really happening:
-
-1. You manually run the `review-docs-deploy` job in a merge request.
-1. The job runs the [`scripts/trigger-build`](https://gitlab.com/gitlab-org/gitlab/-/blob/master/scripts/trigger-build)
-   script with the `docs deploy` flag, which triggers the "Triggered from `gitlab-org/gitlab` 'review-docs-deploy' job"
-   pipeline trigger in the `gitlab-org/gitlab-docs` project for the `$DOCS_BRANCH` (defaults to `main`).
-1. The preview URL is shown both at the job output and in the merge request
-   widget. You also get the link to the remote pipeline.
-1. In the `gitlab-org/gitlab-docs` project, the pipeline is created and it
-   [skips the test jobs](https://gitlab.com/gitlab-org/gitlab-docs/blob/8d5d5c750c602a835614b02f9db42ead1c4b2f5e/.gitlab-ci.yml#L50-55)
-   to lower the build time.
-1. Once the docs site is built, the HTML files are uploaded as artifacts.
-1. A specific runner tied only to the docs project, runs the Review App job
-   that downloads the artifacts and uses `rsync` to transfer the files over
-   to a location where NGINX serves them.
-
-The following GitLab features are used among others:
-
-- [Manual jobs](../../ci/jobs/job_control.md#create-a-job-that-must-be-run-manually)
-- [Multi project pipelines](../../ci/pipelines/multi_project_pipelines.md)
-- [Review Apps](../../ci/review_apps/index.md)
-- [Artifacts](../../ci/yaml/index.md#artifacts)
-- [Specific runner](../../ci/runners/runners_scope.md#prevent-a-specific-runner-from-being-enabled-for-other-projects)
-- [Pipelines for merge requests](../../ci/pipelines/merge_request_pipelines.md)
+See how you can use review apps to [preview your changes live](review_apps.md).
 
 ## Testing