Format Markdown

This commit is contained in:
Eric Nemchik 2020-07-21 12:08:05 -05:00
parent a23aeef139
commit 1d91e2604f
38 changed files with 591 additions and 206 deletions

View file

@ -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**.

View file

@ -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

View file

@ -1,13 +1,19 @@
# Ansible Test Cases
This folder holds the test cases for **Ansible**.
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.

View file

@ -1,13 +1,19 @@
# ARM Test Cases
This folder holds the test cases for **Azure Resource Manager (ARM)**.
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.

View file

@ -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.

View file

@ -1,13 +1,19 @@
# Clojure Test Cases
This folder holds the test cases for **Clojure**.
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.

View file

@ -1,13 +1,19 @@
# Coffeescript Test Cases
This folder holds the test cases for **Coffeescript**.
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.

View file

@ -1,13 +1,19 @@
# CSS Test Cases
This folder holds the test cases for **CSS**.
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.

View file

@ -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.

View file

@ -1,13 +1,18 @@
# Docker Test Cases
This folder holds the test cases for **Docker**.
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.

View file

@ -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.

View file

@ -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.

View file

@ -1,13 +1,19 @@
# Golang Test Cases
This folder holds the test cases for **Golang**.
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.

View file

@ -1,13 +1,19 @@
# HTML Test Cases
This folder holds the test cases for **HTML**.
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.
- **Note:** They are linted utilizing the default linter rules.

View file

@ -1,13 +1,19 @@
# Javascript Test Cases
This folder holds the test cases for **Javascript**.
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.

View file

@ -1,13 +1,19 @@
# Json Test Cases
This folder holds the test cases for **Json**.
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.

View file

@ -1,13 +1,19 @@
# Kotlin Test Cases
This folder holds the test cases for **Kotlin**.
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.

View file

@ -1,13 +1,19 @@
# Markdown Test Cases
This folder holds the test cases for **Markdown**.
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.

View file

@ -1,14 +1,20 @@
# OpenAPI Test Cases
This folder holds the test cases for **OpenAPI**.
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.

View file

@ -1,13 +1,19 @@
# Perl Test Cases
This folder holds the test cases for **Perl**.
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.

View file

@ -1,13 +1,19 @@
# PHP Test Cases
This folder holds the test cases for **PHP**.
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.

View file

@ -1,13 +1,19 @@
# PowerShell Test Cases
This folder holds the test cases for **PowerShell**.
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.

View file

@ -1,13 +1,19 @@
# Python Test Cases
This folder holds the test cases for **Python**.
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.

View file

@ -1,13 +1,19 @@
# Raku Test Cases
This folder holds the test cases for **Raku**.
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.

View file

@ -1,13 +1,19 @@
# Ruby Test Cases
This folder holds the test cases for **Ruby**.
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.

View file

@ -1,13 +1,19 @@
# Bash Test Cases
This folder holds the test cases for **Bash**.
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.

View file

@ -1,13 +1,19 @@
# Typescript Test Cases
This folder holds the test cases for **Typescript**.
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.

View file

@ -1,13 +1,19 @@
# XML Test Cases
This folder holds the test cases for **XML**.
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.

View file

@ -1,13 +1,19 @@
# Yml Test Cases
This folder holds the test cases for **Yml**.
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.

View file

@ -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.
extensions: Add the IDs of extensions you want installed when the container is created.
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.

View file

@ -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)

View file

@ -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 '....'

View file

@ -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`

222
README.md
View file

@ -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)
- [Environment variables](#environment-variables)
- [Disable rules](#disabling-rules)
- [Docker Hub](#docker-hub)
- [Run Super-Linter outside GitHub Actions](#run-super-linter-outside-github-actions)
- [Limitations](#limitations)
- [Contributing](#how-to-contribute)
- [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)
- [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)
- [How to contribute](#how-to-contribute)
- [License](#license)
## How it Works
@ -30,52 +41,55 @@ 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* |
| --- | --- |
| **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/) |
| **CSS** | [stylelint](https://stylelint.io/) |
| **Clojure** | [clj-kondo](https://github.com/borkdude/clj-kondo) |
| **CoffeeScript** | [coffeelint](https://coffeelint.github.io/) |
| **Dart** | [dartanalyzer](https://dart.dev/guides/language/analysis-options) |
| **Dockerfile** | [dockerfilelint](https://github.com/replicatedhq/dockerfilelint.git) |
| **EDITORCONFIG** | [editorconfig-checker](https://github.com/editorconfig-checker/editorconfig-checker) |
| **ENV** | [dotenv-linter](https://github.com/dotenv-linter/dotenv-linter) |
| **Golang** | [golangci-lint](https://github.com/golangci/golangci-lint) |
| **HTMLHint** | [HTMLHint](https://github.com/htmlhint/HTMLHint) |
| **JavaScript** | [eslint](https://eslint.org/) [standard js](https://standardjs.com/) |
| **JSON** | [jsonlint](https://github.com/zaach/jsonlint) |
| **Kotlin** | [ktlint](https://github.com/pinterest/ktlint) |
| **Markdown** | [markdownlint](https://github.com/igorshubovych/markdownlint-cli#readme) |
| **OpenAPI** | [spectral](https://github.com/stoplightio/spectral) |
| **Perl** | [perl](https://pkgs.alpinelinux.org/package/edge/main/x86/perl) |
| **PHP** | [PHP](https://www.php.net/) |
| **PowerShell** | [PSScriptAnalyzer](https://github.com/PowerShell/Psscriptanalyzer) |
| **Protocol Buffers** | [protolint](https://github.com/yoheimuta/protolint) |
| **Python3** | [pylint](https://www.pylint.org/) |
| **Raku** | [raku](https://raku.org) |
| **Ruby** | [RuboCop](https://github.com/rubocop-hq/rubocop) |
| **Shell** | [Shellcheck](https://github.com/koalaman/shellcheck) |
| **Terraform** | [tflint](https://github.com/terraform-linters/tflint) |
| **TypeScript** | [eslint](https://eslint.org/) [standard js](https://standardjs.com/) |
| **XML** | [LibXML](http://xmlsoft.org/) |
| **YAML** | [YamlLint](https://github.com/adrienverge/yamllint) |
| _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/) |
| **CSS** | [stylelint](https://stylelint.io/) |
| **Clojure** | [clj-kondo](https://github.com/borkdude/clj-kondo) |
| **CoffeeScript** | [coffeelint](https://coffeelint.github.io/) |
| **Dart** | [dartanalyzer](https://dart.dev/guides/language/analysis-options) |
| **Dockerfile** | [dockerfilelint](https://github.com/replicatedhq/dockerfilelint.git) |
| **EDITORCONFIG** | [editorconfig-checker](https://github.com/editorconfig-checker/editorconfig-checker) |
| **ENV** | [dotenv-linter](https://github.com/dotenv-linter/dotenv-linter) |
| **Golang** | [golangci-lint](https://github.com/golangci/golangci-lint) |
| **HTMLHint** | [HTMLHint](https://github.com/htmlhint/HTMLHint) |
| **JavaScript** | [eslint](https://eslint.org/) [standard js](https://standardjs.com/) |
| **JSON** | [jsonlint](https://github.com/zaach/jsonlint) |
| **Kotlin** | [ktlint](https://github.com/pinterest/ktlint) |
| **Markdown** | [markdownlint](https://github.com/igorshubovych/markdownlint-cli#readme) |
| **OpenAPI** | [spectral](https://github.com/stoplightio/spectral) |
| **Perl** | [perl](https://pkgs.alpinelinux.org/package/edge/main/x86/perl) |
| **PHP** | [PHP](https://www.php.net/) |
| **PowerShell** | [PSScriptAnalyzer](https://github.com/PowerShell/Psscriptanalyzer) |
| **Protocol Buffers** | [protolint](https://github.com/yoheimuta/protolint) |
| **Python3** | [pylint](https://www.pylint.org/) |
| **Raku** | [raku](https://raku.org) |
| **Ruby** | [RuboCop](https://github.com/rubocop-hq/rubocop) |
| **Shell** | [Shellcheck](https://github.com/koalaman/shellcheck) |
| **Terraform** | [tflint](https://github.com/terraform-linters/tflint) |
| **TypeScript** | [eslint](https://eslint.org/) [standard js](https://standardjs.com/) |
| **XML** | [LibXML](http://xmlsoft.org/) |
| **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,112 +149,124 @@ 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.
But if you wish to select specific linters, we give you full control to choose which linters are run,
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. |
| **VALIDATE_YAML** | `true` |Flag to enable or disable the linting process of the language. |
| **VALIDATE_JSON** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_XML** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_MD** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_BASH** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_PERL** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_RAKU** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_PHP** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_PYTHON** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_RUBY** | `true` | Flag to enable or disable the linting process of the language. |
| **RUBY_CONFIG_FILE** | `.ruby-lint.yml` | Filename for [rubocop configuration](https://docs.rubocop.org/rubocop/configuration.html) (ex: `.ruby-lint.yml`, `.rubocop.yml`)|
| **VALIDATE_COFFEE** | `true` | Flag to enable or disable the linting process of the language . |
| **VALIDATE_ANSIBLE** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_JAVASCRIPT_ES** | `true` | Flag to enable or disable the linting process of the language. (Utilizing: eslint) |
| **JAVASCRIPT_ES_CONFIG_FILE** | `.eslintrc.yml` | Filename for [eslint configuration](https://eslint.org/docs/user-guide/configuring#configuration-file-formats) (ex: `.eslintrc.yml`, `.eslintrc.json`)|
| **VALIDATE_JAVASCRIPT_STANDARD** | `true` | Flag to enable or disable the linting process of the language. (Utilizing: standard) |
| **VALIDATE_JSX** | `true` | Flag to enable or disable the linting process for jsx files (Utilizing: eslint) |
| **VALIDATE_TSX** | `true` | Flag to enable or disable the linting process for tsx files (Utilizing: eslint) |
| **VALIDATE_TYPESCRIPT_ES** | `true` | Flag to enable or disable the linting process of the language. (Utilizing: eslint) |
| **TYPESCRIPT_ES_CONFIG_FILE** | `.eslintrc.yml` | Filename for [eslint configuration](https://eslint.org/docs/user-guide/configuring#configuration-file-formats) (ex: `.eslintrc.yml`, `.eslintrc.json`)|
| **VALIDATE_TYPESCRIPT_STANDARD** | `true` | Flag to enable or disable the linting process of the language. (Utilizing: standard) |
| **VALIDATE_DOCKER** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_GO** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_POWERSHELL** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_ARM** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_TERRAFORM** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_CSS** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_ENV** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_CLOJURE** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_HTML** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_KOTLIN** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_DART** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_OPENAPI** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_CLOUDFORMATION** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_PROTOBUF** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_EDITORCONFIG** | `true` | Flag to enable or disable the linting process with the editorconfig. |
| **ANSIBLE_DIRECTORY** | `/ansible` | Flag to set the root directory for Ansible file location(s). |
| **ACTIONS_RUNNER_DEBUG** | `false` | Flag to enable additional information about the linter, versions, and additional output. |
| **DISABLE_ERRORS** | `false` | Flag to have the linter complete with exit code 0 even if errors were detected. |
| **DEFAULT_WORKSPACE** | `/tmp/lint` | The location containing files to lint if you are running locally. |
| **OUTPUT_FORMAT** | `none` | The report format to be generated, besides the stdout one. Output format of tap is currently using v13 of the specification. Supported formats: tap |
| **OUTPUT_FOLDER** | `super-linter.report` | The location where the output reporting will be generated to. Output folder must not previously exist. |
| **OUTPUT_DETAILS** | `simpler` | What level of details to be reported. Supported formats: simpler or detailed. |
| **MULTI_STATUS** | `true` | A status API is made for each language that is linted to make visual parsing easier. |
| **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. |
| **VALIDATE_YAML** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_JSON** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_XML** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_MD** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_BASH** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_PERL** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_RAKU** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_PHP** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_PYTHON** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_RUBY** | `true` | Flag to enable or disable the linting process of the language. |
| **RUBY_CONFIG_FILE** | `.ruby-lint.yml` | Filename for [rubocop configuration](https://docs.rubocop.org/rubocop/configuration.html) (ex: `.ruby-lint.yml`, `.rubocop.yml`) |
| **VALIDATE_COFFEE** | `true` | Flag to enable or disable the linting process of the language . |
| **VALIDATE_ANSIBLE** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_JAVASCRIPT_ES** | `true` | Flag to enable or disable the linting process of the language. (Utilizing: eslint) |
| **JAVASCRIPT_ES_CONFIG_FILE** | `.eslintrc.yml` | Filename for [eslint configuration](https://eslint.org/docs/user-guide/configuring#configuration-file-formats) (ex: `.eslintrc.yml`, `.eslintrc.json`) |
| **VALIDATE_JAVASCRIPT_STANDARD** | `true` | Flag to enable or disable the linting process of the language. (Utilizing: standard) |
| **VALIDATE_JSX** | `true` | Flag to enable or disable the linting process for jsx files (Utilizing: eslint) |
| **VALIDATE_TSX** | `true` | Flag to enable or disable the linting process for tsx files (Utilizing: eslint) |
| **VALIDATE_TYPESCRIPT_ES** | `true` | Flag to enable or disable the linting process of the language. (Utilizing: eslint) |
| **TYPESCRIPT_ES_CONFIG_FILE** | `.eslintrc.yml` | Filename for [eslint configuration](https://eslint.org/docs/user-guide/configuring#configuration-file-formats) (ex: `.eslintrc.yml`, `.eslintrc.json`) |
| **VALIDATE_TYPESCRIPT_STANDARD** | `true` | Flag to enable or disable the linting process of the language. (Utilizing: standard) |
| **VALIDATE_DOCKER** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_GO** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_POWERSHELL** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_ARM** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_TERRAFORM** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_CSS** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_ENV** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_CLOJURE** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_HTML** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_KOTLIN** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_DART** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_OPENAPI** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_CLOUDFORMATION** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_PROTOBUF** | `true` | Flag to enable or disable the linting process of the language. |
| **VALIDATE_EDITORCONFIG** | `true` | Flag to enable or disable the linting process with the editorconfig. |
| **ANSIBLE_DIRECTORY** | `/ansible` | Flag to set the root directory for Ansible file location(s). |
| **ACTIONS_RUNNER_DEBUG** | `false` | Flag to enable additional information about the linter, versions, and additional output. |
| **DISABLE_ERRORS** | `false` | Flag to have the linter complete with exit code 0 even if errors were detected. |
| **DEFAULT_WORKSPACE** | `/tmp/lint` | The location containing files to lint if you are running locally. |
| **OUTPUT_FORMAT** | `none` | The report format to be generated, besides the stdout one. Output format of tap is currently using v13 of the specification. Supported formats: tap |
| **OUTPUT_FOLDER** | `super-linter.report` | The location where the output reporting will be generated to. Output folder must not previously exist. |
| **OUTPUT_DETAILS** | `simpler` | What level of details to be reported. Supported formats: simpler or detailed. |
| **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)

View file

@ -1,6 +1,6 @@
# TEMPLATES
The files in this folder are template rules for the linters that will run against your code base. If you chose to copy these to your local repository in the directory: `.github/` they will be used at runtime. If they are not present, they will be used by default in the linter run.
The files in this folder are template rules for the linters that will run against your code base. If you chose to copy these to your local repository in the directory: `.github/` they will be used at runtime. If they are not present, they will be used by default in the linter run.
The file(s) will be parsed at run time on the local branch to load all rules needed to run the **Super-Linter** **GitHub** Action.
The file(s) will be parsed at run time on the local branch to load all rules needed to run the **Super-Linter** **GitHub** Action.
The **GitHub** Action will inform the user via the **Checks API** on the status and success of the process.

View file

@ -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,63 +135,76 @@ 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
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
tags:
- skip_ansible_lint
- skip_ansible_lint
```
### 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
- 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
This line is waaaaaaaaaay too long # yamllint disable-line
```
### Yamllint disable code block
```yml
# yamllint disable rule:colons
- Key : value
dolor : sit,
foo : bar
- Key: value
dolor: sit,
foo: bar
# yamllint enable
```
### 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:
@ -273,149 +309,196 @@ Resources:
cfn-lint:
config:
ignore_checks:
- E3030
- E3030
Properties:
InstanceType: nt.x4superlarge
ImageId: ami-abc1234
```
### 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
- 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,56 +742,69 @@ 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": [
"styles/ignored/wildcards/*.css",
"styles/ignored/specific-file.css"
]
]
}
```
--------------------------------------------------------------------------------
---
## 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

View file

@ -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.
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`

View file

@ -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`