Remove trailing whitespace in docs

Remove unneeded trailing whitespace in lines in
/development /ci /api and /administration docs.

7 files changed, 71 insertions, 73 deletions

diff --git a/doc/development/contributing/issue_workflow.md b/doc/development/contributing/issue_workflow.md
index 910f9f4bf7a..d0562cd2bbd 100644
--- a/doc/development/contributing/issue_workflow.md
+++ b/doc/development/contributing/issue_workflow.md
@@ -58,9 +58,9 @@ issue is labeled with a subject label corresponding to your expertise.
 
 Subject labels are always all-lowercase.
 
-## Team labels 
+## Team labels
 
-**Important**: Most of the team labels will be soon deprecated in favor of [Group labels](#group-labels). 
+**Important**: Most of the team labels will be soon deprecated in favor of [Group labels](#group-labels).
 
 Team labels specify what team is responsible for this issue.
 Assigning a team label makes sure issues get the attention of the appropriate
@@ -98,7 +98,6 @@ indicate if an issue needs backend work, frontend work, or both.
 Team labels are always capitalized so that they show up as the first label for
 any issue.
 
-
 ## Stage labels
 
 Stage labels specify which [DevOps stage][devops-stages] the issue belongs to.
@@ -141,43 +140,42 @@ Group labels specify which [groups][structure-groups] the issue belongs to.
 
 The current group labels are:
 
-* ~"group::access"
-* ~"group::measure"
-* ~"group::source code" 
-* ~"group::knowledge" 
-* ~"group::editor" 
-* ~"group::gitaly"  
-* ~"group::gitter"  
-* ~"group::team planning" 
-* ~"group::enterprise planning" 
-* ~"group::certify" 
-* ~"group::ci and runner" 
-* ~"group::testing" 
-* ~"group::package" 
-* ~"group::progressive delivery" 
-* ~"group::release management" 
-* ~"group::autodevops and kubernetes" 
-* ~"group::serverless and paas"
-* ~"group::apm" 
-* ~"group::health"
-* ~"group::static analysis"
-* ~"group::dynamic analysis"
-* ~"group::software composition analysis" 
-* ~"group::runtime application security" 
-* ~"group::threat management" 
-* ~"group::application infrastructure security" 
-* ~"group::activation" 
-* ~"group::adoption" 
-* ~"group::upsell" 
-* ~"group::retention" 
-* ~"group::fulfillment" 
-* ~"group::telemetry" 
-* ~"group::distribution" 
-* ~"group::geo" 
-* ~"group::memory" 
-* ~"group::ecosystem" 
+- ~"group::access"
+- ~"group::measure"
+- ~"group::source code"
+- ~"group::knowledge"
+- ~"group::editor"
+- ~"group::gitaly"  
+- ~"group::gitter"  
+- ~"group::team planning"
+- ~"group::enterprise planning"
+- ~"group::certify"
+- ~"group::ci and runner"
+- ~"group::testing"
+- ~"group::package"
+- ~"group::progressive delivery"
+- ~"group::release management"
+- ~"group::autodevops and kubernetes"
+- ~"group::serverless and paas"
+- ~"group::apm"
+- ~"group::health"
+- ~"group::static analysis"
+- ~"group::dynamic analysis"
+- ~"group::software composition analysis"
+- ~"group::runtime application security"
+- ~"group::threat management"
+- ~"group::application infrastructure security"
+- ~"group::activation"
+- ~"group::adoption"
+- ~"group::upsell"
+- ~"group::retention"
+- ~"group::fulfillment"
+- ~"group::telemetry"
+- ~"group::distribution"
+- ~"group::geo"
+- ~"group::memory"
+- ~"group::ecosystem"
   
-
 These labels are [scoped labels](../../user/project/labels.md#scoped-labels-premium)
 and thus are mutually exclusive.
 
@@ -192,15 +190,15 @@ can be applied to a single issue. You can find the groups listed in the
 
 The current department labels are:
 
-* ~UX
-* ~Quality
+- ~UX
+- ~Quality
 
 ## Specialization labels
 
 These labels narrow the [specialization](https://about.gitlab.com/company/team/structure/#specialist) on a unit of work.
 
-* ~frontend
-* ~backend
+- ~frontend
+- ~backend
 
 ## Release Scoping labels
 
@@ -248,9 +246,9 @@ There can be multiple facets of the impact. The below is a guideline.
 If a bug seems to fall between two severity labels, assign it to the higher-severity label.
 
 - Example(s) of ~S1
-  - Data corruption/loss. 
+  - Data corruption/loss.
   - Security breach.
-  - Unable to create an issue or merge request. 
+  - Unable to create an issue or merge request.
   - Unable to add a comment or discussion to the issue or merge request.
 - Example(s) of ~S2
   - Cannot submit changes through the web IDE but the commandline works.
diff --git a/doc/development/documentation/workflow.md b/doc/development/documentation/workflow.md
index 0abfe4b82a4..9f488fac7d0 100644
--- a/doc/development/documentation/workflow.md
+++ b/doc/development/documentation/workflow.md
@@ -6,5 +6,5 @@ description: Learn the processes for contributing to GitLab's documentation.
 
 Documentation workflows at GitLab differ depending on the reason for the change:
 
-- [Documentation process for feature changes](feature-change-workflow.md) - The documentation is being created or updated as part of the development and release of a new or enhanced feature. This process involves the developer of the feature (who includes new/updated documentation files as part of the same merge request containing the feature's code) and also involves the product manager and technical writer who are listed for the feature's [DevOps stage](https://about.gitlab.com/handbook/product/categories/#devops-stages). 
+- [Documentation process for feature changes](feature-change-workflow.md) - The documentation is being created or updated as part of the development and release of a new or enhanced feature. This process involves the developer of the feature (who includes new/updated documentation files as part of the same merge request containing the feature's code) and also involves the product manager and technical writer who are listed for the feature's [DevOps stage](https://about.gitlab.com/handbook/product/categories/#devops-stages).
 - [Documentation improvement workflow](improvement-workflow.md) - All documentation additions not associated with a feature release. Documentation is being created or updated to improve accuracy, completeness, ease of use, or any reason other than a feature change. Anyone (and everyone) can contribute a merge request for this type of change at any time.
diff --git a/doc/development/i18n/proofreader.md b/doc/development/i18n/proofreader.md
index 35c5b155594..910d7296057 100644
--- a/doc/development/i18n/proofreader.md
+++ b/doc/development/i18n/proofreader.md
@@ -106,32 +106,31 @@ are very appreciative of the work done by translators and proofreaders!
 1. Contribute translations to GitLab. See instructions for
    [translating GitLab](translation.md).
 
-    Translating GitLab is a community effort that requires team work and
-    attention to detail. Proofreaders play an important role helping new
-    contributors, and ensuring the consistency and quality of translations.
-    Your conduct and contributions as a translator should reflect this before
-    requesting to be a proofreader.
+   Translating GitLab is a community effort that requires team work and
+   attention to detail. Proofreaders play an important role helping new
+   contributors, and ensuring the consistency and quality of translations.
+   Your conduct and contributions as a translator should reflect this before
+   requesting to be a proofreader.
 
 1. Request proofreader permissions by opening a merge request to add yourself
    to the list of proofreaders.
 
-    Open the [proofreader.md source file][proofreader-src] and click **Edit**.
+   Open the [proofreader.md source file][proofreader-src] and click **Edit**.
 
-    Add your language in alphabetical order, and add yourself to the list
-    including:
-    - name
-    - link to your GitLab profile
-    - link to your CrowdIn profile
+   Add your language in alphabetical order, and add yourself to the list
+   including:
+   - name
+   - link to your GitLab profile
+   - link to your CrowdIn profile
 
-    In the merge request description, please include links to any projects you
-    have previously translated.
+   In the merge request description, please include links to any projects you
+   have previously translated.
 
 1. Your request to become a proofreader will be considered on the merits of
    your previous translations by [GitLab team members](https://about.gitlab.com/team/)
    or [Core team members](https://about.gitlab.com/core-team/) who are fluent in
    the language or current proofreaders.
    - When a request is made for the first proofreader for a language and there are no [GitLab team members](https://about.gitlab.com/team/)
-   or [Core team members](https://about.gitlab.com/core-team/) who speak the language, we will request links to previous translation work in other communities or projects.  
-
+   or [Core team members](https://about.gitlab.com/core-team/) who speak the language, we will request links to previous translation work in other communities or projects.
 
 [proofreader-src]: https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/i18n/proofreader.md
diff --git a/doc/development/new_fe_guide/style/prettier.md b/doc/development/new_fe_guide/style/prettier.md
index 4495f38f262..5f44c640d76 100644
--- a/doc/development/new_fe_guide/style/prettier.md
+++ b/doc/development/new_fe_guide/style/prettier.md
@@ -4,7 +4,7 @@ Our code is automatically formatted with [Prettier](https://prettier.io) to foll
 
 ## Editor
 
-The easiest way to include prettier in your workflow is by setting up your preferred editor (all major editors are supported) accordingly. We suggest setting up prettier to run automatically when each file is saved. Find [here](https://prettier.io/docs/en/editors.html) the best way to set it up in your preferred editor. 
+The easiest way to include prettier in your workflow is by setting up your preferred editor (all major editors are supported) accordingly. We suggest setting up prettier to run automatically when each file is saved. Find [here](https://prettier.io/docs/en/editors.html) the best way to set it up in your preferred editor.
 
 Please take care that you only let Prettier format the same file types as the global Yarn script does (.js, .vue, and .scss). In VSCode by example you can easily exclude file formats in your settings file:
 
@@ -28,6 +28,7 @@ Updates all currently staged files (based on `git diff`) with Prettier and saves
 ```
 yarn prettier-staged
 ```
+
 Checks all currently staged files (based on `git diff`) with Prettier and log which files would need manual updating to the console.
 
 ```
diff --git a/doc/development/testing_guide/end_to_end/index.md b/doc/development/testing_guide/end_to_end/index.md
index 59eb3ecfd7e..2dc06ba10a5 100644
--- a/doc/development/testing_guide/end_to_end/index.md
+++ b/doc/development/testing_guide/end_to_end/index.md
@@ -148,7 +148,7 @@ Once you decided where to put [test environment orchestration scenarios] and
 the [GitLab QA orchestrator README][gitlab-qa-readme], and [the already existing
 instance-level scenarios][instance-level scenarios].
 
-Continued reading:  
+Continued reading:
 
 - [Quick Start Guide](quick_start_guide.md)
 - [Style Guide](style_guide.md)
diff --git a/doc/development/testing_guide/end_to_end/style_guide.md b/doc/development/testing_guide/end_to_end/style_guide.md
index 0272e1810f2..52a8116e01c 100644
--- a/doc/development/testing_guide/end_to_end/style_guide.md
+++ b/doc/development/testing_guide/end_to_end/style_guide.md
@@ -63,17 +63,17 @@ We follow a simple formula roughly based on hungarian notation.
   - `_checkbox`
   - `_radio`
   - `_content`
-  
+
 *Note: This list is a work in progress. This list will eventually be the end-all enumeration of all available types.
         I.e., any element that does not end with something in this list is bad form.*
-  
+
 #### Examples
 
 **Good**
 
 ```ruby
 view '...' do
-  element :edit_button 
+  element :edit_button
   element :notes_tab
   element :squash_checkbox
   element :username_field
@@ -84,15 +84,15 @@ end
 **Bad**
 
 ```ruby
-view '...' do  
+view '...' do
   # `_confirmation` should be `_field`. what sort of confirmation? a checkbox confirmation? no real way to disambiguate.
   # an appropriate replacement would be `element :password_confirmation_field`
   element :password_confirmation
 
-  # `clone_options` is too vague. If it's a dropdown menu, it should be `clone_dropdown`. 
+  # `clone_options` is too vague. If it's a dropdown menu, it should be `clone_dropdown`.
   # If it's a checkbox, it should be `clone_checkbox`
   element :clone_options
-  
+
   # how is this url being displayed? is it a textbox? a simple span?
   element :ssh_clone_url
 end
diff --git a/doc/development/testing_guide/frontend_testing.md b/doc/development/testing_guide/frontend_testing.md
index 98df0b5ea7c..bb44cc595e9 100644
--- a/doc/development/testing_guide/frontend_testing.md
+++ b/doc/development/testing_guide/frontend_testing.md
@@ -501,17 +501,17 @@ The following are examples of tests that work for both Karma and Jest:
 it('makes a request', () => {
   const responseBody = getJSONFixture('some/fixture.json'); // loads spec/javascripts/fixtures/some/fixture.json
   axiosMock.onGet(endpoint).reply(200, responseBody);
-  
+
   myButton.click();
-  
+
   // ...
 });
 
 it('uses some HTML element', () => {
   loadFixtures('some/page.html'); // loads spec/javascripts/fixtures/some/page.html and adds it to the DOM
-  
+
   const element = document.getElementById('#my-id');
-  
+
   // ...
 });
 ```