Resolve Markdown ordered lists not conforming to styleguide

doc/university/training/topics/merge_conflicts.md

@@ -16,15 +16,15 @@ comments: false
 ## Merge conflicts
 1. Checkout a new branch and edit `conflicts.rb`. Add 'Line4' and 'Line5'.
-2. Commit and push
-3. Checkout master and edit `conflicts.rb`. Add 'Line6' and 'Line7' below 'Line3'.
-4. Commit and push to master
-5. Create a merge request and watch it fail
-6. Rebase our new branch with master
-7. Fix conflicts on the `conflicts.rb` file.
-8. Stage the file and continue rebasing
-9. Force push the changes
-10. Finally continue with the Merge Request
+1. Commit and push.
+1. Checkout master and edit `conflicts.rb`. Add 'Line6' and 'Line7' below 'Line3'.
+1. Commit and push to master.
+1. Create a merge request and watch it fail.
+1. Rebase our new branch with master.
+1. Fix conflicts on the `conflicts.rb` file.
+1. Stage the file and continue rebasing.
+1. Force push the changes.
+1. Finally continue with the Merge Request.
 ----------

doc/university/training/topics/rollback_commits.md

@@ -41,15 +41,15 @@ comments: false
 ## Reset Workflow
 1. Edit file again 'edit_this_file.rb'
-2. Check status
-3. Add and commit with wrong message
-4. Check log
-5. Amend commit
-6. Check log
-7. Soft reset
-8. Check log
-9. Pull for updates
-10. Push changes
+1. Check status
+1. Add and commit with wrong message
+1. Check log
+1. Amend commit
+1. Check log
+1. Soft reset
+1. Check log
+1. Pull for updates
+1. Push changes
 ----------

doc/university/training/topics/stash.md

@@ -66,12 +66,12 @@ stashes.
 ## Git Stash
 1. Modify a file
-2. Stage file
-3. Stash it
-4. View our stash list
-5. Confirm no pending changes through status
-5. Apply with pop
-6. View list to confirm changes
+1. Stage file
+1. Stash it
+1. View our stash list
+1. Confirm no pending changes through status
+1. Apply with pop
+1. View list to confirm changes
 ----------

doc/update/README.md

@@ -38,12 +38,12 @@ Starting with GitLab 9.1.0 it's possible to upgrade to a newer major, minor, or
 patch version of GitLab without having to take your GitLab instance offline.
 However, for this to work there are the following requirements:
-1. You can only upgrade 1 minor release at a time. So from 9.1 to 9.2, not to
+- You can only upgrade 1 minor release at a time. So from 9.1 to 9.2, not to
    9.3.
-2. You have to use [post-deployment
+- You have to use [post-deployment
    migrations](../development/post_deployment_migrations.md) (included in
-   zero downtime update steps below)
-3. You are using PostgreSQL. If you are using MySQL please look at the release
+   zero downtime update steps below).
+- You are using PostgreSQL. If you are using MySQL please look at the release
    post to see if downtime is required.
 Most of the time you can safely upgrade from a patch release to the next minor

doc/user/profile/account/two_factor_authentication.md

@@ -158,7 +158,7 @@ authentication. If an SSH key is added to your GitLab account, you can generate
 a new set of recovery codes with SSH.
 1. Run `ssh git@gitlab.example.com 2fa_recovery_codes`.
-2. You are prompted to confirm that you want to generate new codes. Continuing this process invalidates previously saved codes.
+1. You are prompted to confirm that you want to generate new codes. Continuing this process invalidates previously saved codes.
     ```
     bash
     $ ssh git@gitlab.example.com 2fa_recovery_codes
@@ -185,7 +185,7 @@ a new set of recovery codes with SSH.
     so you do not lose access to your account again.
     ```
-3. Go to the GitLab sign-in page and enter your username/email and password.
+1. Go to the GitLab sign-in page and enter your username/email and password.
    When prompted for a two-factor code, enter one of the recovery codes obtained
    from the command-line output.

doc/user/profile/index.md

@@ -97,13 +97,13 @@ You and GitLab admins can see your the abovementioned information on your profil
 > [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/issues/14078) in GitLab 11.3.
-Enabling private contributions will include contributions to private projects, in the user contribution calendar graph and user recent activity. 
+Enabling private contributions will include contributions to private projects, in the user contribution calendar graph and user recent activity.
 To enable private contributions:
 1. Navigate to your personal [profile settings](#profile-settings).
-2. Check the "Private contributions" option.
-3. Hit **Update profile settings**.
+1. Check the "Private contributions" option.
+1. Hit **Update profile settings**.
 ## Current status

doc/user/project/container_registry.md

@@ -139,12 +139,12 @@ docker login registry.example.com -u <username> -p <token>
 1. Check to make sure that the system clock on your Docker client and GitLab server have
    been synchronized (e.g. via NTP).
-2. If you are using an S3-backed Registry, double check that the IAM
+1. If you are using an S3-backed Registry, double check that the IAM
    permissions and the S3 credentials (including region) are correct. See [the
    sample IAM policy](https://docs.docker.com/registry/storage-drivers/s3/)
    for more details.
-3. Check the Registry logs (e.g. `/var/log/gitlab/registry/current`) and the GitLab production logs
+1. Check the Registry logs (e.g. `/var/log/gitlab/registry/current`) and the GitLab production logs
    for errors (e.g. `/var/log/gitlab/gitlab-rails/production.log`). You may be able to find clues
    there.

doc/user/project/deploy_tokens/index.md

@@ -13,8 +13,8 @@ You can create as many deploy tokens as you like from the settings of your proje
 1. Log in to your GitLab account.
 1. Go to the project you want to create Deploy Tokens for.
-1. Go to **Settings** > **Repository**
-1. Click on "Expand" on **Deploy Tokens** section
+1. Go to **Settings** > **Repository**.
+1. Click on "Expand" on **Deploy Tokens** section.
 1. Choose a name and optionally an expiry date for the token.
 1. Choose the [desired scopes](#limiting-scopes-of-a-deploy-token).
 1. Click on **Create deploy token**.
@@ -46,8 +46,8 @@ the following table.
 To download a repository using a Deploy Token, you just need to:
 1. Create a Deploy Token with `read_repository` as a scope.
-2. Take note of your `username` and `token`
-3. `git clone` the project using the Deploy Token:
+1. Take note of your `username` and `token`.
+1. `git clone` the project using the Deploy Token:
     ```sh
     git clone http://<username>:<deploy_token>@gitlab.example.com/tanuki/awesome_project.git
@@ -60,8 +60,8 @@ Replace `<username>` and `<deploy_token>` with the proper values.
 To read the container registry images, you'll need to:
 1. Create a Deploy Token with `read_registry` as a scope.
-2. Take note of your `username` and `token`
-3. Log in to GitLab’s Container Registry using the deploy token:
+1. Take note of your `username` and `token`.
+1. Log in to GitLab’s Container Registry using the deploy token:
 ```sh
 docker login registry.example.com -u <username> -p <deploy_token>

doc/user/project/import/github.md

@@ -65,9 +65,9 @@ developer documentation.
 Before you begin, ensure that any GitHub users who you want to map to GitLab users have either:
-1. A GitLab account that has logged in using the GitHub icon
+- A GitLab account that has logged in using the GitHub icon
 \- or -
-2. A GitLab account with an email address that matches the [public email address](https://help.github.com/articles/setting-your-commit-email-address-on-github/) of the GitHub user
+- A GitLab account with an email address that matches the [public email address](https://help.github.com/articles/setting-your-commit-email-address-on-github/) of the GitHub user
 User-matching attempts occur in that order, and if a user is not identified either way, the activity is associated with
 the user account that is performing the import.
@@ -77,10 +77,10 @@ If you are using a self-hosted GitLab instance, this process requires that you h
 [GitHub integration][gh-import].
 1. From the top navigation bar, click **+** and select **New project**.
-2. Select the **Import project** tab and then select **GitHub**.
-3. Select the first button to **List your GitHub repositories**. You are redirected to a page on github.com to authorize the GitLab application.
-4. Click **Authorize gitlabhq**. You are redirected back to GitLab's Import page and all of your GitHub repositories are listed.
-5. Continue on to [selecting which repositories to import](#selecting-which-repositories-to-import).
+1. Select the **Import project** tab and then select **GitHub**.
+1. Select the first button to **List your GitHub repositories**. You are redirected to a page on github.com to authorize the GitLab application.
+1. Click **Authorize gitlabhq**. You are redirected back to GitLab's Import page and all of your GitHub repositories are listed.
+1. Continue on to [selecting which repositories to import](#selecting-which-repositories-to-import).
 ### Using a GitHub token
@@ -92,12 +92,12 @@ integration enabled, that should be the preferred method to import your reposito
 If you are not using the GitHub integration, you can still perform an authorization with GitHub to grant GitLab access your repositories:
 1. Go to https://github.com/settings/tokens/new
-2. Enter a token description.
-3. Select the repo scope.
-4. Click **Generate token**.
-5. Copy the token hash.
-6. Go back to GitLab and provide the token to the GitHub importer.
-7. Hit the **List Your GitHub Repositories** button and wait while GitLab reads your repositories' information.
+1. Enter a token description.
+1. Select the repo scope.
+1. Click **Generate token**.
+1. Copy the token hash.
+1. Go back to GitLab and provide the token to the GitHub importer.
+1. Hit the **List Your GitHub Repositories** button and wait while GitLab reads your repositories' information.
    Once done, you'll be taken to the importer page to select the repositories to import.
 ### Selecting which repositories to import
@@ -107,10 +107,10 @@ your GitHub repositories are listed.
 1. By default, the proposed repository namespaces match the names as they exist in GitHub, but based on your permissions,
    you can choose to edit these names before you proceed to import any of them.
-2. Select the **Import** button next to any number of repositories, or select **Import all repositories**.
-3. The **Status** column shows the import status of each repository. You can choose to leave the page open and it will
+1. Select the **Import** button next to any number of repositories, or select **Import all repositories**.
+1. The **Status** column shows the import status of each repository. You can choose to leave the page open and it will
    update in realtime or you can return to it later.
-4. Once a repository has been imported, click its GitLab path to open its GitLab URL.
+1. Once a repository has been imported, click its GitLab path to open its GitLab URL.
 ## Mirroring and pipeline status sharing

doc/user/project/integrations/bugzilla.md

@@ -16,8 +16,9 @@ Once you have configured and enabled Bugzilla you'll see the Bugzilla link on th
 ## Referencing issues in Bugzilla
 Issues in Bugzilla can be referenced in two alternative ways:
-1. `#<ID>` where `<ID>` is a number (example `#143`).
-2. `<PROJECT>-<ID>` where `<PROJECT>` starts with a capital letter which is
+
+- `#<ID>` where `<ID>` is a number (example `#143`).
+- `<PROJECT>-<ID>` where `<PROJECT>` starts with a capital letter which is
   then followed by capital letters, numbers or underscores, and `<ID>` is
   a number (example `API_32-143`).

doc/user/project/integrations/jira_cloud_configuration.md

@@ -4,16 +4,15 @@ An API token is needed when integrating with JIRA Cloud, follow the steps
 below to create one:
 1. Log in to https://id.atlassian.com with your email.
-2. **Click API tokens**, then **Create API token**.
+1. **Click API tokens**, then **Create API token**.
 ![JIRA API token](img/jira_api_token_menu.png)
 ![JIRA API token](img/jira_api_token.png)
-3. Make sure to write down your new API token as you will need it in the next [steps](jira.md#configuring-gitlab).
+1. Make sure to write down your new API token as you will need it in the next [steps](jira.md#configuring-gitlab).
 NOTE: **Note**
 It is important that the user associated with this email has 'write' access to projects in JIRA.
 The JIRA configuration is complete. You are going to need this new created token and the email you used to log in when [configuring GitLab in the next section](jira.md#configuring-gitlab).
-

doc/user/project/integrations/jira_server_configuration.md

@@ -17,17 +17,17 @@ We have split this stage in steps so it is easier to follow.
      ![Jira user management link](img/jira_user_management_link.png)
-2. The next step is to create a new user (e.g., `gitlab`) who has write access
+1. The next step is to create a new user (e.g., `gitlab`) who has write access
    to projects in Jira. Enter the user's name and a _valid_ e-mail address
    since Jira sends a verification e-mail to set up the password.
    _**Note:** Jira creates the username automatically by using the e-mail
-   prefix. You can change it later, if needed. Our integration does not support SSO (such as SAML). You will need to create 
-    an HTTP basic authentication password. You can do this by visiting the user 
+   prefix. You can change it later, if needed. Our integration does not support SSO (such as SAML). You will need to create
+    an HTTP basic authentication password. You can do this by visiting the user
     profile, looking up the username, and setting a password._
      ![Jira create new user](img/jira_create_new_user.png)
-3. Create a `gitlab-developers` group which will have write access
+1. Create a `gitlab-developers` group which will have write access
    to projects in Jira. Go to the **Groups** tab and select **Create group**.
      ![Jira create new user](img/jira_create_new_group.png)
@@ -36,13 +36,13 @@ We have split this stage in steps so it is easier to follow.
      ![Jira create new group](img/jira_create_new_group_name.png)
-4. To give the newly-created group 'write' access, go to
+1. To give the newly-created group 'write' access, go to
    **Application access > View configuration** and add the `gitlab-developers`
    group to Jira Core.
      ![Jira group access](img/jira_group_access.png)
-5. Add the `gitlab` user to the `gitlab-developers` group by going to
+1. Add the `gitlab` user to the `gitlab-developers` group by going to
    **Users > GitLab user > Add group** and selecting the `gitlab-developers`
    group from the dropdown menu. Notice that the group says _Access_, which is
    intended as part of this process.

doc/user/project/integrations/redmine.md

@@ -18,15 +18,16 @@ in the table below.
     ![Redmine configuration](img/redmine_configuration.png)
-2. To disable the internal issue tracking system in a project, navigate to the General page, expand [Permissions](../settings/index.md#sharing-and-permissions), and slide the Issues switch invalid.
+1. To disable the internal issue tracking system in a project, navigate to the General page, expand [Permissions](../settings/index.md#sharing-and-permissions), and slide the Issues switch invalid.
     ![Issue configuration](img/issue_configuration.png)
 ## Referencing issues in Redmine
 Issues in Redmine can be referenced in two alternative ways:
-1. `#<ID>` where `<ID>` is a number (example `#143`)
-2. `<PROJECT>-<ID>` where `<PROJECT>` starts with a capital letter which is
+
+- `#<ID>` where `<ID>` is a number (example `#143`).
+- `<PROJECT>-<ID>` where `<PROJECT>` starts with a capital letter which is
   then followed by capital letters, numbers or underscores, and `<ID>` is
   a number (example `API_32-143`).

doc/user/project/integrations/webhooks.md

@@ -338,10 +338,10 @@ payload will also include information about the target of the comment. For examp
 a comment on an issue will include the specific issue information under the `issue` key.
 Valid target types:
-1. `commit`
-2. `merge_request`
-3. `issue`
-4. `snippet`
+- `commit`
+- `merge_request`
+- `issue`
+- `snippet`
 #### Comment on commit

doc/user/project/issues/automatic_issue_closing.md

@@ -27,10 +27,11 @@ used:
 Note that `%{issue_ref}` is a complex regular expression defined inside GitLab's
 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`).
+
+- A local issue (`#123`).
+- A cross-project issue (`group/project#123`).
+- A link to an issue
+  (`https://gitlab.example.com/group/project/issues/123`).
 ---

doc/user/project/new_ci_build_permissions_model.md

@@ -60,7 +60,7 @@ Let's consider the following scenario:
    hosted in private repositories and you have multiple CI jobs that make use
    of these repositories.
-2. You invite a new [external user][ext]. CI jobs created by that user do not
+1. You invite a new [external user][ext]. CI jobs created by that user do not
    have access to internal repositories, because the user also doesn't have the
    access from within GitLab. You as an employee have to grant explicit access
    for this user. This allows us to prevent from accidental data leakage.