This repository is for the GitHub Action to run a Super-Linter, a ready-to-run collection of linters and code analyzers, to help validate 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 is licensed under a MIT License.

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
   
   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
   
         - name: Super-linter
           uses: super-linter/super-linter@v5
           env:
             DEFAULT_BRANCH: main
             # 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.

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:

  • rust linters
  • dotenv linters
  • armttk linters
  • pwsh linters
  • c# linters

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.

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 ACTIONS_RUNNER_DEBUG=true \
  -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 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 valide the certificate:

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

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