Remove shared files documentation

doc/administration/raketasks/project_import_export.md

@@ -53,5 +53,5 @@ Note the following:
 - The project import option must be enabled in
   application settings (`/admin/application_settings/general`) under **Import sources**, which is available
   under **Admin Area > Settings > Visibility and access controls**.
-- The exports are stored in a temporary [shared directory](../../development/shared_files.md)
-  and are deleted every 24 hours by a specific worker.
+- The exports are stored in a temporary directory and are deleted every
+  24 hours by a specific worker.

doc/development/code_review.md

@@ -559,8 +559,9 @@ Enterprise Edition instance. This has some implications:
    1. Try to avoid that, and add to `ApplicationSetting` instead.
    1. Ensure that it is also
       [added to Omnibus](https://docs.gitlab.com/omnibus/settings/gitlab.yml.html#adding-a-new-setting-to-gitlab-yml).
-1. **File system access** can be slow, so try to avoid
-   [shared files](shared_files.md) when an alternative solution is available.
+1. **File system access** is not possible in a [cloud-native architecture](architecture.md#adapting-existing-and-introducing-new-components).
+   Ensure that we support object storage for any file storage we need to perform. For more
+   information, see the [uploads documentation](uploads.md).
 
 ### Review turnaround time
 

doc/development/contributing/merge_request_workflow.md

@@ -78,8 +78,7 @@ request is as follows:
 1. If your MR touches code that executes shell commands, reads or opens files, or
    handles paths to files on disk, make sure it adheres to the
    [shell command guidelines](../shell_commands.md)
-1. If your code creates new files on disk please read the
-   [shared files guidelines](../shared_files.md).
+1. If your code needs to handle file storage, see the [uploads documentation](../uploads.md).
 1. If your merge request adds one or more migrations, make sure to execute all
    migrations on a fresh database before the MR is reviewed. If the review leads
    to large changes in the MR, execute the migrations again once the review is complete.

doc/development/shared_files.md

@@ -6,34 +6,10 @@ info: To determine the technical writer assigned to the Stage/Group associated w
 
 # Shared files
 
-Historically, GitLab has been storing shared files in many different
-directories: `public/uploads`, `builds`, `tmp/repositories`, `tmp/rebase` (EE),
-etc. Having so many shared directories makes it difficult to deploy GitLab on
-shared storage (e.g. NFS). Working towards GitLab 9.0 we are consolidating
-these different directories under the `shared` directory.
+Historically, GitLab supported storing files that could be accessed from multiple application
+servers in `shared/`, using a shared storage solution like NFS. Although this is still an option for
+some GitLab installations, it must not be the only file storage option for a given feature. This is
+because [cloud-native GitLab installations do not support it](architecture.md#adapting-existing-and-introducing-new-components).
 
-This means that if GitLab begins storing puppies in some future version
-then we should put them in `shared/puppies`. Temporary puppy files should be
-stored in `shared/tmp`.
-
-In the GitLab application code you can get the full path to the `shared`
-directory with `Gitlab.config.shared.path`.
-
-## What is not a 'shared file'
-
-Files that belong to only one process, or on only one server, should not go in
-`shared`. Examples include PID files and sockets.
-
-## Temporary files and shared storage
-
-Sometimes you create a temporary file on disk with the intention of it becoming
-'official'. For example you might be first streaming an upload from a user to
-disk in a temporary file so you can perform some checks on it. When the checks
-pass, you make the file official. In scenarios like this please follow these
-rules:
-
-- Store the temporary file under `shared/tmp`, i.e. on the same file system you
-  want the official file to be on.
-- Use move/rename operations when operating on the file instead of copy
-  operations where possible, because renaming a file is much faster than
-  copying it.
+Our [uploads documentation](uploads.md) describes how to handle file storage in
+such a way that it supports both options: direct disk access and object storage.

doc/user/group/settings/import_export.md

@@ -29,7 +29,7 @@ To enable GitLab import/export:
 
 Note the following:
 
-- Exports are stored in a temporary [shared directory](../../../development/shared_files.md) and are deleted every 24 hours by a specific worker.
+- Exports are stored in a temporary directory and are deleted every 24 hours by a specific worker.
 - To preserve group-level relationships from imported projects, run the Group Import/Export first, to allow projects to
 be imported into the desired group structure.
 - Imported groups are given a `private` visibility level, unless imported into a parent group.

doc/user/project/settings/import_export.md

@@ -39,7 +39,7 @@ Note the following:
   The Importing GitLab version must be greater than or equal to the Exporting GitLab version.
 - Imports fail unless the import and export GitLab instances are
   compatible as described in the [Version history](#version-history).
-- Exports are generated in your configured `shared_path`, a temporary [shared directory](../../../development/shared_files.md)
+- Exports are generated in your configured `shared_path`, a temporary shared directory,
   and are moved to your configured `uploads_directory`. Every 24 hours, a specific worker deletes these export files.
 - Group members are exported as project members, as long as the user has
   maintainer or administrator access to the group where the exported project lives.