MegaLinter is an open-source tool for CI/CD workflows that analyzes the consistency of your code, IaC, configuration, and scripts in your repository to ensure all your project sources are clean and formatted, regardless of the IDE or tools used by your developers. Powered by OX Security.
Supporting 65 languages, 22 formats, and 20 tooling formats. It is ready to use out of the box as a GitHub Action or with any CI system, highly configurable, and free for all uses.
MegaLinter has native integrations with many major CI/CD tools.
Before you go further, see the online documentation website, which offers much easier navigation than this README
- Why MegaLinter
- Quick Start
- Supported Linters
- Installation
- Configuration
- Reporters
- Flavors
- Badge
- Plugins
- They talk about MegaLinter
- Frequently Asked Questions
- How to contribute
- Special thanks
- License
- MegaLinter vs Super-Linter
Projects need to contain clean code in order to avoid technical debt, which makes ongoing maintenance harder and more time-consuming.
By using code formatters and code linters, you ensure that your codebase is easier to read and follows best practices, from kickoff through each step of the project lifecycle.
Not all developers use linters in their IDEs, which makes code reviews harder and longer to process.
By using MegaLinter, you'll enjoy the following benefits for your team:
- At each pull request, it automatically analyzes all updated code across all languages.
- By reading error logs, developers learn best practices for the languages they use.
- The MegaLinter documentation provides a list of IDE plugins for each linter, so developers know which linter and plugins to install.
- MegaLinter works out of the box after a quick setup.
- Formatting and fixes can be automatically applied directly to the Git branch or provided in reports.
- This tool is 100% open source and free for all uses (personal, professional, public, and private repositories).
- MegaLinter can run on any CI tool and be run locally: no need to authorize an external application, and your codebase never leaves your tooling ecosystem.
- Run
npx mega-linter-runner --installto generate configuration files (you need Node.js installed). - Commit, push, and create a pull request.
- Watch!
Notes:
- This repo is a hard fork of GitHub Super-Linter, rewritten in Python to add many additional features.
- If you are a Super-Linter user, you can transparently switch to MegaLinter and keep the same configuration (just replace
super-linter/super-linter@v3withoxsecurity/megalinter@v8in your GitHub Action YAML file, like on this PR). - If you want to use MegaLinter's extra features (recommended), please take 5 minutes to use the assisted installation.
- For a beginner-friendly example of getting started with MegaLinter, check out this blog post by Alec Johnson.
All linters are integrated into the MegaLinter Docker image, which is frequently updated with their latest versions.
Just run npx mega-linter-runner --install at the root of your repository and answer questions, it will generate ready to use configuration files for MegaLinter :)
The following instructions examples are using latest MegaLinter stable version (v8 , always corresponding to the latest release)
- Docker image:
oxsecurity/megalinter:v9 - GitHub Action:
oxsecurity/megalinter@v9
You can also use beta version (corresponding to the content of main branch)
- Docker image:
oxsecurity/megalinter:beta - GitHub Action:
oxsecurity/megalinter@beta
- Create a new file in your repository called
.github/workflows/mega-linter.yml - Copy the example workflow from below into that new file, no extra configuration required
- Commit that file to a new branch
- Open up a pull request and observe the action working
- Enjoy your more stable, and cleaner code base
NOTES:
- If you pass the Environment variable
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}in your workflow, then the MegaLinter will mark the status of each individual linter run in the Checks section of a pull request. Without this you will only see the overall status of the full run. There is no need to set the GitHub Secret as it's automatically set by GitHub, it only needs to be passed to the action. - You can also use it outside of GitHub Actions (CircleCI, Azure Pipelines, Jenkins, GitLab, or even locally with a docker run) , and have status on Github Pull Request if
GITHUB_TARGET_URLenvironment variable exists.
In your repository you should have a .github/workflows folder with GitHub Action similar to below:
.github/workflows/mega-linter.yml
This file should have this code
---
# MegaLinter GitHub Action configuration file
# More info at https://megalinter.io
name: MegaLinter
on:
# Trigger mega-linter at every push. Action will also be visible from Pull Requests to main
push: # Comment this line to trigger action only on pull-requests (not recommended if you don't pay for GH Actions)
pull_request:
branches: [master, main]
env: # Comment env block if you don't want to apply fixes
# Apply linter fixes configuration
APPLY_FIXES: all # When active, APPLY_FIXES must also be defined as environment variable (in github/workflows/mega-linter.yml or other CI tool)
APPLY_FIXES_EVENT: pull_request # Decide which event triggers application of fixes in a commit or a PR (pull_request, push, all)
APPLY_FIXES_MODE: commit # If APPLY_FIXES is used, defines if the fixes are directly committed (commit) or posted in a PR (pull_request)
concurrency:
group: ${{ github.ref }}-${{ github.workflow }}
cancel-in-progress: true
jobs:
megalinter:
name: MegaLinter
runs-on: ubuntu-latest
permissions:
# Give the default GITHUB_TOKEN write permission to commit and push, comment issues & post new PR
# Remove the ones you do not need
contents: write
issues: write
pull-requests: write
steps:
# Git Checkout
- name: Checkout Code
uses: actions/checkout@v5
with:
token: ${{ secrets.PAT || secrets.GITHUB_TOKEN }}
fetch-depth: 0 # If you use VALIDATE_ALL_CODEBASE = true, you can remove this line to improve performances
# MegaLinter
- name: MegaLinter
id: ml
# You can override MegaLinter flavor used to have faster performances
# More info at https://megalinter.io/flavors/
uses: oxsecurity/megalinter@v8
env:
# All available variables are described in documentation
# https://megalinter.io/configuration/
VALIDATE_ALL_CODEBASE: ${{ github.event_name == 'push' && github.ref == 'refs/heads/main' }} # Validates all source when push on main, else just the git diff with main. Override with true if you always want to lint all sources
GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
# ADD YOUR CUSTOM ENV VARIABLES HERE OR DEFINE THEM IN A FILE .mega-linter.yml AT THE ROOT OF YOUR REPOSITORY
# DISABLE: COPYPASTE,SPELL # Uncomment to disable copy-paste and spell checks
# Upload MegaLinter artifacts
- name: Archive production artifacts
if: success() || failure()
uses: actions/upload-artifact@v4
with:
name: MegaLinter reports
path: |
megalinter-reports
mega-linter.log
# Create pull request if applicable (for now works only on PR from same repository, not from forks)
- name: Create Pull Request with applied fixes
id: cpr
if: steps.ml.outputs.has_updated_sources == 1 && (env.APPLY_FIXES_EVENT == 'all' || env.APPLY_FIXES_EVENT == github.event_name) && env.APPLY_FIXES_MODE == 'pull_request' && (github.event_name == 'push' || github.event.pull_request.head.repo.full_name == github.repository) && !contains(github.event.head_commit.message, 'skip fix')
uses: peter-evans/create-pull-request@v7
with:
token: ${{ secrets.PAT || secrets.GITHUB_TOKEN }}
commit-message: "[MegaLinter] Apply linters automatic fixes"
title: "[MegaLinter] Apply linters automatic fixes"
labels: bot
- name: Create PR output
if: steps.ml.outputs.has_updated_sources == 1 && (env.APPLY_FIXES_EVENT == 'all' || env.APPLY_FIXES_EVENT == github.event_name) && env.APPLY_FIXES_MODE == 'pull_request' && (github.event_name == 'push' || github.event.pull_request.head.repo.full_name == github.repository) && !contains(github.event.head_commit.message, 'skip fix')
run: |
echo "Pull Request Number - ${{ steps.cpr.outputs.pull-request-number }}"
echo "Pull Request URL - ${{ steps.cpr.outputs.pull-request-url }}"
# Push new commit if applicable (for now works only on PR from same repository, not from forks)
- name: Prepare commit
if: steps.ml.outputs.has_updated_sources == 1 && (env.APPLY_FIXES_EVENT == 'all' || env.APPLY_FIXES_EVENT == github.event_name) && env.APPLY_FIXES_MODE == 'commit' && github.ref != 'refs/heads/main' && (github.event_name == 'push' || github.event.pull_request.head.repo.full_name == github.repository) && !contains(github.event.head_commit.message, 'skip fix')
run: sudo chown -Rc $UID .git/
- name: Commit and push applied linter fixes
if: steps.ml.outputs.has_updated_sources == 1 && (env.APPLY_FIXES_EVENT == 'all' || env.APPLY_FIXES_EVENT == github.event_name) && env.APPLY_FIXES_MODE == 'commit' && github.ref != 'refs/heads/main' && (github.event_name == 'push' || github.event.pull_request.head.repo.full_name == github.repository) && !contains(github.event.head_commit.message, 'skip fix')
uses: stefanzweifel/git-auto-commit-action@v6
with:
branch: ${{ github.event.pull_request.head.ref || github.head_ref || github.ref }}
commit_message: "[MegaLinter] Apply linters fixes"
commit_user_name: megalinter-bot
commit_user_email: [email protected]Create or update .gitlab-ci.yml file at the root of your repository
# MegaLinter GitLab CI job configuration file
# More info at https://megalinter.io/
mega-linter:
stage: test
# You can override MegaLinter flavor used to have faster performances
# More info at https://megalinter.io/flavors/
image: oxsecurity/megalinter:v9
script: [ "true" ] # if script: ["true"] doesn't work, you may try -> script: [ "/bin/bash /entrypoint.sh" ]
variables:
# All available variables are described in documentation
# https://megalinter.io/configuration/
DEFAULT_WORKSPACE: $CI_PROJECT_DIR
# ADD YOUR CUSTOM ENV VARIABLES HERE TO OVERRIDE VALUES OF .mega-linter.yml AT THE ROOT OF YOUR REPOSITORY
artifacts:
when: always
paths:
- megalinter-reports
expire_in: 1 weekCreate a Gitlab access token and define it in a variable GITLAB_ACCESS_TOKEN_MEGALINTER in the project CI/CD masked variables. Make sure your token (e.g. if a project token) as the appropriate role for commenting a merge request (at least developer).
Use the following Azure Pipelines YAML template
You can configure a build validation branch policy against a single repository or across all repositories. If you configure across all repositories then your pipeline is stored in a central repository.
Add the following to an azure-pipelines.yaml file within your code repository:
# Run MegaLinter to detect linting and security issues
- job: MegaLinter
pool:
vmImage: ubuntu-latest
steps:
# Checkout repo
- checkout: self
# Pull MegaLinter docker image
- script: docker pull oxsecurity/megalinter:v9
displayName: Pull MegaLinter
# Run MegaLinter
- script: |
docker run -v $(System.DefaultWorkingDirectory):/tmp/lint \
--env-file <(env | grep -e SYSTEM_ -e BUILD_ -e TF_ -e AGENT_) \
-e SYSTEM_ACCESSTOKEN=$(System.AccessToken) \
-e GIT_AUTHORIZATION_BEARER=$(System.AccessToken) \
oxsecurity/megalinter:v9
displayName: Run MegaLinter
# Upload MegaLinter reports
- task: PublishPipelineArtifact@1
condition: succeededOrFailed()
displayName: Upload MegaLinter reports
inputs:
targetPath: "$(System.DefaultWorkingDirectory)/megalinter-reports/"
artifactName: MegaLinterReportAdd the following to an azure-pipelines.yaml file within a separate repository, for example a 'MegaLinter' repository:
# Run MegaLinter to detect linting and security issues
trigger: none
pool:
vmImage: ubuntu-latest
variables:
repoName: $[ replace(split(variables['System.PullRequest.SourceRepositoryURI'], '/')[6], '%20', ' ') ]
steps:
# Checkout triggering repo
- checkout: git://$(System.TeamProject)/$(repoName)@$(System.PullRequest.SourceBranch)
displayName: Checkout Triggering Repository
# Pull MegaLinter docker image
- script: docker pull oxsecurity/megalinter:v9
displayName: Pull MegaLinter
# Run MegaLinter
- script: |
docker run -v $(System.DefaultWorkingDirectory):/tmp/lint \
--env-file <(env | grep -e SYSTEM_ -e BUILD_ -e TF_ -e AGENT_) \
-e SYSTEM_ACCESSTOKEN=$(System.AccessToken) \
-e GIT_AUTHORIZATION_BEARER=$(System.AccessToken) \
oxsecurity/megalinter:v9
displayName: Run MegaLinter
# Upload MegaLinter reports
- task: PublishPipelineArtifact@1
condition: succeededOrFailed()
displayName: MegaLinter Report
inputs:
targetPath: $(System.DefaultWorkingDirectory)/megalinter-reports/
artifactName: MegaLinterReportTo enable Pull Request comments, follow the configuration instructions.
Note: If your pipelines run on Azure DevOps but your source code is hosted on GitHub, and you want status reports to appear on GitHub, you must provide additional repository information to the pipeline. See this example for guidance.
You can also follow this detailed tutorial by DonKoning.
-
Create a
bitbucket-pipelines.ymlfile at the root of your repository. -
Copy and paste the following template or add the step to your existing pipeline.
image: atlassian/default-image:3
pipelines:
default:
- parallel:
- step:
name: Run MegaLinter
image: oxsecurity/megalinter:v9
script:
- export DEFAULT_WORKSPACE=$BITBUCKET_CLONE_DIR && bash /entrypoint.sh
artifacts:
- megalinter-reports/**Add the following stage to your Jenkinsfile.
You may activate the File.io reporter or Email reporter to access detailed logs and fixed sources.
// Lint with MegaLinter: https://megalinter.io/
stage('MegaLinter') {
agent {
docker {
image 'oxsecurity/megalinter:v9'
args "-u root -e VALIDATE_ALL_CODEBASE=true -v ${WORKSPACE}:/tmp/lint --entrypoint=''"
reuseNode true
}
}
steps {
sh '/entrypoint.sh'
}
post {
always {
archiveArtifacts allowEmptyArchive: true, artifacts: 'mega-linter.log,megalinter-reports/**/*', defaultExcludes: false, followSymlinks: false
}
}
}CloudBees has a helpful tutorial about how to use MegaLinter with Jenkins!
Use the following job step in your pipeline template.
Note: Make sure you have a job.plan.get step that retrieves the repo containing your repository, as shown in the example.
---
- name: linting
plan:
- get: repo
- task: linting
config:
platform: linux
image_resource:
type: docker-image
source:
repository: oxsecurity/megalinter
tag: v8
inputs:
- name: repo
run:
path: bash
args:
- -cxe
- |
cd repo
export DEFAULT_WORKSPACE=$(pwd)
bash -ex /entrypoint.sh
## doing this because concourse doesn't work as other CI systems
# params:
# PARALLEL: true
# DISABLE: SPELL
# APPLY_FIXES: all
# DISABLE_ERRORS: true
# VALIDATE_ALL_CODEBASE: trueOR
Create a reusable Concourse task that can be used with multiple pipelines.
- Create task file
task-linting.yaml
---
platform: linux
image_resource:
type: docker-image
source:
repository: oxsecurity/megalinter
tag: v8
inputs:
- name: repo
## uncomment this if you want reports as task output
# output:
# - name: reports
# path: repo/megalinter-reports
run:
path: bash
args:
- -cxe
- |
cd repo
export DEFAULT_WORKSPACE=$(pwd)
bash -ex /entrypoint.sh- Use that
task-linting.yamltask in your pipeline.
Note:
-
Make sure
task-linting.yamlis available in therepoinput at the repository root. -
Task
outputis not shown here.
resources:
- name: linting
plan:
- get: repo
- task: linting
file: repo/task-linting.yaml
# params:
# PARALLEL: true
# DISABLE: SPELL
# APPLY_FIXES: all
# DISABLE_ERRORS: true
# VALIDATE_ALL_CODEBASE: trueWarning: Drone CI support is experimental and is undergoing significant modifications (see issue #2047).
-
Create a
.drone.ymlfile on the root directory of your repository -
Copy and paste the following template:
kind: pipeline
type: docker
name: MegaLinter
workspace:
path: /tmp/lint
steps:
- name: megalinter
image: oxsecurity/megalinter:v9
environment:
DEFAULT_WORKSPACE: /tmp/lintThis uses the Drone CI Docker runner, so you need to install and configure it beforehand on your Drone CI server.
The Drone CI workflow should trigger automatically for most scenarios (push, pull request, sync…). However, you can optionally change this behavior by modifying the trigger. For example:
kind: pipeline
type: docker
name: MegaLinter
workspace:
path: /tmp/lint
steps:
- name: megalinter
image: oxsecurity/megalinter:v9
environment:
DEFAULT_WORKSPACE: /tmp/lint
trigger:
event:
- pushThe workflow above triggers only on push, and not in other situations. For more information about configuring Drone CI trigger rules, see the documentation.
You can also run MegaLinter with its Docker container. Execute this command:
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock:rw -v $(pwd):/tmp/lint:rw oxsecurity/megalinter:v9
No extra arguments are needed; however, MegaLinter will lint all files inside the /tmp/lint folder. You may need to configure your tool of choice to use /tmp/lint as its workspace.
This can be changed:
Example:
docker run --rm -v /var/run/docker.sock:/var/run/docker.sock:rw -v $(pwd):/example/folder:rw oxsecurity/megalinter:v9
Use mega-linter-runner to run MegaLinter locally with the same configuration defined in your .mega-linter.yml file.
See the mega-linter-runner installation instructions.
Example:
npx mega-linter-runner --flavor salesforce -e "'ENABLE=DOCKERFILE,MARKDOWN,YAML'" -e 'SHOW_ELAPSED_TIME=true'Note: You can also use this command line in your custom CI/CD pipelines.
MegaLinter configuration variables are defined in a .mega-linter.yml file at the root of the repository or with environment variables. You can see an example config file in this repo: .mega-linter.yml.
Configuration is assisted with autocompletion and validation in most commonly used IDEs, thanks to the JSON schema stored on schemastore.org.
- VS Code: You need an extension like Red Hat YAML.
- IntelliJ IDEA family: Autocompletion is supported natively.
You can also define variables as environment variables.
- If a variable exists in both ENV and the
.mega-linter.ymlfile, priority is given to the ENV variable.
| ENV VAR | Default Value | Notes |
|---|---|---|
| ADDITIONAL_EXCLUDED_DIRECTORIES | [] | List of additional excluded directory basenames. They're excluded at any nested level. |
| APPLY_FIXES | none |
Activates formatting and autofix (more info) |
| CLEAR_REPORT_FOLDER | false |
Flag to clear files from report folder (usually megalinter-reports) before starting the linting process |
| CONFIG_PROPERTIES_TO_APPEND | [] | List of configuration properties to append their values (instead of replacing them) in case of using EXTENDS. |
| DEFAULT_BRANCH | HEAD |
The name of the repository's default branch, useful if you use VALIDATE_ALL_CODEBASE=false |
| DEFAULT_WORKSPACE | /tmp/lint |
The location containing files to lint if you are running locally. |
| DISABLE_ERRORS | false |
Flag to have the linter complete with exit code 0 even if errors were detected. |
| DISABLE | List of disabled descriptors keys (more info) | |
| DISABLE_LINTERS | List of disabled linters keys (more info) | |
| DISABLE_ERRORS_LINTERS | List of enabled but not blocking linters keys. All linters not in this list will be not blocking (more info) | |
| ENABLE_ERRORS_LINTERS | List of enabled and blocking linters keys (more info) | |
| ENABLE | List of enabled descriptors keys (more info) | |
| ENABLE_LINTERS | List of enabled linters keys (more info) | |
| EXCLUDED_DIRECTORIES | […many values…] | List of excluded directory basenames. They're excluded at any nested level. |
| EXTENDS | Base mega-linter.yml config file(s) to extend local configuration from. Can be a single URL or a list of .mega-linter.yml config files URLs. Later files take precedence. |
|
| FAIL_IF_MISSING_LINTER_IN_FLAVOR | false |
If set to true, MegaLinter fails if a linter is missing in the selected flavor |
| FAIL_IF_UPDATED_SOURCES | false |
If set to true, MegaLinter fails if a linter or formatter has autofixed sources, even if there are no errors |
| FILTER_REGEX_EXCLUDE | none |
Regular expression defining which files will be excluded from linting (more info) .ex: .*src/test.*) |
| FILTER_REGEX_INCLUDE | all |
Regular expression defining which files will be processed by linters (more info) .ex: .*src/.*) |
| FLAVOR_SUGGESTIONS | true |
Provides suggestions about different MegaLinter flavors to use to improve runtime performances |
| FORMATTERS_DISABLE_ERRORS | true |
Formatter errors will be reported as errors (not warnings) if this variable is set to false. |
| GIT_AUTHORIZATION_BEARER | If set, calls git with Authorization: Bearer+value |
|
| GITHUB_WORKSPACE | Base directory for REPORT_OUTPUT_FOLDER, for user-defined linter rules location, for location of linted files if DEFAULT_WORKSPACE isn't set |
|
| IGNORE_GENERATED_FILES | false |
If set to true, MegaLinter will skip files containing @generated marker but without @not-generated marker (more info at https://generated.at) |
| IGNORE_GITIGNORED_FILES | true |
If set to true, MegaLinter will skip files ignored by Git using the .gitignore file. |
| JAVASCRIPT_DEFAULT_STYLE | standard |
Javascript default style to check/apply. standard,prettier |
| LINTER_RULES_PATH | .github/linters |
Directory for all linter configuration rules. Can be a local folder or a remote URL (e.g., https://raw.githubusercontent.com/some_org/some_repo/mega-linter-rules). |
| LOG_FILE | mega-linter.log |
The file name for outputting logs. All output is sent to the log file regardless of LOG_LEVEL. Use none to not generate this file. |
| LOG_LEVEL | INFO |
How much output the script will generate to the console. One of INFO, DEBUG, WARNING or ERROR. |
| MARKDOWN_DEFAULT_STYLE | markdownlint |
Markdown default style to check/apply. markdownlint, remark-lint |
| MEGALINTER_CONFIG | .mega-linter.yml |
Name of MegaLinter configuration file. Can be defined remotely, in that case set this environment variable with the remote URL of .mega-linter.yml config file |
| MEGALINTER_FILES_TO_LINT | [] | Comma-separated list of files to analyze. Using this variable will bypass other file listing methods |
| PARALLEL | true |
Process linters in parallel to improve overall MegaLinter performance. If true, linters of same language or formats are grouped in the same parallel process to avoid lock issues if fixing the same files |
| PARALLEL_PROCESS_NUMBER | All available cores are used by default. If there are too many, decrease the number of used cores to enhance performance (example: 4). |
|
| PLUGINS | [] | List of plugin urls to install and run during MegaLinter run |
| POST_COMMANDS | [] | Custom bash commands to run after linters |
| PRE_COMMANDS | [] | Custom bash commands to run before linters |
| PRINT_ALPACA | true |
Enable printing alpaca image to console |
| PRINT_ALL_FILES | false |
Display all files analyzed by the linter instead of only the number. |
| PYTHON_DEFAULT_STYLE | black |
Python default style to check/apply. black,ruff |
| REPORT_OUTPUT_FOLDER | ${GITHUB_WORKSPACE}/megalinter-reports |
Directory for generating report files. Set to none to skip generating reports. |
| SECURED_ENV_VARIABLES | [] | Additional list of secured environment variables to hide when calling linters. |
| SECURED_ENV_VARIABLES_DEFAULT | MegaLinter & CI platforms sensitive variables | List of secured environment variables to hide when calling linters. Default list. This is not recommended to override this variable, use SECURED_ENV_VARIABLES |
| SHOW_ELAPSED_TIME | false |
Displays elapsed time in reports |
| SHOW_SKIPPED_LINTERS | true |
Displays all disabled linters MegaLinter could have run. |
| SKIP_CLI_LINT_MODES | [] | Comma-separated list of cli_lint_modes. To use if you want to skip linters with some CLI lint modes (ex: file,project). Available values: file,cli_lint_mode,project. |
| SKIP_LINTER_OUTPUT_SANITIZATION | false |
By default, MegaLinter sanitizes the output of every external command using Gitleaks public rules. If you are on a private and secured repo, you can improve performances by setting this variable to true, but it will mean that if a linter output contains a secret, it will be visible in log files |
| TYPESCRIPT_DEFAULT_STYLE | standard |
Typescript default style to check/apply. standard,prettier |
| 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. |
MegaLinter has all linters enabled by default, but allows enabling or disabling specific ones.
- If
ENABLEisn't set, all descriptors are activated by default. If set, all linters of listed descriptors are activated by default. - If
ENABLE_LINTERSis set, only the listed linters are processed. - If
DISABLEis set, the linters in the listed descriptors are skipped. - If
DISABLE_LINTERSis set, the listed linters are skipped. - If
DISABLE_ERRORS_LINTERSis set, the listed linters will run, but if errors are found, they will be considered non-blocking. - If
ENABLE_ERRORS_LINTERSis set, only the linters in this list will be considered blocking.
Examples:
- Run all javascript and groovy linters except STANDARD javascript linter. DevSkim errors will be non-blocking
ENABLE: JAVASCRIPT,GROOVY
DISABLE_LINTERS: JAVASCRIPT_STANDARD
DISABLE_ERRORS_LINTERS: REPOSITORY_DEVSKIM- Run all matching linters but only trivy is blocking
ENABLE_ERRORS_LINTERS: REPOSITORY_TRIVY- Run all linters except PHP linters (PHP_BUILTIN, PHP_PHPCS, PHP_PHPSTAN, PHP_PSALM)
DISABLE: PHP- Run all linters except PHP_PHPSTAN and PHP_PSALM linters
DISABLE_LINTERS:
- PHP_PHPSTAN
- PHP_PSALMIf you need to lint only a folder or exclude some files from linting, you can use the optional environment parameters FILTER_REGEX_INCLUDE and FILTER_REGEX_EXCLUDE.
You can apply filters to a single linter by defining the variables <LINTER_KEY>_FILTER_REGEX_INCLUDE and <LINTER_KEY>_FILTER_REGEX_EXCLUDE.
Examples:
- Lint only src folder:
FILTER_REGEX_INCLUDE: (src/) - Don't lint files inside test and example folders:
FILTER_REGEX_EXCLUDE: (test/|examples/) - Don't lint javascript files inside test folder:
FILTER_REGEX_EXCLUDE: (test/.*\.js)
Warning: Not applicable with linters using CLI lint mode project (see details).
MegaLinter can apply fixes provided by linters. To use this capability, you need three environment variables defined at the top level.
- APPLY_FIXES:
allto apply fixes of all linters, or a list of linter keys (ex:JAVASCRIPT_ES,MARKDOWN_MARKDOWNLINT)
Only for the GitHub Actions workflow file, if you use it:
- APPLY_FIXES_EVENT:
all,push,pull_request,none(use none in case of use of Updated sources reporter) - APPLY_FIXES_MODE:
committo create a new commit and push it on the same branch, orpull_requestto create a new PR targeting the branch.
You may see GitHub permission errors, or workflows not running on the new commit.
To solve these issues, apply one of the following solutions.
- Method 1: The most secured
- Create a Fine-Grained Personal Access Token, scoped only to your repository and with Contents: Read/Write, then copy the PAT value
- Define environment secret variable named PAT on your repository, and paste the PAT value
- Update your GitHub Actions workflow to add the environment name
-- Method 2: Easier, but any contributor with write access can see your Personal Access Token, so use it only on private repositories.
- Create a Classic Personal Access Token, then copy the PAT value
- Define secret variable named PAT on your repository, and paste the PAT value
- You can use the Updated sources reporter if you don't want fixes to be automatically applied on the Git branch. Instead, download them in a ZIP file and manually extract them into your project.
- If used,
APPLY_FIXES_EVENTandAPPLY_FIXES_MODEcannot be defined in the.mega-linter.ymlconfig file; they must be set as environment variables. - If you use
APPLY_FIXES, add the following line to your.gitignorefile:
megalinter-reports/See variables related to a single linter behavior in linters documentations
MegaLinter can run custom commands before running linters (for example, installing a plugin required by one of the linters you use).
Example in .mega-linter.yml config file
PRE_COMMANDS:
- command: npm install eslint-plugin-whatever
cwd: root # Will be run at the root of the MegaLinter Docker image
secured_env: true # True by default. If set to false, no global variables will be hidden (for example, if you need GITHUB_TOKEN)
run_before_linters: True # Will be run before the execution of the linters themselves; required for npm/pip commands that cannot be run in parallel
- command: echo "pre-test command has been called"
cwd: workspace # Will be run at the root of the workspace (usually your repository root)
continue_if_failed: False # Will stop the process if the command fails (return code > 0)
- command: pip install flake8-cognitive-complexity
venv: flake8 # Will be run within the flake8 Python virtualenv. There is one virtualenv per Python-based linter, with the same name
- command: export MY_OUTPUT_VAR="my output var" && export MY_OUTPUT_VAR2="my output var2"
output_variables: ["MY_OUTPUT_VAR","MY_OUTPUT_VAR2"] # Will collect the values of output variables and update MegaLinter's own ENV context
- command: echo "Some command called before loading MegaLinter plugins"
cwd: workspace # Will be run at the root of the workspace (usually your repository root)
continue_if_failed: False # Will stop the process if the command fails (return code > 0)
tag: before_plugins # Tag indicating that the command will be run before loading plugins
- command: echo "Some command called after running MegaLinter linters"
run_after_linters: True # Will be run after the execution of the linters themselves| Property | Description | Default value |
|---|---|---|
| command | Command line to run | Mandatory |
| cwd | Directory where to run the command (workspace or root) |
workspace |
| run_before_linters | If set to true, runs the command before the execution of the linters themselves, required for npm/pip commands that cannot be run in parallel |
false |
| run_after_linters | If set to true, runs the command after the execution of the linters themselves |
false |
| secured_env | Apply filtering of secured environment variables before calling the command (default true). Be careful if you disable it! |
true |
| continue_if_failed | If set to false, stop the MegaLinter process in case of command failure |
true |
| venv | If set, runs the command in the related Python venv | |
| output_variables | ENV variables to read from output after running the commands, and store in MegaLinter's ENV context so they can be reused in subsequent commands | [] |
| tag | Tag defining at which command entry point the command will be run (available tags: before_plugins) |
MegaLinter can run custom commands after running linters (for example, running additional tests).
Example in .mega-linter.yml config file
POST_COMMANDS:
- command: npm run test
cwd: "workspace" # Will be run at the root of the workspace (usually your repository root)
continue_if_failed: False # Will stop the process if the command fails (return code > 0)MegaLinter runs in a Docker image and calls the linters via the command line to gather their results.
If you run it from your CI/CD pipelines, the Docker image may have access to your environment variables, which can contain secrets defined in CI/CD variables.
As it can be complicated to fully trust the authors of all open-source linters, MegaLinter removes variables from the environment used to call linters.
Thanks to this feature, you only need to trust MegaLinter and its internal Python dependencies; there is no need to trust all the linters that are used.
You can add secured variables to the default list using the configuration property SECURED_ENV_VARIABLES in .mega-linter.yml or as an environment variable (priority is given to ENV variables over the .mega-linter.yml property).
Values can be:
- String (ex:
MY_SECRET_VAR) - Regular Expression (ex:
(MY.*VAR))
Environment variables are secured for each command line called (linters, plugins, SARIF formatter, etc.) except for PRE_COMMANDS, and only if you define secured_env: false in the command.
- Example of adding extra secured variables in
.mega-linter.yml:
SECURED_ENV_VARIABLES:
- MY_SECRET_TOKEN
- ANOTHER_VAR_CONTAINING_SENSITIVE_DATA
- OX_API_KEY
- (MY.*VAR) # Regex format- Example of adding extra secured variables in CI variables, so they cannot be overridden in
.mega-linter.yml:
SECURED_ENV_VARIABLES=MY_SECRET_TOKEN,ANOTHER_VAR_CONTAINING_SENSITIVE_DATA,OX_API_KEYIf you override SECURED_ENV_VARIABLES_DEFAULT, it replaces the default list, so it's better to only define SECURED_ENV_VARIABLES to add items to the default list.
SECURED_ENV_VARIABLES_DEFAULT contains:
- GITHUB_TOKEN
- PAT
- SYSTEM_ACCESSTOKEN
- GIT_AUTHORIZATION_BEARER
- CI_JOB_TOKEN
- GITLAB_ACCESS_TOKEN_MEGALINTER
- GITLAB_CUSTOM_CERTIFICATE
- WEBHOOK_REPORTER_BEARER_TOKEN
- NODE_TOKEN
- NPM_TOKEN
- DOCKER_USERNAME
- DOCKER_PASSWORD
- CODECOV_TOKEN
- GCR_USERNAME
- GCR_PASSWORD
- SMTP_PASSWORD
- CI_SFDX_HARDIS_GITLAB_TOKEN
- (SFDX_CLIENT_ID_.*)
- (SFDX_CLIENT_KEY_.*)
You can configure exceptions for a specific linter by defining (linter-key)_UNSECURED_ENV_VARIABLES.
Variable names in this list won't be hidden from the linter commands.
TERRAFORM_TFLINT_UNSECURED_ENV_VARIABLES:
- GITHUB_TOKEN # Can contain string only, not regexEach linter is preconfigured to use a default lint mode, which is visible in the MegaLinter documentation (example). The possible values are:
list_of_files: The linter is called only once, and passed a list of all the files to be processedproject: The linter is called only once, from the root folder of the repository, and it scans for the files to process, as no file names are provided to itfile: The linter is called once per file, which hurts performance
You can override the CLI_LINT_MODE by using a configuration variable for each linter (see the linters documentation).
- Linters that default to the
filelint mode cannot be overridden to use thelist_of_fileslint mode. - Linters that default to the
projectlint mode cannot be overridden to use either thelist_of_filesorfilelint modes.
Allowing file or list_of_files to be overridden to project is mostly for workarounds. For example, some linters have a problem finding their config file when the current folder isn't the repository root.
Special considerations:
- Linters that are configured to use the
projectlint mode ignore variables likeFILTER_REGEX_INCLUDEandFILTER_REGEX_EXCLUDE, as they are not passed a list of files to lint. For those linters, you must check their documentation to see if a linter can be configured to ignore specific files. For example, the Secretlint linter ignores files listed in~/.secretlintignoreby default, or it can be configured to instead ignore files listed in~/.gitignoreby settingREPOSITORY_SECRETLINT_ARGUMENTSto--secretlintignore .gitignore.
MegaLinter can generate various reports that you can activate or deactivate and customize.
| Reporter | Description | Default |
|---|---|---|
| Text files | Generates One log file by linter + suggestions for fixes that can not be automated | Active |
| SARIF (beta) | Generates an aggregated SARIF output file | Inactive |
| GitHub Pull Request comments | MegaLinter posts a comment on the PR with a summary of lint results, and links to detailed logs | Active if GitHub Action |
| Gitlab Merge Request comments | Mega-Linter posts a comment on the MR with a summary of lint results, and links to detailed logs | Active if in Gitlab CI |
| Azure Pipelines Pull Request comments | Mega-Linter posts a comment on the PR with a summary of lint results, and links to detailed logs | Active if in Azure Pipelines |
| Bitbucket Pull Request comments | Mega-Linter posts a comment on the PR with a summary of lint results, and links to detailed logs | Active if in Bitbucket CI |
| API (Grafana) | Sends logs and metrics to Grafana endpoint (Loki / Prometheus) | Inactive |
| Updated sources | Zip containing all formatted and autofixed sources so you can extract them in your repository | Active |
| IDE Configuration | Apply MegaLinter configuration in your local IDE with linter config files and IDE extensions | Active |
| GitHub Status | One GitHub status by linter on the PR, with links to detailed logs | Active if GitHub Action |
| File.io | Send reports on file.io so you can access them with a simple hyperlink provided at the end of console log | Inactive |
| JSON | Generates a JSON output report file | Inactive |
| Receive all reports on your e-mail, if you can not use artifacts | Active | |
| TAP files | One file by linter following Test Anything Protocol format | Active |
| Console | Execution logs visible in console with summary table and links to other reports at the end | Active |
| Markdown Summary | Generates a Markdown summary report file | Inactive |
To improve run performance, we provide flavored MegaLinter images containing only the linters related to a project type.
- When using the default MegaLinter, if a MegaLinter flavor would cover all your project requirements, a message is added in the logs.
- If your project uses a MegaLinter flavor that doesn't cover linter requirements, an error message will be thrown with instructions on how to solve the issue.
The following table doesn't display docker pulls from MegaLinter v4 & v5 images.
| Flavor | Description | Embedded linters | Info | |
|---|---|---|---|---|
 |
all | Default MegaLinter Flavor | 126 |   |
| c_cpp | Optimized for pure C/C++ projects | 55 |   |
|
| ci_light | Optimized for CI items (Dockerfile, Jenkinsfile, JSON/YAML schemas,XML | 22 |   |
|
| cupcake | MegaLinter for the most commonly used languages | 86 |   |
|
| documentation | MegaLinter for documentation projects | 48 |   |
|
| dotnet | Optimized for C, C++, C# or VB based projects | 63 |   |
|
| dotnetweb | Optimized for C, C++, C# or VB based projects with JS/TS | 72 |   |
|
| formatters | Contains only formatters | 18 |   |
|
| go | Optimized for GO based projects | 50 |   |
|
| java | Optimized for JAVA based projects | 53 |   |
|
| javascript | Optimized for JAVASCRIPT or TYPESCRIPT based projects | 58 |   |
|
| php | Optimized for PHP based projects | 53 |   |
|
| python | Optimized for PYTHON based projects | 64 |   |
|
| ruby | Optimized for RUBY based projects | 49 |   |
|
| rust | Optimized for RUST based projects | 49 |   |
|
| salesforce | Optimized for Salesforce based projects | 52 |   |
|
| security | Optimized for security | 23 |   |
|
| swift | Optimized for SWIFT based projects | 49 |   |
|
| terraform | Optimized for TERRAFORM based projects | 53 |   |
If you need a new flavor, post an issue 😉
You can also generate your own custom flavors to include exactly the linters you need in your MegaLinter Docker image.
You can show the MegaLinter status with a badge in your repository README.
If your main branch is named master, replace main with master in the URLs.
- Format
[](https://github.com/<OWNER>/<REPOSITORY>/actions?query=workflow%3AMegaLinter+branch%3Amain)- Example
[](https://github.com/nvuillam/npm-groovy-lint/actions?query=workflow%3AMegaLinter+branch%3Amain)- Format
.. |MegaLinter yes| image:: https://github.com/<OWNER>/<REPOSITORY>/workflows/MegaLinter/badge.svg?branch=main
:target: https://github.com/<OWNER>/<REPOSITORY>/actions?query=workflow%3AMegaLinter+branch%3Amain- Example
.. |MegaLinter yes| image:: https://github.com/nvuillam/npm-groovy-lint/workflows/MegaLinter/badge.svg?branch=main
:target: https://github.com/nvuillam/npm-groovy-lint/actions?query=workflow%3AMegaLinter+branch%3AmainNote: IF you did not use MegaLinter as GitHub Action name, please read GitHub Actions Badges documentation{target=_blank}
For performance and security reasons, we cannot embed every linter in MegaLinter.
But our core architecture allows building and publishing MegaLinter plugins!
| Name | Description | Author | Raw URL |
|---|---|---|---|
| jupyfmt | The uncompromising Jupyter notebook formatter | Kim Philipp Jablonski | Descriptor |
| linkcheck | Plugin to check and validate markdown links exist and working | Shiran Rubin | Descriptor |
| nitpick | Command-line tool and flake8 plugin to enforce the same settings across multiple language-independent projects | W. Augusto Andreoli | Descriptor |
| mustache | Plugin to validate Logstash pipeline definition files using mustache | Yann Jouanique | Descriptor |
| salt-lint | Checks Salt State files (SLS) for best practices and behavior that could potentially be improved. | Joachim Grimm | Descriptor |
| docker-compose-linter | Plugin to lint docker-compose files | Wesley Dean | Descriptor |
| repolinter | Plugin to run TODO Group's repolinter to look for repository best practices | Wesley Dean | Descriptor |
| j2lint | Plugin to lint Jinja2 files | Wesley Dean | Descriptor |
| fmlint | Plugin to lint YAML frontmatter in Markdown documents | Wesley Dean | Descriptor |
Note: Using an external plugin means you trust its author.
Submit a Pull Request if you want your plugin to appear here :)
Add plugin URLs in the PLUGINS property of .mega-linter.yml. URLs must either begin with "https://" or take the form of "file://<path>", where <path> points to a valid plugin descriptor file.
Note: Both <path> and the default mount directory (/tmp/lint/<path>) will be checked for a valid descriptor.
PLUGINS:
- https://raw.githubusercontent.com/kpj/jupyfmt/master/mega-linter-plugin-jupyfmt/jupyfmt.megalinter-descriptor.yml
- file://.automation/test/mega-linter-plugin-test/test.megalinter-descriptor.ymlYou can implement your own descriptors and load them as plugins during MegaLinter runtime.
- Descriptor format is exactly the same as MegaLinter embedded ones (see JSON schema documentation)
- Plugin descriptor files must be named **.megalinter-descriptor.yml and conform to the MegaLinter JSON Schema
- Plugins must be hosted in a URL containing **/mega-linter-plugin-**/
- File URLs must conform to the same directory and file naming criteria as defined above.
- For now, the only
installattributes managed aredockerfileinstructions starting byRUN
| Article | Author |
|---|---|
| MegaLinter{target=_blank} | Stéphane Robert, 3DS OutScale{target=_blank} |
| MegaLinter: un linter pour les gouverner tous{target=_blank} | Guillaume Arnaud, WeScale{target=_blank} |
| MegaLinter, votre meilleur ami pour un code de qualité{target=_blank} | Thomas Sanson{target=_blank} |
| Article | Author |
|---|---|
| Try using MegaLinter{target=_blank} | Takashi Minayaga{target=_blank} |
- (Brazilian) MegaLinter: Como Automatizar a Qualidade do Código para Todas Plataformas, by Codando TV
- (FR) MegaLinter presentation at DevCon 20 / Programmez Magazine, by Nicolas Vuillamy
- Code quality - Ep01 - MegaLinter, one linter to rule them all, by Bertrand Thomas
- DevSecOps Webinar using MegaLinter, by 5.15 Technologies{target=_blank}
- Ortelius Architecture Meeting, with a review of MegaLinter, by Steve Taylor{target=_blank} from Ortelius
- analysis-tools.dev{target=_blank}
- awesome-linters{target=_blank}
- schemastore.org{target=_blank}
- abhith.net{target=_blank}
- my-devops-lab.com{target=_blank}
- checkmake{target=_blank}
- checkstyle{target=_blank}
- clj-kondo{target=_blank}
- cljstyle{target=_blank}
- cspell{target=_blank}
- detekt{target=_blank}
- djlint{target=_blank}
- dotenv-linter{target=_blank}
- editorconfig-checker{target=_blank}
- eslint{target=_blank}
- eslint-plugin-jsonc{target=_blank}
- hadolint{target=_blank}
- htmlhint{target=_blank}
- jscpd{target=_blank}
- kics{target=_blank}
- ktlint{target=_blank}
- lintr{target=_blank}
- npm-groovy-lint{target=_blank}
- npm-package-json-lint{target=_blank}
- pmd{target=_blank}
- rst-lint{target=_blank}
- rstcheck{target=_blank}
- rubocop{target=_blank}
- scalafix{target=_blank}
- secretlint{target=_blank}
- sfdx-scanner-apex{target=_blank}
- sfdx-scanner-aura{target=_blank}
- sfdx-scanner-lwc{target=_blank}
My repo CI already has linters and they're working perfectly, so why do I need MegaLinter?
You can continue using your installed linters and deactivate them in .mega-linter.yml. For example, in a JavaScript project using ESLint, configure MegaLinter with DISABLE: JAVASCRIPT. That way, you will benefit from both your installed linters and other MegaLinter linters checking JSON, YAML, Markdown, Dockerfile, Bash, spelling mistakes, dead URLs…
OK but… how does it work?
MegaLinter is based on Docker images containing either all linters, or a selection of linters if you use a MegaLinter flavor for a project with a specific language or format.
The core architecture does the following:
- Initialization
- List all project files:
- except files in ignored folders (
node_modules, etc…) - except files not matching
FILTER_REGEX_INCLUDE(if defined by user) - except files matching
FILTER_REGEX_EXCLUDE(if defined by user)
- except files in ignored folders (
- Collect files for each activated linter, matching their own filtering criteria:
- file extensions
- file names
- file content
<descriptor_or_linter_key>_FILTER_REGEX_INCLUDE(if defined by user)<descriptor_or_linter_key>_FILTER_REGEX_EXCLUDE(if defined by user)
- List all project files:
- Linting
- Parallelly, for each linter with matching files:
- Call the linter on matching files (or the whole project for some linters like copy-paste detector)
- Call activated linter-level reporters (GitHub Status Reporter…)
- Parallelly, for each linter with matching files:
- Finalization
- Call activated global level reporters (GitHub Pull Request Comment Reporter, File.io Reporter, Email Reporter…)
- Manage return code:
- 0 if no error (or only non blocking errors if user defined
DISABLE_ERRORSor<descriptor_or_linter_key>_DISABLE_ERRORS) - 1 if errors
- 0 if no error (or only non blocking errors if user defined
Contributions to MegaLinter are very welcome: the more we are, the stronger MegaLinter becomes! Please follow Contributing Guide
To help, you can also:
- ⭐ Star the repository
- 🍺 Offer a beer!
- report problems and request new features
- share on twitter{target=_blank}
MegaLinter wouldn't be what it is without its great team of maintainers!
MegaLinter obviously would not exist without its linters and libraries: many thanks to all the dedicated open-source teams maintaining these awesome linters!
MegaLinter has been built on the ashes of a rejected Pull Request{target=_blank} on GitHub Super-Linter{target=_blank}.
Even if I disagree with their decision to remain in Bash, the core team has always been nice and supportive during the time I was a Super-Linter contributor{target=_blank} :)
The hard fork of Super-Linter to Python isn't just a language switch: Python's flexibility and libraries enabled many additional features described below.
MegaLinter hides many environment variables when calling the linters.
That way you need to trust only MegaLinter core code with your secrets, not the 100+ embedded linters !
- MegaLinter flavors allow using smaller Docker images, reducing pull time.
- Thanks to Python multiprocessing, linters are run in parallel, which is much faster than Super-Linter's Bash script that runs all linters sequentially.
- When the linter allows it, call it once with N files, instead of calling it N times with one file.
- C, C++, Copy-Paste detection, Credentials, GraphQL, JSON & YAML with JSON schemas, Markdown tables formatting, Puppet, reStructuredText, Rust, Scala, Spell checker, Swift, Visual Basic .NET …
MegaLinter can automatically apply fixes performed by linters and push them to the same branch, or create a Pull Request that you can validate.
This is pretty handy, especially for linter errors related to formatting (in that case, you don't have any manual update to perform)
MegaLinter can be run locally thanks to mega-linter-runner.
- Accuracy: Count the total number of errors, not only the number of files in error.
- Show linter version and applied filters for each linter processed.
- Reports stored as artifacts on GitHub Actions runs or other remote files
- General log
- One report file by linter
- Assisted installation and configuration using a Yeoman generator and JSON schemas for the configuration file
- Configure include and exclude regexes for a single language or linter: e.g.,
JAVASCRIPT_FILTER_REGEX_INCLUDE (src) - Configure additional CLI arguments for a linter: e.g.,
JAVASCRIPT_ES_ARGUMENTS "--debug --env-info" - Configure non-blocking errors for a single language or linter: e.g.,
JAVASCRIPT_DISABLE_ERRORS - Simplified languages and linters variables
- ENABLE = list of languages and formats to apply lint on codebase (default: all)
- ENABLE_LINTERS = list of linters to apply lint on codebase (default: all)
- DISABLE = list of languages and formats to skip (default: none)
- DISABLE_LINTERS = list of linters to skip (default: none)
- Variables VALIDATE_XXX are still taken in account (but should not be used in association with ENABLE and DISABLE variables)
- One page per linter documentation:
- All variables that can be used with this linter
- List of file extensions, names and filters applied by the linter
- Link to MegaLinter default linter configuration
- Link to linter website
- Link to official page explaining how to customize the linter rules
- Link to official page explaining how to disable rules from source comments
- Examples of linter command line calls behind the hood
- Help command text
- Installation commands
- Installation links for related IDEs
- README
- Separate languages, formats, and tooling formats in the linters table
- Add logos for each descriptor
For less commonly used linters, MegaLinter offers a plugin architecture so anyone can publish plugins.
- Refactoring runtime in Python, for easier handling than Bash thanks to classes and Python modules
- Everything related to each linter is in a single descriptor YAML file
- Easier ongoing maintenance
- Fewer conflicts to manage between PRs
- A few special cases require a Python linter class)
- Default behaviors for all linters, with the possibility to override parts of them for special cases
- Hierarchical architecture: Apply fixes and new behaviors to all linters with a single code update
- Documentation as code
- Generate linters tables (ordered by type: language, format, and tooling format) and include them in the README. (see result)
- Generate one markdown file per linter, containing all configuration variables, information, and examples (see examples)
- Automatic generation of Dockerfiles using YAML descriptors, always using the linter's latest version
- Dockerfile commands (FROM, ARG, ENV, COPY, RUN)
- APK packages (Linux)
- NPM packages (Node.js)
- PIP packages (Python)
- GEM packages (Ruby)
- Phive packages (PHP)
- Have a centralized exclude list (node_modules, .rbenv, etc.)
- Test classes for each capability
- Test classes for each linter: automatic generation of test classes using .automation/build.py
- Set up code coverage
- Development CI/CD
- Validate multi-status on PR inside each PR (posted from step "Run against all code base")
- Run test classes and code coverage with pytest during validation GitHub Action
- Validate descriptor YML files with json schema during build
- Automated job to upgrade linters to their latest stable version
