Merge branch 'docs-port-ee-community-contributions' into 'master'

Docs port ee community contributions

See merge request gitlab-org/gitlab-ce!21311

doc/administration/gitaly/index.md

@@ -149,7 +149,7 @@ listen_addr = '0.0.0.0:8075'
 [auth]
 token = 'abc123secret'
 
-[[storage]
+[[storage]]
 name = 'default'
 path = '/mnt/gitlab/default/repositories'
 

doc/administration/high_availability/nfs.md

@@ -47,7 +47,7 @@ there because this will also affect performance. We recommend that the log files
 stored on a local volume.
 
 For more details on another person's experience with EFS, see
-[Amazon's Elastic File System: Burst Credits](https://www.rawkode.io/2017/04/amazons-elastic-file-system-burst-credits/)
+[Amazon's Elastic File System: Burst Credits](https://rawkode.com/2017/04/16/amazons-elastic-file-system-burst-credits/)
 
 ## NFS Client mount options
 

doc/administration/job_artifacts.md

@@ -190,7 +190,7 @@ _The artifacts are stored by default in
         remote_directory: "artifacts" # The bucket name
         connection:
           provider: AWS # Only AWS supported at the moment
-          aws_access_key_id: AWS_ACESS_KEY_ID
+          aws_access_key_id: AWS_ACCESS_KEY_ID
           aws_secret_access_key: AWS_SECRET_ACCESS_KEY
           region: eu-central-1
     ```

doc/administration/pages/index.md

@@ -11,6 +11,7 @@ description: 'Learn how to administer GitLab Pages.'
 - This guide is for Omnibus GitLab installations. If you have installed
   GitLab from source, follow the [Pages source installation document](source.md).
 - To learn how to use GitLab Pages, read the [user documentation][pages-userguide].
+- Does NOT support subgroups. See [this issue](https://gitlab.com/gitlab-org/gitlab-ce/issues/30548) for more information and status.
 
 This document describes how to set up the _latest_ GitLab Pages feature. Make
 sure to read the [changelog](#changelog) if you are upgrading to a new GitLab
@@ -73,8 +74,8 @@ among other things.
 
 Follow [these instructions](https://publicsuffix.org/submit/) to submit your
 GitLab Pages subdomain. For instance, if your domain is `example.io`, you should
-request that `*.example.io` is added to the Public Suffix List. GitLab.com
-added `*.gitlab.io` [in 2016](https://gitlab.com/gitlab-com/infrastructure/issues/230).
+request that `example.io` is added to the Public Suffix List. GitLab.com
+added `gitlab.io` [in 2016](https://gitlab.com/gitlab-com/infrastructure/issues/230).
 
 ### DNS configuration
 

doc/api/groups.md

@@ -82,7 +82,7 @@ You can filter by [custom attributes](custom_attributes.md) with:
 GET /groups?custom_attributes[key]=value&custom_attributes[other_key]=other_value
 ```
 
-## List a groups's subgroups
+## List a group's subgroups
 
 > [Introduced][ce-15142] in GitLab 10.3.
 

doc/api/projects.md

@@ -710,7 +710,7 @@ PUT /projects/:id
 | Attribute | Type | Required | Description |
 | --------- | ---- | -------- | ----------- |
 | `id` | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) |
-| `name` | string | yes | The name of the project |
+| `name` | string | no | The name of the project |
 | `path` | string | no | Custom repository name for the project. By default generated based on name |
 | `default_branch` | string | no | `master` by default |
 | `description` | string | no | Short project description |

doc/api/tags.md

@@ -174,8 +174,19 @@ Parameters:
 
 - `id` (required) - The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user
 - `tag_name` (required) - The name of a tag
+
+Request body:
+
 - `description` (required) - Release notes with markdown support
 
+```json
+{
+  "description": "Amazing release. Wow"
+}
+```
+
+Response:
+
 ```json
 {
   "tag_name": "1.0.0",
@@ -195,8 +206,19 @@ Parameters:
 
 - `id` (required) - The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user
 - `tag_name` (required) - The name of a tag
+
+Request body:
+
 - `description` (required) - Release notes with markdown support
 
+```json
+{
+  "description": "Amazing release. Wow"
+}
+```
+
+Response:
+
 ```json
 {
   "tag_name": "1.0.0",

doc/ci/caching/index.md

@@ -87,7 +87,7 @@ you can use the same key for all of them:
 
 ```yaml
 cache:
-  key: one-key-to-rull-them-all
+  key: one-key-to-rule-them-all
 ```
 
 To share the same cache between branches, but separate them by job:
@@ -489,7 +489,15 @@ needed to compile the project:
   Artifacts were designed to upload some compiled/generated bits of the build,
   and they can be fetched by any number of concurrent Runners. They are
   guaranteed to be available and are there to pass data between jobs. They are
-  also exposed to be downloaded from the UI.
+  also exposed to be downloaded from the UI. **Artifacts can only exist in
+  directories relative to the build directory** and specifying paths which don't
+  comply to this rule trigger an unintuitive and unlogical error message (an
+  enhancement is discussed at
+  https://gitlab.com/gitlab-org/gitlab-ce/issues/15530). Artifacts need to be
+  uploaded to the GitLab instance (not only the GitLab runner) before the next
+  stage job(s) can start, so you need to evaluate carefully whether your
+  bandwidth allows you to profit from parallelization with stages and shared
+  artifacts before investing time in changes to the setup.
 
 It's sometimes confusing because the name artifact sounds like something that
 is only useful outside of the job, like for downloading a final image. But

doc/ci/yaml/README.md

@@ -390,6 +390,28 @@ job:
 The specification above, will make sure that `job` is built by a Runner that
 has both `ruby` AND `postgres` tags defined.
 
+Tags are also a great way to run different jobs on different platforms, for
+example, given an OS X Runner with tag `osx` and Windows Runner with tag
+`windows`, the following jobs run on respective platforms:
+
+```yaml
+windows job:
+  stage:
+    - build
+  tags:
+    - windows
+  script:
+    - echo Hello, %USERNAME%!
+
+osx job:
+  stage:
+    - build
+  tags:
+    - osx
+  script:
+    - echo "Hello, $USER!"
+```
+
 ## `allow_failure`
 
 `allow_failure` is used when you want to allow a job to fail without impacting

doc/install/kubernetes/gitlab_omnibus.md

@@ -101,7 +101,7 @@ Other common configuration options:
 - `provider`: Optimizes the deployment for a cloud provider. The default is `gke` for [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/), with `acs` also supported for the [Azure Container Service](https://azure.microsoft.com/en-us/services/container-service/).
 
 For additional configuration options, consult the
-[`values.yaml`](https://gitlab.com/charts/charts.gitlab.io/blob/master/charts/gitlab-omnibus/values.yaml).
+[`values.yaml`](https://gitlab.com/charts/gitlab-omnibus/blob/master/values.yaml).
 
 ### Choosing a different GitLab release version
 
@@ -228,7 +228,7 @@ helm upgrade gitlab --set gitlab=ee,gitlabEEImage=gitlab/gitlab-ee:9.5.5-ee.0 gi
 To uninstall the GitLab Chart, run the following:
 
 ```bash
-helm delete gitlab
+helm delete --purge gitlab
 ```
 
 ## Troubleshooting

doc/raketasks/backup_restore.md

@@ -124,7 +124,7 @@ To use the `copy` strategy instead of the default streaming strategy, specify
 
 ### Excluding specific directories from the backup
 
-You can choose what should be backed up by adding the environment variable `SKIP`.
+You can choose what should be exempt from the backup up by adding the environment variable `SKIP`.
 The available options are:
 
 - `db` (database)
@@ -138,6 +138,9 @@ The available options are:
 
 Use a comma to specify several options at the same time:
 
+All wikis will be backed up as part of the `repositories` group. Non-existent wikis
+will be skipped during a backup.
+
 ```
 # use this command if you've installed GitLab with the Omnibus package
 sudo gitlab-rake gitlab:backup:create SKIP=db,uploads

doc/security/README.md

@@ -10,6 +10,7 @@ comments: false
 - [Webhooks and insecure internal web services](webhooks.md)
 - [Information exclusivity](information_exclusivity.md)
 - [Reset your root password](reset_root_password.md)
+- [Unlock a locked user](unlock_user.md)
 - [User File Uploads](user_file_uploads.md)
 - [How we manage the CRIME vulnerability](crime_vulnerability.md)
 - [Enforce Two-factor authentication](two_factor_authentication.md)

doc/security/reset_root_password.md

@@ -37,4 +37,4 @@ Don't forget to save the changes.
 user.save!
 ```
 
-Exit the console and try to login with your new password.
\ No newline at end of file
+Exit the console and try to login with your new password.

doc/security/unlock_user.md

+# How to unlock a locked user
+
+Log into your server with root privileges. Then start a Ruby on Rails console.
+
+Start the console with this command:
+
+```bash
+gitlab-rails console production
+```
+
+Wait until the console has loaded.
+
+There are multiple ways to find your user. You can search for email or username.
+
+```bash
+user = User.where(id: 1).first
+```
+
+or
+
+```bash
+user = User.find_by(email: 'admin@local.host')
+```
+
+Unlock the user:
+
+```bash
+user.unlock_access!
+```
+
+Exit the console, the user should now be able to log in again.

doc/security/user_email_confirmation.md

@@ -4,4 +4,4 @@ Gitlab admin can enable email confirmation on sign-up, if you want to confirm al
 user emails before they are able to sign-in.
 
 In the Admin area under **Settings** (`/admin/application_settings`), go to section
-**Sign-in Restrictions** and look for **Send confirmation email on sign-up** option.
+**Sign-up Restrictions** and look for **Send confirmation email on sign-up** option.

doc/ssh/README.md

@@ -48,9 +48,11 @@ Note that Public SSH key may also be named as follows:
     **Git Bash on Windows / GNU/Linux / macOS:**
 
     ```bash
-    ssh-keygen -t rsa -C "your.email@example.com" -b 4096
+    ssh-keygen -o -t rsa -C "your.email@example.com" -b 4096
     ```
 
+    (Note: the `-o` option was introduced in 2014; if this command does not work for you, simply remove the `-o` option and try again)
+
     **Windows:**
 
     Alternatively on Windows you can download
@@ -75,7 +77,9 @@ Note that Public SSH key may also be named as follows:
 
      NOTE: **Note:**
      If you want to change the password of your SSH key pair, you can use
-     `ssh-keygen -p <keyname>`.
+     `ssh-keygen -p -o -f <keyname>`.
+     The `-o` option was added in 2014, so if this command does not work for you,
+     simply remove the `-o` option and try again.
 
 ## Adding a SSH key to your GitLab account
 
@@ -191,15 +195,15 @@ project.
 
 ### Global shared deploy keys
 
-Global Shared Deploy keys allow read-only or read-write (if enabled) access to 
+Global Shared Deploy keys allow read-only or read-write (if enabled) access to
 be configured on any repository in the entire GitLab installation.
 
 This is really useful for integrating repositories to secured, shared Continuous
-Integration (CI) services or other shared services. 
-GitLab administrators can set up the Global Shared Deploy key in GitLab and 
+Integration (CI) services or other shared services.
+GitLab administrators can set up the Global Shared Deploy key in GitLab and
 add the private key to any shared systems.  Individual repositories opt into
 exposing their repository using these keys when a project maintainers (or higher)
-authorizes a Global Shared Deploy key to be used with their project. 
+authorizes a Global Shared Deploy key to be used with their project.
 
 Global Shared Keys can provide greater security compared to Per-Project Deploy
 Keys since an administrator of the target integrated system is the only one
@@ -211,13 +215,13 @@ the primary way for project maintainers and owners to identify the correct Globa
 Deploy key to add.  For instance, if the key gives access to a SaaS CI instance,
 use the name of that service in the key name if that is all it is used for.
 When creating Global Shared Deploy keys, give some thought to the granularity
-of keys - they could be of very narrow usage such as just a specific service or 
-of broader usage for something like "Anywhere you need to give read access to 
+of keys - they could be of very narrow usage such as just a specific service or
+of broader usage for something like "Anywhere you need to give read access to
 your repository".
 
-Once a GitLab administrator adds the Global Deployment key, project maintainers 
-and owners can add it in project's **Settings > Repository** section by expanding the 
-**Deploy Key** section and clicking **Enable** next to the appropriate key listed 
+Once a GitLab administrator adds the Global Deployment key, project maintainers
+and owners can add it in project's **Settings > Repository** section by expanding the
+**Deploy Key** section and clicking **Enable** next to the appropriate key listed
 under **Public deploy keys available to any project**.
 
 NOTE: **Note:**

doc/topics/autodevops/index.md

@@ -450,7 +450,7 @@ executed somewhere else, it cannot be accessed again.
 
 > [Introduced][ce-19507] in GitLab 11.0.
 
-For internal and private projects a [GitLab Deploy Token](../../user/project/deploy_tokens/index.md###gitlab-deploy-token) 
+For internal and private projects a [GitLab Deploy Token](../../user/project/deploy_tokens/index.md###gitlab-deploy-token)
 will be automatically created, when Auto DevOps is enabled and the Auto DevOps settings are saved. This Deploy Token
 can be used for permanent access to the registry.
 
@@ -574,13 +574,13 @@ postgres://user:password@postgres-host:postgres-port/postgres-database
 ### Environment variables
 
 The following variables can be used for setting up the Auto DevOps domain,
-providing a custom Helm chart, or scaling your application. PostgreSQL can be
+providing a custom Helm chart, or scaling your application. PostgreSQL can
 also be customized, and you can easily use a [custom buildpack](#custom-buildpacks).
 
 | **Variable**                 | **Description**                                                                                                                                                                                                               |
 | ------------                 | ---------------                                                                                                                                                                                                               |
 | `AUTO_DEVOPS_DOMAIN`         | The [Auto DevOps domain](#auto-devops-domain); by default set automatically by the [Auto DevOps setting](#enabling-auto-devops).                                                                                              |
-| `AUTO_DEVOPS_CHART`          | The Helm Chart used to deploy your apps; defaults to the one [provided by GitLab](https://gitlab.com/charts/charts.gitlab.io/tree/master/charts/auto-deploy-app).                                                             |
+| `AUTO_DEVOPS_CHART`          | The Helm Chart used to deploy your apps; defaults to the one [provided by GitLab](https://gitlab.com/charts/auto-deploy-app).                                                             |
 | `REPLICAS`                   | The number of replicas to deploy; defaults to 1.                                                                                                                                                                              |
 | `PRODUCTION_REPLICAS`        | The number of replicas to deploy in the production environment. This takes precedence over `REPLICAS`; defaults to 1.                                                                                                         |
 | `CANARY_REPLICAS`            | The number of canary replicas to deploy for [Canary Deployments](https://docs.gitlab.com/ee/user/project/canary_deployments.html); defaults to 1                                                                              |

doc/topics/autodevops/quick_start_guide.md

@@ -143,7 +143,7 @@ In the next section we'll break down the pipeline and explain what each job does
 
 By now you should see the pipeline running, but what is it running exactly?
 
-To navigate inside the pipeline, click its status badge. (It's status should be "running").
+To navigate inside the pipeline, click its status badge. (Its status should be "running").
 The pipeline is split into 4 stages, each running a couple of jobs.
 
 ![Pipeline stages](img/guide_pipeline_stages.png)
@@ -194,7 +194,7 @@ applications. In the rightmost column for the production environment, you can ma
 
 - The first icon will open the URL of the application that is deployed in
   production. It's a very simple page, but the important part is that it works!
-- The next icon with the small graph will take you to the metrics page where
+- The next icon, with the small graph, will take you to the metrics page where
   Prometheus collects data about the Kubernetes cluster and how the application
   affects it (in terms of memory/CPU usage, latency, etc.).
 
@@ -217,7 +217,7 @@ under **Settings > CI/CD > Variables**.
 
 ### Working with branches
 
-Following the [GitLab flow](../../workflow/gitlab_flow.md#working-with-feature-branches)
+Following the [GitLab flow](../../workflow/gitlab_flow.md#working-with-feature-branches),
 let's create a feature branch that will add some content to the application.
 
 Under your repository, navigate to the following file: `app/views/welcome/index.html.erb`.
@@ -235,7 +235,7 @@ by clicking **Commit**.
 ![Web IDE commit](img/guide_ide_commit.png)
 
 Once you submit the merge request, you'll see the pipeline running. This will
-run all the jobs as [described previously](#deploying-the-application), as well
+run all the jobs as [described previously](#deploying-the-application), as well as
 a few more that run only on branches other than `master`.
 
 ![Merge request](img/guide_merge_request.png)
@@ -278,7 +278,7 @@ and the application will be eventually deployed straight to production.
 
 After implementing this project, you should now have a solid understanding of the basics of Auto DevOps.
 We started from building and testing to deploying and monitoring an application
-all within GitLab. Despite its automatic nature, Audo DevOps can also be configured
+all within GitLab. Despite its automatic nature, Auto DevOps can also be configured
 and customized to fit your workflow. Here are some helpful resources for further reading:
 
 1. [Auto DevOps](index.md)

doc/update/README.md

@@ -142,4 +142,4 @@ possible.
 [ee-ce]: ../downgrade_ee_to_ce/README.md
 [ce]: https://about.gitlab.com/features/#community
 [ee]: https://about.gitlab.com/features/#enterprise
-[omni-ce-ee]: http://docs.gitlab.com/omnibus/update/README.html#from-community-edition-to-enterprise-edition
+[omni-ce-ee]: https://docs.gitlab.com/omnibus/update/README.html#updating-community-edition-to-enterprise-edition

doc/user/project/import/svn.md

@@ -8,7 +8,7 @@ between the two, for more information consult your favorite search engine.
 
 There are two approaches to SVN to Git migration:
 
-1. [Git/SVN Mirror](#smooth-migration-with-a-gitsvn-mirror-using-subgit) which:
+1. [Git/SVN Mirror](#smooth-migration-with-a-git-svn-mirror-using-subgit) which:
     - Makes the GitLab repository to mirror the SVN project.
     - Git and SVN repositories are kept in sync; you can use either one.
     - Smoothens the migration process and allows to manage migration risks.

doc/user/project/issues/automatic_issue_closing.md

@@ -26,8 +26,10 @@ used:
 ```
 
 Note that `%{issue_ref}` is a complex regular expression defined inside GitLab's
-source code that can match a reference to 1) a local issue (`#123`),
-2) a cross-project issue (`group/project#123`) or 3) a link to an issue
+source code that can match references to:
+1. a local issue (`#123`),
+2. a cross-project issue (`group/project#123`) 
+3. a link to an issue
 (`https://gitlab.example.com/group/project/issues/123`).
 
 ---

doc/user/project/repository/gpg_signed_commits/index.md

@@ -55,6 +55,8 @@ started:
     ```sh
     gpg --full-gen-key
     ```
+    
+_NOTE: In some cases like Gpg4win on Windows and other Mac OS versions the command here may be ` gpg --gen-key`_
 
     This will spawn a series of questions.
 

doc/workflow/lfs/lfs_administration.md

@@ -24,7 +24,7 @@ There are various configuration options to help GitLab server administrators:
 In `/etc/gitlab/gitlab.rb`:
 
 ```ruby
-# Change to true to enable lfs
+# Change to true to enable lfs - enabled by default if not defined
 gitlab_rails['lfs_enabled'] = false
 
 # Optionally, change the storage path location. Defaults to

doc/workflow/timezone.md

@@ -9,6 +9,7 @@ Uncomment and customize if you want to change the default time zone of GitLab ap
 
 To see all available time zones, run `bundle exec rake time:zones:all`.
 
+With Omnibus installations, run `gitlab-rake time:zones:all`.
 
 ## Changing time zone in omnibus installations
 

scripts/lint-doc.sh

@@ -5,7 +5,7 @@ cd "$(dirname "$0")/.."
 # Use long options (e.g. --header instead of -H) for curl examples in documentation.
 echo '=> Checking for cURL short options...'
 grep --extended-regexp --recursive --color=auto 'curl (.+ )?-[^- ].*' doc/ >/dev/null 2>&1
-if [ $? == 0 ]
+if [ $? -eq 0 ]
 then
   echo '✖ ERROR: Short options for curl should not be used in documentation!
          Use long options (e.g., --header instead of -H):' >&2