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.

You can configure Super-linter to automatically deliver linting and formatting fixes. For example, you can configure a workflow that automatically commits the fixes, and pushes them to a branch.

To ensure that Super-linter analyzes your codebase as expected, we recommend that you configure your fix mode workflows in addition to your existing Super-linter workflows.

The following example shows a GitHub Actions workflow that uses Super-linter to automatically fix linting and formatting issues, commit changes in the current branch, and push commits to the remote branch tracking the current branch whenever a pull request is created or updated:

---
name: Lint

on: # yamllint disable-line rule:truthy
  push: null
  pull_request: null

permissions:
  contents: read

jobs:
  lint:
    # Super-linter workflow running in check only mode
    # See https://github.com/super-linter/super-linter#get-started

  fix-lint-issues:
    permissions:
      # To write linting fixes
      contents: write
      # To write Super-linter status checks
      statuses: write
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - name: Super-Linter
        uses: super-linter/[email protected] # x-release-please-version
        env:
          GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
          # Set your fix mode variables to true
          FIX_SHELL_SHFMT: true
          FIX_YAML_PRETTIER: true
          # To reuse the same Super-linter configuration that you use in the
          # lint job without duplicating it, see
          # https://github.com/super-linter/super-linter/blob/main/docs/run-linter-locally.md#share-environment-variables-between-environments
      - name: Commit and push linting fixes
        # Run only on:
        # - Pull requests
        # - Not on the default branch
        if: >
          github.event_name == 'pull_request' &&
          github.ref_name != github.event.repository.default_branch
        uses: stefanzweifel/git-auto-commit-action@v5
        with:
          branch: ${{ github.event.pull_request.head.ref || github.head_ref || github.ref }}
          commit_message: "chore: fix linting issues"
          commit_user_name: super-linter
          commit_user_email: [email protected]

This example uses GitHub Actions automatic token authentication that automatically greates a unique GITHUB_TOKEN secret for the workflow. GitHub Actions imposes the following limitations on workflows:

• To avoid accidentally creating recursive workflow runs, the commit that contains linting and formatting fixes doesn't create new workflow runs.
• It restrict edits to GitHub Actions workflows files (in .github/workflows).
• It may fail pushing commits to protected branches.

To work around these limitations, you do the following:

1. Create an authentication token with additional permissions.

2. Grant the authentication token the repo and workflow permissions.

3. Use the authentication token in the actions/checkout step:

   - uses: actions/checkout@v4
     with:
       fetch-depth: 0
       token: ${{ secrets.SUPER_LINTER_TOKEN }}

   This example assumes that you saved the authentication token in a secret called SUPER_LINTER_TOKEN, but you can choose whatever name you prefer for the secret.

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 the src folder in the root of the repository: FILTER_REGEX_INCLUDE: ^src/
• Lint all src folders in the repository: FILTER_REGEX_INCLUDE: (^|/)src/
• Do not lint files inside test folder in the root of the repository: FILTER_REGEX_EXCLUDE: ^test/
• Do not lint files inside all test folders in the repository: FILTER_REGEX_EXCLUDE: (^|/)test/
• Do not lint JavaScript files inside test folder in the root of the repository: FILTER_REGEX_EXCLUDE: ^test/[^/] \.js$
• Do not lint JavaScript files inside test folder in the root of the repository (recursively): FILTER_REGEX_EXCLUDE: ^test/. \.js$
• Do not lint files named gradlew and JavaScript files inside a specific directory: FILTER_REGEX_EXCLUDE: ((^|/)gradlew|^specific/directory/[^/] \.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.

Super-linter generates output reports and logs. To avoid that these outputs end up in your repository, we recommend that you add the following lines to your .gitignore file:

# Super-linter outputs
super-linter-output
super-linter.log

# GitHub Actions leftovers
github_conf

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