super-linter/super-linter

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 :).

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

For a guide on how to set up your development environment and contribute to Super-linter, see the development guide.

Super-linter supports the following tools:

Super-linter records the installed version of each linter and formatter in /action/linterVersions.txt inside the container image, and attaches linterVersions.txt (standard image) and slim-linterVersions.txt (slim image) as release assets on each GitHub release.

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 permission to clone the repository
         contents: read
         packages: read
         # issues and pull-requests permissions to write results as pull
         # request comments. Omit them if you don't need summary comments
         issues: write
         pull-requests: write
         # To report GitHub Actions status checks. Omit if you don't need
         # to update commit status
         statuses: write
   
       steps:
         - name: Checkout code
           uses: actions/checkout@v6
           with:
             # super-linter needs the full git history to get the
             # list of files that changed across commits
             fetch-depth: 0
             persist-credentials: false
   
         - name: Super-linter
           uses: super-linter/super-linter@v9.0.0 # 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.

To lint and format only the files that you changed or created, set VALIDATE_ALL_CODEBASE to false. To lint and format all the files in the workspace, set VALIDATE_ALL_CODEBASE to true (the default).

The following linters and formatters ignore the VALIDATE_ALL_CODEBASE variable, and always check the entire workspace:

• Biome, because it supports its own mechanism to check changed files only. For more information, about configuring Biome to only check changed files, see Biome VCS integration doc.
• Trivy, because while some Trivy scanners can work on changed files only, others expect to scan the entire workspace. For example, if you run the SBOM scanner against a subset of files, you'll unexpectedly get a partial SBOM.
• Jscpd, because the most likely intended Jscpd use case is to search for duplicates across the entire workspace, not just across the changed files.

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.

There is no FIX_PRE_COMMIT configuration variable because you can enable or disable fix mode for a pre-commit hook (if the hook supports that) by updating your pre-commit configuration file. To enable fix mode for a pre-commit hook, see the documentation of that hook.

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 you push commits on any branch, or when you create or update a pull request:

---
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@v6
        with:
          fetch-depth: 0
          persist-credentials: false
      - name: Super-Linter
        uses: super-linter/super-linter@v9.0.0 # 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: super-linter@super-linter.dev

This example uses GitHub Actions automatic token authentication that automatically creates 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 restricts 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@v6
     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.

By providing your own configuration files, Super-linter will ignore default configuration files. For example, if you provide your own configuration file for a linter, you can enable more checks and rules than what Super-linter enables by default for that linter, or disable some checks and rules that you don't need to enable. Super-linter configures some linters to enable more checks and rules than linters would by default, so by providing your own configuration file, ensure that you enable all checks and rules that you need for your use case.

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

• Load configuration files from the root directory of your repository:

  env:
    LINTER_RULES_PATH: .

In order to facilitate migrations from using standalone linters and formatters to super-linter, the following linters and formatters don't load configuration files from LINTER_RULES_PATH, but rather they use their own mechanism to discover and load configuration files. To configure these linters and formatters, see:

• Biome
• Prettier
• Commitlint

Some of the linters and formatters 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 or formatter, 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)$

To use regular expressions that check starting from the beginning of the string (using ^), set STRIP_DEFAULT_WORKSPACE_FOR_REGEX to true.

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.

The following linters and formatters ignore the FILTER_REGEX_INCLUDE, FILTER_REGEX_EXCLUDE, IGNORE_GENERATED_FILES, IGNORE_GITIGNORED_FILES, VALIDATE_ALL_CODEBASE variables, and always check the entire workspace:

• ansible-lint
• Biome
• Jscpd
• Checkov
• pre-commit
• Trivy

When running these linters and formatters, Super-linter demands to them the task of building the list of files that they should check.

To include or exclude files when using the tools in the preceding list, use their own ignoring mechanisms.

When you trigger a workflow with a step that runs Super-linter on GitHub Actions on specific events, consider the following if you set VALIDATE_ALL_CODEBASE to false:

• push events: Super-linter checks only the files that were modified in the commits you pushed in the push event. Examples:
  • If you push commit-1 and commit-2 to branch-a, Super-linter will lint the files you modified in commit-1 and commit-2. Then, if you push commit-3 to branch-a, Super-linter will check only the files you modified in commit-3.
  • If you push a merge commit that merges the default branch (example: main) in a non-default branch, Super-linter will check only the files that you modified in the merge commit. This might be surprising for some users, because, in this case, Super-linter will check only files that you modified in the default branch in the merge commit.
• merge_group, pull_request events: Super-linter checks all the files that you modified compared to the repository default branch.
• workflow_dispatch events: Super-linter checks all the files that you modified compared to the repository default branch. If you send a workflow_dispatch event to the default branch of your repository, or to a tag that points at the HEAD of your default branch, Super-linter will not find any file to lint unless VALIDATE_ALL_CODEBASE is set to true.
• pull_request_target, repository_dispatch, schedule events: Super-linter will not find any files to check unless VALIDATE_ALL_CODEBASE is set to true because these events run against the repository default branch.

By setting FAIL_ON_INVALID_GITHUB_ACTIONS_EVENT_CONFIGURATION to true, Super-linter exits with an error if the configuration is not suitable for the GitHub event that triggered the issue.

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 certification authority (CA) certificate in the operating system 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.
• If ENABLE_GITHUB_PULL_REQUEST_SUMMARY_COMMENT is set to true, Super-linter posts a comment on the pull request that triggered the Super-linter workflow. Setting ENABLE_GITHUB_PULL_REQUEST_SUMMARY_COMMENT 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 detailed outputs 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.

When outputs (and optionally the summary) are saved, the output directory ${SUPER_LINTER_OUTPUT_DIRECTORY_NAME} has the following structure:

• ${SUPER_LINTER_OUTPUT_DIRECTORY_NAME}/
  • ${SUPER_LINTER_SUMMARY_FILE_NAME}: A Markdown summary containing a table of the validation results for each language/linter (see Summary outputs for details).
  • super-linter/: Contains detailed execution logs and results:
    • super-linter-results.json: Top-level execution log in JSON format (GNU Parallel output), recording the execution of LintCodebase for each language.
    • super-linter-parallel-results-build-file-list.json: JSON file containing the results of the file discovery and categorization phase.
    • super-linter-file-arrays/: Contains files listing the discovered files for each linter:
      • file-array-<LINTER>: List of files mapped to the specific <LINTER>.
    • For each language <LANGUAGE> (e.g., BASH, TYPESCRIPT_ES):
      • super-linter-parallel-command-exit-code-<LANGUAGE>: The exit code of the linter command execution.
      • super-linter-parallel-stdout-<LANGUAGE>: Standard output of the linter command.
      • super-linter-parallel-stderr-<LANGUAGE>: Standard error of the linter command.
      • super-linter-worker-results-<LANGUAGE>.json: Detailed execution results of the linter worker in JSON format (GNU Parallel job log).

If you set CREATE_LOG_FILE to true, Super-linter saves its log to ${DEFAULT_WORKSPACE}/${LOG_FILE}.

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

Super-linter supports installing dependencies at runtime, on each Super-linter run. For more information about installing additional dependencies when running Super-linter, see Install additional dependencies.