The super-linter finds issues and reports them to the console output. Fixes are suggested in the console output but not automatically fixed, and a status check will show up as failed on the pull request.
The design of the **Super-Linter** is currently to allow linting to occur in **GitHub Actions** as a part of continuous integration occurring on pull requests as the commits get pushed. It works best when commits are being pushed early and often to a branch with an open or draft pull request. There is some desire to move this closer to local development for faster feedback on linting errors but this is not yet supported.
**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.
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...*
| **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 |
| **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. |
| **VALIDATE_ANSIBLE** | `true` | Flag to enable or disable the linting process of the Ansible language. |
| **VALIDATE_ARM** | `true` | Flag to enable or disable the linting process of the ARM language. |
| **VALIDATE_BASH** | `true` | Flag to enable or disable the linting process of the Bash language. |
| **VALIDATE_CLOJURE** | `true` | Flag to enable or disable the linting process of the Clojure language. |
| **VALIDATE_CLOUDFORMATION** | `true` | Flag to enable or disable the linting process of the AWS Cloud Formation language. |
| **VALIDATE_COFFEE** | `true` | Flag to enable or disable the linting process of the Coffeescript language . |
| **VALIDATE_CSS** | `true` | Flag to enable or disable the linting process of the CSS language. |
| **VALIDATE_DART** | `true` | Flag to enable or disable the linting process of the Dart language. |
| **VALIDATE_DOCKER** | `true` | Flag to enable or disable the linting process of the Docker language. |
| **VALIDATE_EDITORCONFIG** | `true` | Flag to enable or disable the linting process with the editorconfig. |
| **VALIDATE_ENV** | `true` | Flag to enable or disable the linting process of the ENV language. |
| **VALIDATE_GO** | `true` | Flag to enable or disable the linting process of the Golang language. |
| **VALIDATE_HTML** | `true` | Flag to enable or disable the linting process of the HTML language. |
| **VALIDATE_JAVASCRIPT_ES** | `true` | Flag to enable or disable the linting process of the Javascript language. (Utilizing: eslint) |
| **VALIDATE_JAVASCRIPT_STANDARD** | `true` | Flag to enable or disable the linting process of the Javascript language. (Utilizing: standard) |
| **VALIDATE_JSON** | `true` | Flag to enable or disable the linting process of the JSON language. |
| **VALIDATE_JSX** | `true` | Flag to enable or disable the linting process for jsx files (Utilizing: eslint) |
| **VALIDATE_KOTLIN** | `true` | Flag to enable or disable the linting process of the Kotlin language. |
| **VALIDATE_MD** | `true` | Flag to enable or disable the linting process of the Markdown language. |
| **VALIDATE_OPENAPI** | `true` | Flag to enable or disable the linting process of the OpenAPI language. |
| **VALIDATE_PERL** | `true` | Flag to enable or disable the linting process of the Perl language. |
| **VALIDATE_PHP** | `true` | Flag to enable or disable the linting process of the PHP language. |
| **VALIDATE_PROTOBUF** | `true` | Flag to enable or disable the linting process of the Protobuf language. |
| **VALIDATE_PYTHON** | `true` | Flag to enable or disable the linting process of the Python language. |
| **VALIDATE_POWERSHELL** | `true` | Flag to enable or disable the linting process of the Powershell language. |
| **VALIDATE_RAKU** | `true` | Flag to enable or disable the linting process of the Raku language. |
| **VALIDATE_RUBY** | `true` | Flag to enable or disable the linting process of the Ruby language. |
| **VALIDATE_STATES** | `true` | Flag to enable or disable the linting process for AWS States Language. |
| **VALIDATE_TERRAFORM** | `true` | Flag to enable or disable the linting process of the Terraform language. |
| **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 Typescript language. (Utilizing: eslint) |
| **VALIDATE_TYPESCRIPT_STANDARD** | `true` | Flag to enable or disable the linting process of the Typescript language. (Utilizing: standard) |
| **VALIDATE_XML** | `true` | Flag to enable or disable the linting process of the XML language. |
| **VALIDATE_YAML** | `true` |Flag to enable or disable the linting process of the YAML language. |
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)
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 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.
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.
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)