Format Markdown

.automation/README.md

@@ -1,23 +1,28 @@
 # .automation
+
 This folder holds automation scripts to help `deploy` and `cleanup` **DockerHub** images of the **Super-Linter**
 
 ## cleanup-docker.sh
+
 This script uses **GitHub Actions** so that when a PR is merged and closed, the **GitHub Action** is triggered.
 It will then search **DockerHub** for the image that was deployed during the development, and remove it.
 
 ## upload-docker.sh
+
 This script uses **GitHub Actions** so that when a push to the repository is committed, it will complete the following:
+
 - Checkout the source code
 - Build the **Docker** container for **Super-Linter** using that source code
 - Upload the container to **DockerHub**
 
 When the script is triggered on master, it will push with the tag:**latest** which is used by all scripting for general availability.
 When the script is triggered in a branch, it will push with the tag:**NameOfBranch** which can be used for:
-- *testing*
-- *troubleshooting*
-- *debugging*
+
+- _testing_
+- _troubleshooting_
+- _debugging_
 - **Note:** The branch name will be reduced to alphanumeric for consistency and uploading
 
 ## test
 
-This folder holds all **Test Cases** to help run the *CI/CT/CD* process for the **Super-Linter**.
+This folder holds all **Test Cases** to help run the _CI/CT/CD_ process for the **Super-Linter**.

.automation/test/README.md

@@ -1,6 +1,8 @@
 # Test Cases
+
 This folder holds `test cases` that are used to validate the sanity of the **Super-Linter**.
 The format:
+
 - Each **Super-Linter** language should have its own folder
   - Folder(s) containing test cases for each language supported
   - Passing test case(s) per language denoted in naming scheme

.automation/test/ansible/README.md

@@ -1,13 +1,19 @@
 # Ansible Test Cases
+
 This folder holds the test cases for **Ansible**.
 
 ## Additional Docs
+
 The folder **ghe-initialize** is pulled from the **GitHub-Demo-Stack** and is a valid **Ansible** role.
 
 ## Good Test Cases
+
 The test cases denoted: `LANGUAGE_good_FILE.EXTENSION` are all valid, and should pass successfully when linted.
+
 - **Note:** They are linted utilizing the default linter rules.
 
 ## Bad Test Cases
+
 The test cases denoted: `LANGUAGE_bad_FILE.EXTENSION` are **NOT** valid, and should trigger errors when linted.
+
 - **Note:** They are linted utilizing the default linter rules.

.automation/test/arm/README.md

@@ -1,13 +1,19 @@
 # ARM Test Cases
+
 This folder holds the test cases for **Azure Resource Manager (ARM)**.
 
 ## Additional Docs
+
 No Additional information is needed for this test case.
 
 ## Good Test Cases
+
 The test cases denoted: `LANGUAGE_good_FILE.EXTENSION` are all valid, and should pass successfully when linted.
+
 - **Note:** They are linted utilizing the default linter rules.
 
 ## Bad Test Cases
+
 The test cases denoted: `LANGUAGE_bad_FILE.EXTENSION` are **NOT** valid, and should trigger errors when linted.
+
 - **Note:** They are linted utilizing the default linter rules.

.automation/test/cfn/README.md

@@ -1,13 +1,19 @@
 # AWS CloudFormation Test Cases
+
 This folder holds the test cases for **CloudFormation**.
 
 ## Additional Docs
+
 No Additional information is needed for this test case.
 
 ## Good Test Cases
+
 The test cases denoted: `LANGUAGE_good_FILE.EXTENSION` are all valid, and should pass successfully when linted.
+
 - **Note:** They are linted utilizing the default linter rules.
 
 ## Bad Test Cases
+
 The test cases denoted: `LANGUAGE_bad_FILE.EXTENSION` are **NOT** valid, and should trigger errors when linted.
+
 - **Note:** They are linted utilizing the default linter rules.

.automation/test/clojure/README.md

@@ -1,13 +1,19 @@
 # Clojure Test Cases
+
 This folder holds the test cases for **Clojure**.
 
 ## Additional Docs
+
 No Additional information is needed for this test case.
 
 ## Good Test Cases
+
 The test cases denoted: `LANGUAGE_good_FILE.EXTENSION` are all valid, and should pass successfully when linted.
+
 - **Note:** They are linted utilizing the default linter rules.
 
 ## Bad Test Cases
+
 The test cases denoted: `LANGUAGE_bad_FILE.EXTENSION` are **NOT** valid, and should trigger errors when linted.
+
 - **Note:** They are linted utilizing the default linter rules.

.automation/test/coffeescript/README.md

@@ -1,13 +1,19 @@
 # Coffeescript Test Cases
+
 This folder holds the test cases for **Coffeescript**.
 
 ## Additional Docs
+
 No Additional information is needed for this test case.
 
 ## Good Test Cases
+
 The test cases denoted: `LANGUAGE_good_FILE.EXTENSION` are all valid, and should pass successfully when linted.
+
 - **Note:** They are linted utilizing the default linter rules.
 
 ## Bad Test Cases
+
 The test cases denoted: `LANGUAGE_bad_FILE.EXTENSION` are **NOT** valid, and should trigger errors when linted.
+
 - **Note:** They are linted utilizing the default linter rules.

.automation/test/css/README.md

@@ -1,13 +1,19 @@
 # CSS Test Cases
+
 This folder holds the test cases for **CSS**.
 
 ## Additional Docs
+
 No Additional information is needed for this test case.
 
 ## Good Test Cases
+
 The test cases denoted: `LANGUAGE_good_FILE.EXTENSION` are all valid, and should pass successfully when linted.
+
 - **Note:** They are linted utilizing the default linter rules.
 
 ## Bad Test Cases
+
 The test cases denoted: `LANGUAGE_bad_FILE.EXTENSION` are **NOT** valid, and should trigger errors when linted.
+
 - **Note:** They are linted utilizing the default linter rules.

.automation/test/dart/README.md

@@ -1,13 +1,19 @@
 # Dart Test Cases
+
 This folder holds the test cases for **Dart**.
 
 ## Additional Docs
+
 No Additional information is needed for this test case.
 
 ## Good Test Cases
+
 The test cases denoted: `LANGUAGE_good_FILE.EXTENSION` are all valid, and should pass successfully when linted.
+
 - **Note:** They are linted utilizing the default linter rules.
 
 ## Bad Test Cases
+
 The test cases denoted: `LANGUAGE_bad_FILE.EXTENSION` are **NOT** valid, and should trigger errors when linted.
+
 - **Note:** They are linted utilizing the default linter rules.

.automation/test/docker/README.md

@@ -1,13 +1,18 @@
 # Docker Test Cases
+
 This folder holds the test cases for **Docker**.
 
 ## Additional Docs
+
 Due to the nature of the naming of files, we have `2` subfolders in this directory.
+
 - `good` is for working, and correct **Dockerfile**(s)
 - `bad` is for invalid, and incorrect **Dockerfile**(s)
 
 ## Good Test Cases
+
 - **Note:** They are linted utilizing the default linter rules.
 
 ## Bad Test Cases
+
 - **Note:** They are linted utilizing the default linter rules.

.automation/test/editorconfig-checker/README.md

@@ -1,13 +1,19 @@
 # EDITORCONFIG_CHECKER Test Cases
+
 This folder holds the test cases for **EDITORCONFIG_CHECKER**.
 
 ## Additional Docs
+
 No Additional information is needed for this test case.
 
 ## Good Test Cases
+
 The test cases denoted: `LANGUAGE_good_FILE.EXTENSION` are all valid, and should pass successfully when linted.
+
 - **Note:** They are linted utilizing the default linter rules.
 
 ## Bad Test Cases
+
 The test cases denoted: `LANGUAGE_bad_FILE.EXTENSION` are **NOT** valid, and should trigger errors when linted.
+
 - **Note:** They are linted utilizing the default linter rules.

.automation/test/env/README.md

@@ -1,13 +1,19 @@
 # ENV Test Cases
+
 This folder holds the test cases for **ENV**.
 
 ## Additional Docs
+
 No Additional information is needed for this test case.
 
 ## Good Test Cases
+
 The test cases denoted: `LANGUAGE_good_FILE.EXTENSION` are all valid, and should pass successfully when linted.
+
 - **Note:** They are linted utilizing the default linter rules.
 
 ## Bad Test Cases
+
 The test cases denoted: `LANGUAGE_bad_FILE.EXTENSION` are **NOT** valid, and should trigger errors when linted.
+
 - **Note:** They are linted utilizing the default linter rules.

.automation/test/golang/README.md

@@ -1,13 +1,19 @@
 # Golang Test Cases
+
 This folder holds the test cases for **Golang**.
 
 ## Additional Docs
+
 No Additional information is needed for this test case.
 
 ## Good Test Cases
+
 The test cases denoted: `LANGUAGE_good_FILE.EXTENSION` are all valid, and should pass successfully when linted.
+
 - **Note:** They are linted utilizing the default linter rules.
 
 ## Bad Test Cases
+
 The test cases denoted: `LANGUAGE_bad_FILE.EXTENSION` are **NOT** valid, and should trigger errors when linted.
+
 - **Note:** They are linted utilizing the default linter rules.

.automation/test/html/README.md

@@ -1,13 +1,19 @@
 # HTML Test Cases
+
 This folder holds the test cases for **HTML**.
 
 ## Additional Docs
+
 No Additional information is needed for this test case.
 
 ## Good Test Cases
+
 The test cases denoted: `LANGUAGE_good_FILE.EXTENSION` are all valid, and should pass successfully when linted.
+
 - **Note:** They are linted utilizing the default linter rules.
 
 ## Bad Test Cases
+
 The test cases denoted: `LANGUAGE_bad_FILE.EXTENSION` are **NOT** valid, and should trigger errors when linted.
+
 - **Note:** They are linted utilizing the default linter rules.

.automation/test/javascript/README.md

@@ -1,13 +1,19 @@
 # Javascript Test Cases
+
 This folder holds the test cases for **Javascript**.
 
 ## Additional Docs
+
 No Additional information is needed for this test case.
 
 ## Good Test Cases
+
 The test cases denoted: `LANGUAGE_good_FILE.EXTENSION` are all valid, and should pass successfully when linted.
+
 - **Note:** They are linted utilizing the default linter rules.
 
 ## Bad Test Cases
+
 The test cases denoted: `LANGUAGE_bad_FILE.EXTENSION` are **NOT** valid, and should trigger errors when linted.
+
 - **Note:** They are linted utilizing the default linter rules.

.automation/test/json/README.md

@@ -1,13 +1,19 @@
 # Json Test Cases
+
 This folder holds the test cases for **Json**.
 
 ## Additional Docs
+
 No Additional information is needed for this test case.
 
 ## Good Test Cases
+
 The test cases denoted: `LANGUAGE_good_FILE.EXTENSION` are all valid, and should pass successfully when linted.
+
 - **Note:** They are linted utilizing the default linter rules.
 
 ## Bad Test Cases
+
 The test cases denoted: `LANGUAGE_bad_FILE.EXTENSION` are **NOT** valid, and should trigger errors when linted.
+
 - **Note:** They are linted utilizing the default linter rules.

.automation/test/kotlin/README.md

@@ -1,13 +1,19 @@
 # Kotlin Test Cases
+
 This folder holds the test cases for **Kotlin**.
 
 ## Additional Docs
+
 No Additional information is needed for this test case.
 
 ## Good Test Cases
+
 The test cases denoted: `LANGUAGE_good_FILE.EXTENSION` are all valid, and should pass successfully when linted.
+
 - **Note:** They are linted utilizing the default linter rules.
 
 ## Bad Test Cases
+
 The test cases denoted: `LANGUAGE_bad_FILE.EXTENSION` are **NOT** valid, and should trigger errors when linted.
+
 - **Note:** They are linted utilizing the default linter rules.

.automation/test/markdown/README.md

@@ -1,13 +1,19 @@
 # Markdown Test Cases
+
 This folder holds the test cases for **Markdown**.
 
 ## Additional Docs
+
 No Additional information is needed for this test case.
 
 ## Good Test Cases
+
 The test cases denoted: `LANGUAGE_good_FILE.EXTENSION` are all valid, and should pass successfully when linted.
+
 - **Note:** They are linted utilizing the default linter rules.
 
 ## Bad Test Cases
+
 The test cases denoted: `LANGUAGE_bad_FILE.EXTENSION` are **NOT** valid, and should trigger errors when linted.
+
 - **Note:** They are linted utilizing the default linter rules.

.automation/test/openapi/README.md

@@ -1,14 +1,20 @@
 # OpenAPI Test Cases
+
 This folder holds the test cases for **OpenAPI**.
 
 ## Additional Docs
+
 The `_bad_` tests are valid `.yml`/`.json` but invalid OpenAPI specs.
 The test extensions used are `.ymlopenapi`/`.jsonopenapi` instead of `.yml`/`.json`. This is to prevent the [YAML] and [JSON] tests from picking them up.
 
 ## Good Test Cases
+
 The test cases denoted: `LANGUAGE_good_FILE.EXTENSION` are all valid, and should pass successfully when linted.
+
 - **Note:** They are linted utilizing the default linter rules.
 
 ## Bad Test Cases
+
 The test cases denoted: `LANGUAGE_bad_FILE.EXTENSION` are **NOT** valid, and should trigger errors when linted.
+
 - **Note:** They are linted utilizing the default linter rules.

.automation/test/perl/README.md

@@ -1,13 +1,19 @@
 # Perl Test Cases
+
 This folder holds the test cases for **Perl**.
 
 ## Additional Docs
+
 No Additional information is needed for this test case.
 
 ## Good Test Cases
+
 The test cases denoted: `LANGUAGE_good_FILE.EXTENSION` are all valid, and should pass successfully when linted.
+
 - **Note:** They are linted utilizing the default linter rules.
 
 ## Bad Test Cases
+
 The test cases denoted: `LANGUAGE_bad_FILE.EXTENSION` are **NOT** valid, and should trigger errors when linted.
+
 - **Note:** They are linted utilizing the default linter rules.

.automation/test/php/README.md

@@ -1,13 +1,19 @@
 # PHP Test Cases
+
 This folder holds the test cases for **PHP**.
 
 ## Additional Docs
+
 No Additional information is needed for this test case.
 
 ## Good Test Cases
+
 The test cases denoted: `LANGUAGE_good_FILE.EXTENSION` are all valid, and should pass successfully when linted.
+
 - **Note:** They are linted utilizing the default linter rules.
 
 ## Bad Test Cases
+
 The test cases denoted: `LANGUAGE_bad_FILE.EXTENSION` are **NOT** valid, and should trigger errors when linted.
+
 - **Note:** They are linted utilizing the default linter rules.

.automation/test/powershell/README.md

@@ -1,13 +1,19 @@
 # PowerShell Test Cases
+
 This folder holds the test cases for **PowerShell**.
 
 ## Additional Docs
+
 No Additional information is needed for this test case.
 
 ## Good Test Cases
+
 The test cases denoted: `LANGUAGE_good_FILE.EXTENSION` are all valid, and should pass successfully when linted.
+
 - **Note:** They are linted utilizing the default linter rules.
 
 ## Bad Test Cases
+
 The test cases denoted: `LANGUAGE_bad_FILE.EXTENSION` are **NOT** valid, and should trigger errors when linted.
+
 - **Note:** They are linted utilizing the default linter rules.

.automation/test/python/README.md

@@ -1,13 +1,19 @@
 # Python Test Cases
+
 This folder holds the test cases for **Python**.
 
 ## Additional Docs
+
 No Additional information is needed for this test case.
 
 ## Good Test Cases
+
 The test cases denoted: `LANGUAGE_good_FILE.EXTENSION` are all valid, and should pass successfully when linted.
+
 - **Note:** They are linted utilizing the default linter rules.
 
 ## Bad Test Cases
+
 The test cases denoted: `LANGUAGE_bad_FILE.EXTENSION` are **NOT** valid, and should trigger errors when linted.
+
 - **Note:** They are linted utilizing the default linter rules.

.automation/test/raku/README.md

@@ -1,13 +1,19 @@
 # Raku Test Cases
+
 This folder holds the test cases for **Raku**.
 
 ## Additional Docs
+
 No Additional information is needed for this test case.
 
 ## Good Test Cases
+
 The test cases denoted: `LANGUAGE_good_FILE.EXTENSION` are all valid, and should pass successfully when linted.
+
 - **Note:** They are linted utilizing the default linter rules.
 
 ## Bad Test Cases
+
 The test cases denoted: `LANGUAGE_bad_FILE.EXTENSION` are **NOT** valid, and should trigger errors when linted.
+
 - **Note:** They are linted utilizing the default linter rules.

.automation/test/ruby/README.md

@@ -1,13 +1,19 @@
 # Ruby Test Cases
+
 This folder holds the test cases for **Ruby**.
 
 ## Additional Docs
+
 No Additional information is needed for this test case.
 
 ## Good Test Cases
+
 The test cases denoted: `LANGUAGE_good_FILE.EXTENSION` are all valid, and should pass successfully when linted.
+
 - **Note:** They are linted utilizing the default linter rules.
 
 ## Bad Test Cases
+
 The test cases denoted: `LANGUAGE_bad_FILE.EXTENSION` are **NOT** valid, and should trigger errors when linted.
+
 - **Note:** They are linted utilizing the default linter rules.

.automation/test/shell/README.md

@@ -1,13 +1,19 @@
 # Bash Test Cases
+
 This folder holds the test cases for **Bash**.
 
 ## Additional Docs
+
 No Additional information is needed for this test case.
 
 ## Good Test Cases
+
 The test cases denoted: `LANGUAGE_good_FILE.EXTENSION` are all valid, and should pass successfully when linted.
+
 - **Note:** They are linted utilizing the default linter rules.
 
 ## Bad Test Cases
+
 The test cases denoted: `LANGUAGE_bad_FILE.EXTENSION` are **NOT** valid, and should trigger errors when linted.
+
 - **Note:** They are linted utilizing the default linter rules.

.automation/test/typescript/README.md

@@ -1,13 +1,19 @@
 # Typescript Test Cases
+
 This folder holds the test cases for **Typescript**.
 
 ## Additional Docs
+
 No Additional information is needed for this test case.
 
 ## Good Test Cases
+
 The test cases denoted: `LANGUAGE_good_FILE.EXTENSION` are all valid, and should pass successfully when linted.
+
 - **Note:** They are linted utilizing the default linter rules.
 
 ## Bad Test Cases
+
 The test cases denoted: `LANGUAGE_bad_FILE.EXTENSION` are **NOT** valid, and should trigger errors when linted.
+
 - **Note:** They are linted utilizing the default linter rules.

.automation/test/xml/README.md

@@ -1,13 +1,19 @@
 # XML Test Cases
+
 This folder holds the test cases for **XML**.
 
 ## Additional Docs
+
 No Additional information is needed for this test case.
 
 ## Good Test Cases
+
 The test cases denoted: `LANGUAGE_good_FILE.EXTENSION` are all valid, and should pass successfully when linted.
+
 - **Note:** They are linted utilizing the default linter rules.
 
 ## Bad Test Cases
+
 The test cases denoted: `LANGUAGE_bad_FILE.EXTENSION` are **NOT** valid, and should trigger errors when linted.
+
 - **Note:** They are linted utilizing the default linter rules.

.automation/test/yml/README.md

@@ -1,13 +1,19 @@
 # Yml Test Cases
+
 This folder holds the test cases for **Yml**.
 
 ## Additional Docs
+
 No Additional information is needed for this test case.
 
 ## Good Test Cases
+
 The test cases denoted: `LANGUAGE_good_FILE.EXTENSION` are all valid, and should pass successfully when linted.
+
 - **Note:** They are linted utilizing the default linter rules.
 
 ## Bad Test Cases
+
 The test cases denoted: `LANGUAGE_bad_FILE.EXTENSION` are **NOT** valid, and should trigger errors when linted.
+
 - **Note:** They are linted utilizing the default linter rules.

.devcontainer/README.md

@@ -1,10 +1,10 @@
 # Devcontainer
+
 This file specifies to vscode how to run the container
 
 For format details, see [documentation](https://aka.ms/vscode-remote/devcontainer.json) or this file's [README](https://github.com/microsoft/vscode-dev-containers/tree/v0.123.0/containers/docker-existing-dockerfile)
 
-
 context: Sets the run context to one level up instead of the .devcontainer folder.
 dockerFile: Update the 'dockerFile' property if you aren't using the standard 'Dockerfile' filename.
-settings: Set *default* container specific settings.json values on container create.
+settings: Set _default_ container specific settings.json values on container create.
 extensions: Add the IDs of extensions you want installed when the container is created.

.github/CONTRIBUTING.md

@@ -1,11 +1,14 @@
 # Contributing
+
 :wave: Hi there!
 We're thrilled that you'd like to contribute to this project. Your help is essential for keeping it great.
 
 ## Submitting a pull request
+
 [Pull Requests][pulls] are used for adding new playbooks, roles, and documents to the repository, or editing the existing ones.
 
 **With write access**
+
 1. Clone the repository (only if you have write access)
 1. Create a new branch: `git checkout -b my-branch-name`
 1. Make your change
@@ -13,6 +16,7 @@ We're thrilled that you'd like to contribute to this project. Your help is essen
 1. Pat yourself on the back and wait for your pull request to be reviewed and merged.
 
 **Without write access**
+
 1. [Fork][fork] and clone the repository
 1. Create a new branch: `git checkout -b my-branch-name`
 1. Make your change
@@ -30,16 +34,20 @@ Draft pull requests are also welcome to get feedback early on, or if there is so
 - Open a pull request
 
 ### CI/CT/CD
-The **Super-Linter** has *CI/CT/CD* configured utilizing **GitHub** Actions.
+
+The **Super-Linter** has _CI/CT/CD_ configured utilizing **GitHub** Actions.
+
 - When a branch is created and code is pushed, a **GitHub** Action is triggered for building the new **Docker** container with the new codebase
-- The **Docker** container is then ran against the *test cases* to validate all code sanity
+- The **Docker** container is then ran against the _test cases_ to validate all code sanity
   - `.automation/test` contains all test cases for each language that should be validated
 - These **GitHub** Actions utilize the Checks API and Protected Branches to help follow the SDLC
 - When the Pull Request is merged to master, the **Super-Linter** **Docker** container is then updated and deployed with the new codebase
   - **Note:** The branch's **Docker** container is also removed from **DockerHub** to cleanup after itself
 
 ## Releasing
+
 If you are the current maintainer of this action:
+
 1. If a major version number change: Update `README.md` and the wiki to reflect new version number in the example workflow file sections
 2. Draft [Releases](https://help.github.com/en/github/administering-a-repository/managing-releases-in-a-repository) are created automatically. They just need to be checked over for accuracy before making it official.
 3. Ensure you check the box for [publishing to the marketplace](https://help.github.com/en/actions/creating-actions/publishing-actions-in-github-marketplace#publishing-an-action)
@@ -48,6 +56,7 @@ If you are the current maintainer of this action:
 6. Look for approval from [CODEOWNERS](https://help.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners)
 
 ## Resources
+
 - [How to Contribute to Open Source](https://opensource.guide/how-to-contribute/)
 - [Using Pull Requests](https://help.github.com/articles/about-pull-requests/)
 - [GitHub Help](https://help.github.com)

.github/ISSUE_TEMPLATE/bug_report.md

@@ -12,6 +12,7 @@ A clear and concise description of what the bug is.
 
 **To Reproduce**
 Steps to reproduce the behavior:
+
 1. Go to '...'
 2. Click on '....'
 3. Scroll down to '....'

.github/pull_request-template.md

@@ -1,16 +1,20 @@
 <!-- Please ensure your PR title is brief and descriptive for a good changelog entry -->
 <!-- Link to issue if there is one -->
 <!-- markdownlint-disable -->
+
 Fixes #
+
 <!-- markdownlint-restore -->
 
 <!-- Describe what the changes are -->
+
 ## Proposed Changes
 
--
--
+## -
+
 -
 
 ## Readiness Checklist
+
 - [ ] Label as `breaking` if this is a large fundamental change
 - [ ] Label as either `automation`, `bug`, `documentation`, `enhancement`, `infrastructure`, or `performance`

README.md

@@ -1,8 +1,10 @@
 # Super-Linter
+
 This repository is for the **GitHub Action** to run a **Super-Linter**.
 It is a simple combination of various linters, written in `bash`, to help validate your source code.
 
 The end goal of this tool:
+
 - Prevent broken code from being uploaded to the default branch (Usually `master`)
 - Help establish coding best practices across multiple languages
 - Build guidelines for code layout and format
@@ -10,15 +12,24 @@ The end goal of this tool:
 
 ## Table of Contents
 
-- [How it works](#how-it-works)
-- [Supported linters](#supported-linters)
-- [Usage](#how-to-use)
+- [Super-Linter](#super-linter)
+  - [Table of Contents](#table-of-contents)
+  - [How it Works](#how-it-works)
+  - [Supported Linters](#supported-linters)
+  - [How to use](#how-to-use)
+    - [Example connecting GitHub Action Workflow](#example-connecting-github-action-workflow)
   - [Environment variables](#environment-variables)
-- [Disable rules](#disabling-rules)
+    - [Template rules files](#template-rules-files)
+  - [Disabling rules](#disabling-rules)
   - [Docker Hub](#docker-hub)
   - [Run Super-Linter outside GitHub Actions](#run-super-linter-outside-github-actions)
+    - [Local (troubleshooting/debugging/enhancements)](#local-troubleshootingdebuggingenhancements)
+    - [Azure](#azure)
+    - [GitLab](#gitlab)
+    - [Visual Studio Code](#visual-studio-code)
   - [Limitations](#limitations)
-- [Contributing](#how-to-contribute)
+  - [How to contribute](#how-to-contribute)
+    - [License](#license)
 
 ## How it Works
 
@@ -30,8 +41,8 @@ The design of the **Super-Linter** is currently to allow linting to occur in **G
 
 Developers on **GitHub** can call the **GitHub Action** to lint their code base with the following list of linters:
 
-| *Language*       | *Linter*                                                                 |
-| ---              | ---                                                                      |
+| _Language_                       | _Linter_                                                                             |
+| -------------------------------- | ------------------------------------------------------------------------------------ |
 | **Ansible**                      | [ansible-lint](https://github.com/ansible/ansible-lint)                              |
 | **Azure Resource Manager (ARM)** | [arm-ttk](https://github.com/azure/arm-ttk)                                          |
 | **AWS CloudFormation templates** | [cfn-lint](https://github.com/aws-cloudformation/cfn-python-lint/)                   |
@@ -63,19 +74,22 @@ Developers on **GitHub** can call the **GitHub Action** to lint their code base
 | **YAML**                         | [YamlLint](https://github.com/adrienverge/yamllint)                                  |
 
 ## How to use
+
 More in-depth [tutorial](https://www.youtube.com/watch?v=EDAmFKO4Zt0&t=118s) available
 
 To use this **GitHub** Action you will need to complete the following:
+
 1. Create a new file in your repository called `.github/workflows/linter.yml`
 2. Copy the example workflow from below into that new file, no extra configuration required
 3. Commit that file to a new branch
 4. Open up a pull request and observe the action working
-5. Enjoy your more *stable*, and *cleaner* code base
+5. Enjoy your more _stable_, and _cleaner_ code base
 6. Check out the [Wiki](https://github.com/github/super-linter/wiki) for customization options
 
-**NOTE:** You will need the *Environment* variable `GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}` set in your workflow file to be able to use the multiple status API returns. There is no need to set the **GitHub** Secret, it only needs to be passed.
+**NOTE:** You will need the _Environment_ variable `GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}` set in your workflow file to be able to use the multiple status API returns. There is no need to set the **GitHub** Secret, it only needs to be passed.
 
 ### Example connecting GitHub Action Workflow
+
 In your repository you should have a `.github/workflows` folder with **GitHub** Action similar to below:
 
 - `.github/workflows/linter.yml`
@@ -135,17 +149,16 @@ jobs:
           VALIDATE_ALL_CODEBASE: false
           DEFAULT_BRANCH: master
           GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
-
-...
 ```
 
 **NOTE:**
-Using the line:`uses: docker://github/super-linter:v3` will pull the image down from **DockerHub** and run the **GitHub Super-Linter**.   Using the line: `uses: github/super-linter@v3` will build and compile the **GitHub Super-Linter** at build time. *This can be far more costly in time...*
+Using the line:`uses: docker://github/super-linter:v3` will pull the image down from **DockerHub** and run the **GitHub Super-Linter**. Using the line: `uses: github/super-linter@v3` will build and compile the **GitHub Super-Linter** at build time. _This can be far more costly in time..._
 
 ## Environment variables
+
 The super-linter allows you to pass the following `ENV` variables to be able to trigger different functionality.
 
-*Note:* All the `VALIDATE_[LANGUAGE]` variables behave in a specific way.
+_Note:_ All the `VALIDATE_[LANGUAGE]` variables behave in a specific way.
 If none of them are passed, then they all default to true.
 However if any one of the variables are set, we default to leaving any unset variable to false.
 This means that if you run the linter "out of the box", all languages will be checked.
@@ -153,7 +166,7 @@ But if you wish to select specific linters, we give you full control to choose w
 and won't run anything unexpected.
 
 | **ENV VAR**                      | **Default Value**     | **Notes**                                                                                                                                                                        |
-| --- | --- | --- |
+| -------------------------------- | --------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
 | **VALIDATE_ALL_CODEBASE**        | `true`                | Will parse the entire repository and find all files to validate across all types. **NOTE:** When set to `false`, only **new** or **edited** files will be parsed for validation. |
 | **DEFAULT_BRANCH**               | `master`              | The name of the repository default branch.                                                                                                                                       |
 | **LINTER_RULES_PATH**            | `.github/linters`     | Directory for all linter configuration rules.                                                                                                                                    |
@@ -203,44 +216,57 @@ and won't run anything unexpected.
 | **MULTI_STATUS**                 | `true`                | A status API is made for each language that is linted to make visual parsing easier.                                                                                             |
 
 ### Template rules files
-You can use the **GitHub** **Super-Linter** *with* or *without* your own personal rules sets. This allows for greater flexibility for each individual code base. The Template rules all try to follow the standards we believe should be enabled at the basic level.
+
+You can use the **GitHub** **Super-Linter** _with_ or _without_ your own personal rules sets. This allows for greater flexibility for each individual code base. The Template rules all try to follow the standards we believe should be enabled at the basic level.
+
 - Copy **any** or **all** template rules files from `TEMPLATES/` into your repository in the location: `.github/linters/` of your repository
   - If your repository does not have rules files, they will fall back to defaults in [this repository's `TEMPLATE` folder](https://github.com/github/super-linter/tree/master/TEMPLATES)
 
 ## Disabling rules
-If you need to disable certain *rules* and *functionality*, you can view [Disable Rules](https://github.com/github/super-linter/blob/master/docs/disabling-linters.md)
+
+If you need to disable certain _rules_ and _functionality_, you can view [Disable Rules](https://github.com/github/super-linter/blob/master/docs/disabling-linters.md)
 
 ## Docker Hub
+
 The **Docker** container that is built from this repository is located at `https://hub.docker.com/r/github/super-linter`
 
 ## Run Super-Linter outside GitHub Actions
+
 ### Local (troubleshooting/debugging/enhancements)
+
 If you find that you need to run super-linter locally, you can follow the documentation at [Running super-linter locally](https://github.com/github/super-linter/blob/master/docs/run-linter-locally.md)
 
 Check out the [note](#how-it-works) in **How it Works** to understand more about the **Super-Linter** linting locally versus via continuous integration.
 
 ### Azure
+
 Check out this [article](http://blog.tyang.org/2020/06/27/use-github-super-linter-in-azure-pipelines/)
 
 ### GitLab
+
 Check out this [snippet](https://gitlab.com/snippets/1988376)
 
 ### Visual Studio Code
+
 You can checkout this repository using [Container Remote Development](https://code.visualstudio.com/docs/remote/containers), and debug the linter using the `Test Linter` task.
 ![Example](https://user-images.githubusercontent.com/15258962/85165778-2d2ce700-b21b-11ea-803e-3f6709d8e609.gif)
 
 We will also support [Github Codespaces](https://github.com/features/codespaces/) once it becomes available
 
 ## Limitations
+
 Below are a list of the known limitations for the **GitHub Super-Linter**:
+
 - Due to being completely packaged at run time, you will not be able to update dependencies or change versions of the enclosed linters and binaries
 - Additional details from `package.json` are not read by the **GitHub Super-Linter**
 - Downloading additional codebases as dependencies from private repositories will fail due to lack of permissions
 
 ## How to contribute
+
 If you would like to help contribute to this **GitHub** Action, please see [CONTRIBUTING](https://github.com/github/super-linter/blob/master/.github/CONTRIBUTING.md)
 
---------------------------------------------------------------------------------
+---
 
 ### License
+
 - [MIT License](https://github.com/github/super-linter/blob/master/LICENSE)

docs/disabling-linters.md

@@ -1,4 +1,5 @@
 # Disabling linters and Rules
+
 Linters can often require additional configuration to ensure they work with your codebase and your team's coding style, to avoid flagging false-positives. The **GitHub Super-Linter** has set up some default configurations for each linter which should work reasonably well with common code bases, but many of the linters can be configured to disable certain rules or configure the rules to ignore certain pieces of codes.
 
 To run with your own configuration for a linter, copy the relevant [`TEMPLATE` configuration file for the linter you are using from this repo](https://github.com/github/super-linter/tree/master/TEMPLATES) into the `.github/linters` folder in your own repository, and then edit it to modify, disable - or even add - rules and configuration to suit how you want your code checked.
@@ -7,11 +8,12 @@ How the changes are made differ for each linter, and also how much the **Github
 
 Where a configuration file exists in your repo, it will be used in preference to the default one in the **GitHub Super-Linter** `TEMPLATES` directory (not in addition to it), and where one doesn't exist the `TEMPLATES` version will be used. So you should copy the complete configuration file you require to change from the `TEMPLATES` directory and not just the lines of config you want to change.
 
-It is possible to have custom configurations for some linters, and continue to use the default from `TEMPLATES` directory for others, so if you use `Python` and `JavaScript` and only need to tweak the `Python` rules, then you only need to have a custom configuration for *pylint* and continue to use the default `TEMPLATE` from the main repo for *ESLint*, for example.
+It is possible to have custom configurations for some linters, and continue to use the default from `TEMPLATES` directory for others, so if you use `Python` and `JavaScript` and only need to tweak the `Python` rules, then you only need to have a custom configuration for _pylint_ and continue to use the default `TEMPLATE` from the main repo for _ESLint_, for example.
 
 For some linters it is also possible to override rules on a case by case level with directives in your code. Where this is possible we try to note how to do this in the specific linter sections below, but the official linter documentation will likely give more detail on this.
 
 ## Table of Linters
+
 - [Ruby](#ruby)
 - [Shell](#shell)
 - [Ansible](#ansible)
@@ -42,23 +44,27 @@ For some linters it is also possible to override rules on a case by case level w
 
 <!-- toc -->
 
---------------------------------------------------------------------------------
+---
 
 ## Ruby
+
 - [RuboCop](https://github.com/rubocop-hq/rubocop)
 
 ### RuboCop Config file
+
 - `.github/linters/.ruby-lint.yml`
 - You can pass multiple rules and overwrite default rules
 - File should be located at: `.github/linters/.ruby-lint.yml`
 - **Note:** We use the Default **GitHub** Rule set from [RuboCop-GitHub](https://github.com/github/rubocop-github)
 
 ### RuboCop disable single line
+
 ```ruby
 method(argument) # rubocop:disable SomeRule, SomeOtherRule
 ```
 
 ### RuboCop disable code block
+
 ```ruby
 # rubocop:disable
 This is a long line
@@ -67,6 +73,7 @@ var="this is some other stuff"
 ```
 
 ### RuboCop disable entire file
+
 If you need to ignore an entire file, you can update the `.github/linters/.ruby-lint.yml` to ignore certain files and locations
 
 ```yml
@@ -85,27 +92,31 @@ AllCops:
   TargetRubyVersion: 2.5.1
   EnabledByDefault: true
   Exclude:
-    - 'db/**/*'
-    - 'config/**/*'
-    - 'script/**/*'
-    - 'bin/{rails,rake}'
+    - "db/**/*"
+    - "config/**/*"
+    - "script/**/*"
+    - "bin/{rails,rake}"
     - !ruby/regexp /old_and_unused\.rb$/
 ```
 
---------------------------------------------------------------------------------
+---
 
 ## Shell
+
 - [Shellcheck](https://github.com/koalaman/shellcheck)
 
 ### Shellcheck Config file
-- There is no top level *configuration file* available at this time
+
+- There is no top level _configuration file_ available at this time
 
 ### Shellcheck disable single line
+
 ```bash
 echo "Terrible stuff" # shellcheck disable=SC2059,SC2086
 ```
 
 ### Shellcheck disable code block
+
 ```bash
 # shellcheck disable=SC2059,SC2086
 echo "some hot garbage"
@@ -113,7 +124,9 @@ echo "More garbage code"
 ```
 
 ### Shellcheck disable entire file
+
 - **Note:** The disable must be on the second line of the code right after the shebang
+
 ```bash
 #!/bin/sh
 # shellcheck disable=SC2059,SC1084
@@ -122,23 +135,28 @@ echo "stuff"
 moreThings()
 ```
 
---------------------------------------------------------------------------------
+---
 
 ## Ansible
+
 - [ansible-lint](https://github.com/ansible/ansible-lint)
 
 ### Ansible-lint Config file
+
 - `.github/linters/.ansible-lint.yml`
 - You can pass multiple rules and overwrite default rules
 - File should be located at: `.github/linters/.ansible-lint.yml`
 
 ### Ansible-lint disable single line
+
 ```yml
 - name: this would typically fire GitHasVersionRule 401 and BecomeUserWithoutBecomeRule 501
   become_user: alice # noqa 401 501
   git: src=/path/to/git/repo dest=checkout
 ```
+
 ### Ansible-lint disable code block
+
 ```yml
 - name: this would typically fire GitHasVersionRule 401
   git: src=/path/to/git/repo dest=checkout
@@ -147,28 +165,34 @@ moreThings()
 ```
 
 ### Ansible-lint disable entire file
+
 ```yml
 - name: this would typically fire GitHasVersionRule 401
   git: src=/path/to/git/repo dest=checkout
   tags:
     - skip_ansible_lint
 ```
---------------------------------------------------------------------------------
+
+---
 
 ## YAML
+
 - [YamlLint](https://github.com/adrienverge/yamllint)
 
 ### Yamllint Config file
+
 - `.github/linters/.yaml-lint.yml`
 - You can pass multiple rules and overwrite default rules
 - File should be located at: `.github/linters/.yaml-lint.yml`
 
 ### Yamllint disable single line
+
 ```yml
 This line is waaaaaaaaaay too long # yamllint disable-line
 ```
 
 ### Yamllint disable code block
+
 ```yml
 # yamllint disable rule:colons
 - Key: value
@@ -178,7 +202,9 @@ This line is waaaaaaaaaay too long  # yamllint disable-line
 ```
 
 ### Yamllint disable entire file
+
 If you need to ignore an entire file, you can update the `.github/linters/.yaml-lint.yml` to ignore certain files and locations
+
 ```yml
 # For all rules
 ignore: |
@@ -197,22 +223,26 @@ rules:
       /ascii-art/*
 ```
 
---------------------------------------------------------------------------------
+---
 
 ## Python3
+
 - [pylint](https://www.pylint.org/)
 
 ### Pylint Config file
+
 - `.github/linters/.python-lint`
 - You can pass multiple rules and overwrite default rules
 - File should be located at: `.github/linters/.python-lint`
 
 ### Pylint disable single line
+
 ```python
 global VAR # pylint: disable=global-statement
 ```
 
 ### Pylint disable code block
+
 ```python
 """pylint option block-disable"""
 
@@ -243,6 +273,7 @@ class Foo(object):
 ```
 
 ### Pylint disable entire file
+
 ```python
 #!/bin/python3
 # pylint: skip-file
@@ -250,21 +281,26 @@ class Foo(object):
 var = "terrible code down here..."
 ```
 
---------------------------------------------------------------------------------
+---
 
 ## AWS CloudFormation templates
+
 - [cfn-lint](https://github.com/aws-cloudformation/cfn-python-lint/)
 
 ### cfn-lint Config file
+
 - `.github/linters/.cfnlintrc.yml`
 - You can pass multiple rules and overwrite default rules
 - File should be located at: `.github/linters/.cfnlintrc.yml`
 
 ### cfn-lint disable single line
+
 - There is currently **No** way to disable rules inline of the file(s)
 
 ### cfn-lint disable code block
+
 You can disable both [template](https://github.com/aws-cloudformation/cfn-python-lint/#template-based-metadata) or [resource](https://github.com/aws-cloudformation/cfn-python-lint/#resource-based-metadata) via [metadata](https://github.com/aws-cloudformation/cfn-python-lint/#metadata):
+
 ```yaml
 Resources:
   myInstance:
@@ -280,142 +316,189 @@ Resources:
 ```
 
 ### cfn-lint disable entire file
+
 If you need to ignore an entire file, you can update the `.github/linters/.cfnlintrc.yml` to ignore certain files and locations
+
 ```yaml
 ignore_templates:
   - codebuild.yaml
 ```
 
---------------------------------------------------------------------------------
+---
 
 ## JSON
+
 - [jsonlint](https://github.com/zaach/jsonlint)
 
 ### JsonLint Config file
-- There is no top level *configuration file* available at this time
+
+- There is no top level _configuration file_ available at this time
 
 ### JsonLint disable single line
+
 - There is currently **No** way to disable rules inline of the file(s)
 
 ### JsonLint disable code block
+
 - There is currently **No** way to disable rules inline of the file(s)
 
 ### JsonLint disable entire file
+
 - There is currently **No** way to disable rules inline of the file(s)
 
---------------------------------------------------------------------------------
+---
 
 ## Markdown
+
 - [markdownlint-cli](https://github.com/igorshubovych/markdownlint-cli#readme)
 - [markdownlint rule documentation](https://github.com/DavidAnson/markdownlint/blob/main/doc/Rules.md)
 - [markdownlint inline comment syntax](https://github.com/DavidAnson/markdownlint#configuration)
 
 ### markdownlint Config file
+
 - You can pass multiple rules and overwrite default rules
 - File should be located at: `.github/linters/.markdown-lint.yml`
 
 ### markdownlint disable single line
+
 ```markdown
 ## Here is some document
+
 Here is some random data
+
 <!-- markdownlint-disable -->
+
 any violation you want
+
 <!-- markdownlint-restore -->
+
 Here is more data
 ```
+
 ### markdownlint disable code block
+
 ```markdown
 ## Here is some document
+
 Here is some random data
+
 <!-- markdownlint-disable -->
+
 any violations you want
+
 <!-- markdownlint-restore -->
+
 Here is more data
 ```
 
 ### markdownlint disable entire file
-- You can encapsulate the entire file with the *code block format* to disable an entire file from being parsed
 
---------------------------------------------------------------------------------
+- You can encapsulate the entire file with the _code block format_ to disable an entire file from being parsed
+
+---
 
 ## Perl
+
 - [perl](https://pkgs.alpinelinux.org/package/edge/main/x86/perl)
 
 ### Perl Config file
-- There is no top level *configuration file* available at this time
+
+- There is no top level _configuration file_ available at this time
 
 ### Perl disable single line
+
 - There is currently **No** way to disable rules inline of the file(s)
 
 ### Perl disable code block
+
 - There is currently **No** way to disable rules inline of the file(s)
 
 ### Perl disable entire file
+
 - There is currently **No** way to disable rules inline of the file(s)
 
---------------------------------------------------------------------------------
+---
 
 ## Raku
+
 - [raku](https://raku.org)
 
 ### Raku Config file
-- There is no top level *configuration file* available at this time
+
+- There is no top level _configuration file_ available at this time
 
 ### Raku disable single line
+
 - There is currently **No** way to disable rules inline of the file(s)
 
 ### Raku disable code block
+
 - There is currently **No** way to disable rules inline of the file(s)
 
 ### Raku disable entire file
+
 - There is currently **No** way to disable rules inline of the file(s)
 
---------------------------------------------------------------------------------
---------------------------------------------------------------------------------
+---
+
+---
 
 ## PHP
+
 - [PHP](https://www.php.net/)
 
 ### PHP Config file
-- There is no top level *configuration file* available at this time
+
+- There is no top level _configuration file_ available at this time
 
 ### PHP disable single line
+
 - There is currently **No** way to disable rules inline of the file(s)
 
 ### PHP disable code block
+
 - There is currently **No** way to disable rules inline of the file(s)
 
 ### PHP disable entire file
+
 - There is currently **No** way to disable rules inline of the file(s)
 
---------------------------------------------------------------------------------
+---
 
 ## XML
+
 - [XML](http://xmlsoft.org/)
 
 ### LibXML Config file
-- There is no top level *configuration file* available at this time
+
+- There is no top level _configuration file_ available at this time
 
 ### LibXML disable single line
+
 - There is currently **No** way to disable rules inline of the file(s)
 
 ### LibXML disable code block
+
 - There is currently **No** way to disable rules inline of the file(s)
 
 ### LibXML disable entire file
+
 - There is currently **No** way to disable rules inline of the file(s)
 
---------------------------------------------------------------------------------
+---
 
 ## Coffeescript
+
 - [coffeelint](https://coffeelint.github.io/)
 
 ### coffeelint Config file
+
 - `.github/linters/.coffee-lint.yml`
 - You can pass multiple rules and overwrite default rules
 - File should be located at: `.github/linters/.coffee.yml`
 
 ### coffeelint disable single line
+
 ```Coffeescript
 # coffeelint: disable=max_line_length
 foo = "some/huge/line/string/with/embed/#{values}.that/surpasses/the/max/column/width"
@@ -423,6 +506,7 @@ foo = "some/huge/line/string/with/embed/#{values}.that/surpasses/the/max/column/
 ```
 
 ### coffeelint disable code block
+
 ```Coffeescript
 # coffeelint: disable
 foo = "some/huge/line/string/with/embed/#{values}.that/surpasses/the/max/column/width"
@@ -433,181 +517,223 @@ taz = "some/huge/line/string/with/embed/#{values}.that/surpasses/the/max/column/
 ```
 
 ### coffeelint disable entire file
-- You can encapsulate the entire file with the *code block format* to disable an entire file from being parsed
 
---------------------------------------------------------------------------------
+- You can encapsulate the entire file with the _code block format_ to disable an entire file from being parsed
+
+---
 
 ## Javascript eslint
+
 - [eslint](https://eslint.org/)
 
 ### Javascript eslint Config file
+
 - `.github/linters/.eslintrc.yml`
 - You can pass multiple rules and overwrite default rules
 - File should be located at: `.github/linters/.eslintrc.yml`
 
 ### Javascript eslint disable single line
+
 ```javascript
 var thing = new Thing(); // eslint-disable-line no-use-before-define
 thing.sayHello();
 
 function Thing() {
-
-     this.sayHello = function() { console.log("hello"); };
-
+  this.sayHello = function () {
+    console.log("hello");
+  };
 }
 ```
 
 ### Javascript eslint disable code block
+
 ```javascript
 /*eslint-disable */
 
 //suppress all warnings between comments
-alert('foo')
+alert("foo");
 
 /*eslint-enable */
 ```
+
 ### Javascript eslint disable entire file
+
 - Place at the top of the file:
+
 ```javascript
 /* eslint-disable */
 ```
 
---------------------------------------------------------------------------------
+---
 
 ## Javascript standard
+
 - [standard js](https://standardjs.com/)
 
 ### Javascript standard Config file
-- There is no top level *configuration file* available at this time
+
+- There is no top level _configuration file_ available at this time
 
 ### Javascript standard disable single line
+
 - There is currently **No** way to disable rules inline of the file(s)
 
 ### Javascript standard disable code block
+
 - There is currently **No** way to disable rules inline of the file(s)
 
 ### Javascript standard disable entire file
+
 - There is currently **No** way to disable rules inline of the file(s)
 
---------------------------------------------------------------------------------
+---
 
 ## Typescript eslint
+
 - [eslint](https://eslint.org/)
 
 ### Typescript eslint Config file
+
 - `.github/linters/.eslintrc.yml`
 - You can pass multiple rules and overwrite default rules
 - File should be located at: `.github/linters/.eslintrc.yml`
 
 ### Typescript eslint disable single line
+
 ```typescript
 var thing = new Thing(); // eslint-disable-line no-use-before-define
 thing.sayHello();
 
 function Thing() {
-
-     this.sayHello = function() { console.log("hello"); };
-
+  this.sayHello = function () {
+    console.log("hello");
+  };
 }
 ```
 
 ### Typescript eslint disable code block
+
 ```typescript
 /*eslint-disable */
 
 //suppress all warnings between comments
-alert('foo')
+alert("foo");
 
 /*eslint-enable */
 ```
+
 ### Typescript eslint disable entire file
+
 ```typescript
 /* eslint-disable */
 ```
 
---------------------------------------------------------------------------------
+---
 
 ## Typescript standard
+
 - [standardjs](https://standardjs.com/)
 
 ### Typescript standard Config file
-- There is no top level *configuration file* available at this time
+
+- There is no top level _configuration file_ available at this time
 
 ### Typescript standard disable single line
+
 - There is currently **No** way to disable rules inline of the file(s)
 
 ### Typescript standard disable code block
+
 - There is currently **No** way to disable rules inline of the file(s)
 
 ### Typescript standard disable entire file
+
 - There is currently **No** way to disable rules inline of the file(s)
 
---------------------------------------------------------------------------------
+---
 
 ## Golang
+
 - [golangci-lint](https://github.com/golangci/golangci-lint)
 
 ### golangci-lint standard Config file
+
 - `.github/linters/.golangci.yml`
 - You can pass multiple rules and overwrite default rules
 - File should be located at: `.github/linters/.golangci.yml`
 
 ### golangci-lint disable single line
+
 - There is currently **No** way to disable rules inline of the file(s)
 
 ### golangci-lint disable code block
+
 - There is currently **No** way to disable rules inline of the file(s)
 
 ### golangci-lint disable entire file
+
 - There is currently **No** way to disable rules inline of the file(s)
 
---------------------------------------------------------------------------------
+---
 
 ## Dockerfile
+
 - [dockerfilelint](https://github.com/replicatedhq/dockerfilelint.git)
 
 ### Dockerfilelint standard Config file
+
 - `.github/linters/.dockerfilelintrc`
 - You can pass multiple rules and overwrite default rules
 - File should be located at: `.github/linters/.dockerfilelintrc`
 
 ### Dockerfilelint disable single line
+
 - There is currently **No** way to disable rules inline of the file(s)
 
 ### Dockerfilelint disable code block
+
 - There is currently **No** way to disable rules inline of the file(s)
 
 ### Dockerfilelint disable entire file
+
 - There is currently **No** way to disable rules inline of the file(s)
 
---------------------------------------------------------------------------------
+---
 
 ## Terraform
+
 - [tflint](https://github.com/terraform-linters/tflint)
 
 ### tflint standard Config file
+
 - `.github/linters/.tflint.hcl`
 - You can pass multiple rules and overwrite default rules
 - File should be located at: `.github/linters/.tflint.hcl`
 
 ### tflint disable single line
+
 - There is currently **No** way to disable rules inline of the file(s)
 
 ### tflint disable code block
+
 - There is currently **No** way to disable rules inline of the file(s)
 
 ### tflint disable entire file
+
 - There is currently **No** way to disable rules inline of the file(s)
 
---------------------------------------------------------------------------------
+---
 
 ## CSS
+
 - [stylelint](https://stylelint.io/)
 
 ### stylelint standard Config file
+
 - `.github/linters/.stylelintrc.json`
 
 ### stylelint disable single line
+
 ```css
 #id {
   /* stylelint-disable-next-line declaration-no-important */
@@ -616,14 +742,18 @@ alert('foo')
 ```
 
 ### stylelint disable code block
+
 ```css
 /* stylelint-disable */
-a {}
+a {
+}
 /* stylelint-enable */
 ```
 
 ### stylelint disable entire file
+
 - You can disable entire files with the `ignoreFiles` property in `.stylelintrc.json`
+
 ```json
 {
   "ignoreFiles": [
@@ -633,39 +763,48 @@ a {}
 }
 ```
 
---------------------------------------------------------------------------------
+---
 
 ## ENV
+
 - [dotenv-linter](https://github.com/dotenv-linter/dotenv-linter)
 
 ### dotenv-linter Config file
-- There is no top level *configuration file* available at this time
+
+- There is no top level _configuration file_ available at this time
 
 ### dotenv-linter disable single line
+
 ```env
 # Comment line will be ignored
 ```
 
 ### dotenv-linter disable code block
+
 - There is currently **No** way to disable rules inline of the file(s)
 
 ### dotenv-linter disable entire file
+
 - There is currently **No** way to disable rules inline of the file(s)
 
---------------------------------------------------------------------------------
+---
 
 ## Kotlin
+
 - [ktlint](https://github.com/pinterest/ktlint)
 
 ### ktlint Config file
-- There is no top level *configuration file* available at this time
+
+- There is no top level _configuration file_ available at this time
 
 ### ktlint disable single line
+
 ```kotlin
 import package.* // ktlint-disable no-wildcard-imports
 ```
 
 ### ktlint disable code block
+
 ```kotlin
 /* ktlint-disable no-wildcard-imports */
 import package.a.*
@@ -674,59 +813,72 @@ import package.b.*
 ```
 
 ### ktlint disable entire file
+
 - There is currently **No** way to disable rules inline of the file(s)
 
---------------------------------------------------------------------------------
+---
 
 ## Dart
+
 - [dartanalyzer](https://dart.dev/tools/dartanalyzer)
 
 ### dartanalyzer standard Config file
+
 - `.github/linters/.dart-lint.yml`
 - You can pass multiple rules and overwrite default rules
 - File should be located at: `.github/linters/.dart-lint.yml`
 
 ### dartanalyzer disable single line
+
 ```dart
 int x = ''; // ignore: invalid_assignment
 ```
 
 ### dartanalyzer disable code block
+
 - You can make [rule exceptions](https://dart.dev/guides/language/analysis-options#excluding-code-from-analysis) for the entire file.
+
 ```dart
 // ignore_for_file: unused_import, unused_local_variable
 ```
 
 ### dartanalyzer disable entire file
+
 - You can disable entire files with the `analyzer.exclude` property in `.dart-lint.yml`
+
 ```dart
 analyzer:
   exclude:
     - file
 ```
 
---------------------------------------------------------------------------------
+---
 
 ## OpenAPI
+
 - [spectral](https://github.com/stoplightio/spectral)
 
 ### OpenAPI Config file
+
 - `.github/linters/.openapirc.yml`
 - You can add, extend, and disable rules
 - Documentation at [Spectral Custom Rulesets](https://stoplight.io/p/docs/gh/stoplightio/spectral/docs/guides/4-custom-rulesets.md)
 - File should be located at: `.github/linters/.openapirc.yml`
 
 ### OpenAPI disable single line
+
 - There is currently **No** way to disable rules inline of the file(s)
 
 ### OpenAPI disable code block
+
 - There is currently **No** way to disable rules inline of the file(s)
 
 ### OpenAPI disable entire file
+
 - There is currently **No** way to disable rules inline of the file(s)
 - However, you can make [rule exceptions](https://stoplight.io/p/docs/gh/stoplightio/spectral/docs/guides/6-exceptions.md?srn=gh/stoplightio/spectral/docs/guides/6-exceptions.md) in the config for individual file(s).
 
---------------------------------------------------------------------------------
+---
 
 ## Protocol Buffers
 
@@ -776,20 +928,25 @@ lint:
 ```
 
 ## Clojure
+
 - [clj-kondo](https://github.com/borkdude/clj-kondo)
 - Since clj-kondo approaches static analysis in a very Clojure way, it is advised to read the [configuration docs](https://github.com/borkdude/clj-kondo/blob/master/doc/config.md)
 
 ### clj-kondo standard Config file
+
 - `.github/linters/.clj-kondo/config.edn`
 
 ### clj-kondo disable single line
+
 - There is currently **No** way to disable rules in a single line
 
 ### clj-kondo disable code block
+
 - There is currently **No** way to disable rules in a code block
 
 ### clj-kondo disable entire file
-```clojure
+
+````clojure
 {:output {:exclude-files ["path/to/file"]}}
 
 ## EDITORCONFIG-CHECKER
@@ -805,37 +962,44 @@ lint:
 -
 ```js
 <LINE> // editorconfig-checker-disable-line
-```
+````
 
 ### editorconfig-checker disable code block
+
 - There is currently **No** way to disable rules inline of the file(s)
 
 ### editorconfig-checker disable entire file
+
 -
+
 ```js
 // editorconfig-checker-disable-file
 ```
+
 - You can disable entire files with the `Exclude` property in `.ecrc`
+
 ```json
 {
-  "Exclude": [
-    "path/to/file",
-    "^regular\\/expression\\.ext$"
-   ]
+  "Exclude": ["path/to/file", "^regular\\/expression\\.ext$"]
 }
 ```
 
 ## HTML
+
 - [htmlhint](https://htmlhint.com/)
 
 ### htmlhint standard Config file
+
 - `.github/linters/.htmlhintrc`
 
 ### htmlhint disable single line
+
 - There is currently **No** way to disable rules in a single line
 
 ### htmlhint disable code block
+
 - There is currently **No** way to disable rules in a code block
 
 ### htmlhint disable entire file
+
 - There is currently **No** way to disable rules in an entire file

docs/run-linter-locally.md

@@ -1,5 +1,7 @@
 # Run Super-Linter locally to test your branch of code
+
 If you want to test locally against the **Super-Linter** to test your branch of code, you will need to complete the following:
+
 - Clone your testing source code to your local environment
 - Install Docker to your local environment
 - Pull the container down
@@ -7,15 +9,19 @@ If you want to test locally against the **Super-Linter** to test your branch of
 - Debug/Troubleshoot
 
 ## Install Docker to your local machine
+
 You can follow the link below on how to install and configure **Docker** on your local machine
+
 - [Docker Install Documentation](https://docs.docker.com/install/)
 
 ## Download the latest Super-Linter Docker container
+
 - Pull the latest **Docker** container down from **DockerHub**
   - `docker pull github/super-linter:latest`
     Once the container has been downloaded to your local environment, you can then begin the process, or running the container against your codebase.
 
 ## Run the container Locally
+
 - You can run the container locally with the following **Base** flags to run your code:
   - `docker run -e RUN_LOCAL=true -v /path/to/local/codebase:/tmp/lint github/super-linter`
     - To run against a single file you can use: `docker run -e RUN_LOCAL=true -v /path/to/local/codebase/file:/tmp/lint/file github/super-linter`
@@ -24,14 +30,18 @@ Once the container has been downloaded to your local environment, you can then b
   - **NOTE:** The flag:`RUN_LOCAL` will set: `VALIDATE_ALL_CODEBASE` to true. This means it will scan **all** the files in the directory you have mapped. If you want to only validate a subset of your codebase, map a folder with only the files you wish to have linted
 
 ### Flags for running Locally
+
 You can add as many **Additional** flags as needed, documented in [README.md](../README.md#Environment-variables)
 
 ## Troubleshooting
 
 ### Run container and gain access to the command line
+
 If you need to run the container locally and gain access to its command line, you can run the following command:
+
 - `docker run -it --entrypoint /bin/bash github/super-linter`
 - This will drop you in the command line of the docker container for any testing or troubleshooting that may be needed.
 
 ### Found issues
-If you find a *bug* or *issue*, please open a **GitHub** issue at: `https://github.com/github/super-linter/issues`
+
+If you find a _bug_ or _issue_, please open a **GitHub** issue at: `https://github.com/github/super-linter/issues`

lib/README.md

@@ -1,10 +1,13 @@
 # Super-Linter Library
 
 ## Main script
+
 The file `linter.sh` is the main script that is called for the process and loads all other scripts as functions.
 
 ## Functions
+
 The additional files in the folder are functions to help streamline the main build process and allow for easier maintenance.
+
 - `possum.sh`
   - Official mascot of the **Super-Linter**
 - `buildFileList.sh`