Super-linter is a ready-to-run collection of linters and code analyzers, to help validate and fix your source code.

The goal of super-linter is to help you establish best practices and consistent formatting across multiple programming languages, and ensure developers are adhering to those conventions.

Super-linter analyzes source code files using several tools, and reports the issues that those tools find as console output, and as GitHub Actions status checks. You can also run super-linter outside GitHub Actions.

Super-linter can also help you fix linting and formatting issues.

Super-linter is licensed under an MIT License.

Here are some notable Super-linter features:

• MIT License: Super-linter is licensed under a MIT License.
• Independent project: Super-linter is maintained by a team of independent developers and is not commercially backed by any entity that might influence the course of the project.
• Widely used: Super-linter is the most widely used and forked project of this kind.
• Runs linters in parallel: Since v6, Super-linter parallelizes running all the included linters, leading to scanning massive code repositories in seconds.
• Highly curated set of linters: Avoid including linters that implement overlapping checks, reducing bloat, scanning times, and container image size.
• Run on GitHub Actions or other environments: Super-linter runs on GitHub Actions and other runtime environments, with the only dependency of an OCI-compatible container runtime engine, such as Docker.
• Lean codebase: Super-linter doesn't reinvent the wheel, and builds on top of established tools and standards, such as GNU Parallel.
• Extensive test suite: Super-linter includes an extensive test suite that covers every single linter and analyzer that Super-linter ships.
• Original design: to the best of our knowledge, Super-linter is the first open-source, fully-containerized linting suite. Other projects borrow ideas and design choices from Super-linter (and we're cool with that :).

Super-linter supports the following tools:

More in-depth tutorial available

To run super-linter as a GitHub Action, you do the following:

1. Create a new GitHub Actions workflow in your repository with the following content:

   ---
   name: Lint
   
   on: # yamllint disable-line rule:truthy
     push: null
     pull_request: null
   
   permissions: {}
   
   jobs:
     build:
       name: Lint
       runs-on: ubuntu-latest
   
       permissions:
         contents: read
         packages: read
         # To report GitHub Actions status checks
         statuses: write
   
       steps:
         - name: Checkout code
           uses: actions/checkout@v4
           with:
             # super-linter needs the full git history to get the
             # list of files that changed across commits
             fetch-depth: 0
   
         - name: Super-linter
           uses: super-linter/[email protected] # x-release-please-version
           env:
             # To report GitHub Actions status checks
             GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

2. Commit that file to a new branch.

3. Push the new commit to the remote repository.

4. Create a new pull request to observe the results.

For more information about upgrading super-linter to a new major version, see the upgrade guide.

You can show Super-Linter status with a badge in your repository readme:

Example:

[![Super-Linter](https://github.com/<OWNER>/<REPOSITORY>/actions/workflows/<WORKFLOW_FILE_NAME>/badge.svg)](https://github.com/marketplace/actions/super-linter)

For more information, see Adding a workflow status badge.

Super-Linter provides several variants:

• standard: super-linter/super-linter@[VERSION]: includes all supported linters.

• slim: super-linter/super-linter/slim@[VERSION]: includes all supported linters except:

  • Rustfmt
  • Rust Clippy
  • Azure Resource Manager Template Toolkit (arm-ttk)
  • PSScriptAnalyzer
  • dotnet (.NET) commands and subcommands

You can configure Super-linter using the following environment variables:

The VALIDATE_[LANGUAGE] variables work as follows:

• super-linter runs all supported linters by default.
• If you set any of the VALIDATE_[LANGUAGE] variables to true, super-linter defaults to leaving any unset variable to false (only validate those languages).
• If you set any of the VALIDATE_[LANGUAGE] variables to false, super-linter defaults to leaving any unset variable to true (only exclude those languages).
• If you set any of the VALIDATE_[LANGUAGE] variables to both true and false, super-linter fails reporting an error.

For more information about reusing Super-linter configuration across environments, see Share Environment variables between environments.

All the linters and formatters that Super-linter runs report errors if they detect linting or formatting issues without modifying your source code (check only mode). Check only mode is the default for all linters and formatters that Super-linter runs.

Certain linters and formatters support automatically fixing issues in your code (fix mode). You can enable fix mode for a particular linter or formatter by setting the relevant FIX_<language name> variable to true. To know which linters and formatters support fix mode, refer to the Configure Super-linter section.

Setting a FIX_<language name> variable to true implies setting the corresponding VALIDATE_<language name> to true. Setting a FIX_<language name> variable to true and the corresponding VALIDATE_<language name> to false is a configuration error. Super-linter reports that as a fatal error.

Super-linter supports the following locations to deliver fixes:

• In the current Super-linter workspace, so you can process the changes to your files by yourself. For example:

  • If you're running Super-linter in your CI environment, such as GitHub Actions, you can commit and push changes as part of your workflow.
  • If you're running Super-linter locally, you can commit the changes as you would with any other change in your working directory.

ansible-lint requires that the yaml rule is enabled to for the ansible-lint fix mode to work. The default ansible-lint configuration that Super-linter ships disables the yaml rule because it might not be compatible with yamllint. If you need to enable the ansible-lint fix mode, provide an ansible-lint configuration that doesn't ignore the yaml rule.

When fix mode is enabled, some linters and formatters don't maintain the original file or directory ownership, and use the user that Super-linter uses to run the linter or formatter.

Super-linter provides default configurations for some linters in the TEMPLATES/ directory. You can customize the configuration for the linters that support this by placing your own configuration files in the LINTER_RULES_PATH directory. LINTER_RULES_PATH is relative to the DEFAULT_WORKSPACE directory.

Super-linter supports customizing the name of these configuration files. For more information, refer to Configure super-linter.

For example, you can configure super-linter to load configuration files from the config/lint directory in your repository:

  env:
    LINTER_RULES_PATH: `config/lint`

Some of the linters that super-linter provides can be configured to disable certain rules or checks, and to ignore certain files or part of them.

For more information about how to configure each linter, review their own documentation.

If you need to include or exclude directories from being checked, you can use two environment variables: FILTER_REGEX_INCLUDE and FILTER_REGEX_EXCLUDE.

For example:

• Lint only the src folder: FILTER_REGEX_INCLUDE: .*src/.*
• Do not lint files inside test folder: FILTER_REGEX_EXCLUDE: .*test/.*
• Do not lint JavaScript files inside test folder: FILTER_REGEX_EXCLUDE: .*test/.*.js

Additionally, if you set IGNORE_GENERATED_FILES to true, super-linter ignores any file with @generated string in it, unless the file also has @not-generated marker. For example, super-linter considers a file with the following contents as generated:

#!/bin/sh
echo "@generated"

while considers this file as not generated:

#!/bin/sh
echo "@generated" # @not-generated

Finally, you can set IGNORE_GITIGNORED_FILES to true to ignore a file if Git ignores it too.

You don't need GitHub Actions to run super-linter. It supports several runtime environments.

You can run super-linter outside GitHub Actions. For example, you can run super-linter from a shell:

docker run \
  -e LOG_LEVEL=DEBUG \
  -e RUN_LOCAL=true \
  -v /path/to/local/codebase:/tmp/lint \
  ghcr.io/super-linter/super-linter:latest

For more information, see Run super-linter outside GitHub Actions.

If you need to use your own SSH key to authenticate against private repositories, you can use the SSH_KEY environment variable. The value of that environment variable is expected to be the private key of an SSH keypair that has access to your private repositories.

For example, you can configure this private key as an Encrypted Secret and access it with the secrets parameter from your GitHub Actions workflow:

env:
  SSH_KEY: ${{ secrets.SSH_PRIVATE_KEY }}

If you need to inject a SSL certificate into the trust store, you can use the SSL_CERT_SECRET variable. The value of that variable is expected to be the path to the files that contains a CA that can be used to validate the certificate:

env:
  SSL_CERT_SECRET: ${{ secrets.ROOT_CA }}

Super-linter supports generating several outputs, and also supports exposing the output of individual linters.

Super-linter writes a summary of all the checks:

• If SAVE_SUPER_LINTER_SUMMARY is set to true, Super-linter writes a summary to ${DEFAULT_WORKSPACE}/${SUPER_LINTER_OUTPUT_DIRECTORY_NAME}/${SUPER_LINTER_SUMMARY_FILE_NAME}.
• If ENABLE_GITHUB_ACTIONS_STEP_SUMMARY is set to true, Super-linter writes a GitHub Actions job summary. Setting ENABLE_GITHUB_ACTIONS_STEP_SUMMARY to true, implies setting SAVE_SUPER_LINTER_SUMMARY to true.

The summary is in Markdown format. Super-linter supports the following formats:

• Table (default)

The summary output of previous Super-linter runs is not preserved.

If you set SAVE_SUPER_LINTER_OUTPUT to true, Super-linter saves its output to ${DEFAULT_WORKSPACE}/${SUPER_LINTER_OUTPUT_DIRECTORY_NAME}/super-linter, so you can further process it, if needed.

Most outputs are in JSON format.

The output of previous Super-linter runs is not preserved.

Some linters support configuring the format of their outputs for further processing. To get access to that output, enable it using the respective linter configuration file. If a linter requires a path for the output directory, you can use the value of the ${DEFAULT_WORKSPACE} variable.

If a linter doesn't support setting an arbitrary output path as described in the previous paragraph, but only supports emitting results to standard output or standard error streams, you can enable Super-linter outputs and parse them.

If you would like to help contribute to super-linter, see CONTRIBUTING.