Repository files navigation

MegaLinter is anopen-source tool forCI/CD workflows that analyzes theconsistency of your code,IaC,configuration, andscripts in your repository toensure all your project sources are clean and formatted, no matter which IDE or toolbox is used by your developers. Powered byOX Security.

Supports68 languages,22 formats,21 tooling formats, and isready to use out of the box as a GitHub Action or with any CI system. It ishighly configurable andfree for all uses.

MegaLinter hasnative integrations with many major CI/CD tools.

Upgrade to MegaLinter v9 :):

• Use the newLLM Advisor that will tell you how to fix linters issues
• Create your ownMegaLinter Custom Flavors to improve performance

Before you go further, see theonline documentation website, which offers much easier navigation than this README

• Why MegaLinter
• Quick Start
• Supported Linters
  • Languages
  • Formats
  • Tooling formats
  • Other
• Installation
  • Assisted installation
  • Which version to use ?
  • GitHub Action
  • GitLab CI
  • Azure Pipelines
    • Single Repository
    • Central Repository
    • Pull Request Comments
    • Detailed Tutorial
  • Bitbucket Pipelines
  • Jenkins
  • Concourse
    • Pipeline step
    • Use it as a reusable task
  • Drone CI
    • (Optional) Adjusting trigger rules
  • Docker container
  • Run MegaLinter locally
• Configuration
  • .mega-linter.yml file
  • Common variables
  • Activation and deactivation
  • Filter linted files
  • Apply fixes
    • Apply fixes issues
    • Notes
  • Linter specific variables
  • Pre-commands
  • Post-commands
  • Environment variables security
    • Secured env variables
    • Secured configuration examples
    • Default secured variables
    • Unhide variables for linters
  • CLI lint mode
• Reporters
• Flavors
• Badge
  • Markdown
  • reStructuredText
• Plugins
  • External Plugins Catalog
  • Use external plugins
    • Example
  • Create your own plugin
    • Limitations
• They talk about MegaLinter
  • English articles
  • French articles
  • Videos
  • Web Sites
  • Linters
• Frequently Asked Questions
• How to contribute
• Special thanks
  • Maintainers
  • Contributors
  • Open-source teams
  • Super-Linter team
• License
• MegaLinter vs Super-Linter
  • Security
  • Performance
  • More languages and formats linted
  • Automatically apply formatting and fixes
  • Run locally
  • Reports
    • Capabilities
    • Additional Reporters
  • Enhanced configuration
  • Enhanced documentation
  • Plugin management
  • Simplify architecture and evolutionary maintenance
  • Improve robustness & stability

Projects need to contain clean code in order toavoid technical debt, which makesongoing maintenance harder and more time-consuming.

By usingcode formatters and code linters, you ensure that yourcodebase is easier to read andfollows 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 usingMegaLinter, you'll enjoy the following benefits for your team:

• Ateach pull request, itautomatically analyzes all updated code across all languages.
• By reading error logs,developers learn best practices for the languages they use.
• TheMegaLinter documentation provides alist of IDE plugins for each linter, so developers know which linter and plugins to install.
• MegaLinterworks out of the box after aquick setup.
• Formatting and fixes can be automaticallyapplied directly to the Git branch orprovided in reports.
• This tool is100% open source andfree for all uses (personal, professional, public, and private repositories).
• MegaLinter can run onany CI tool and berun locally:no need to authorize an external application, andyour codebase never leaves your tooling ecosystem.

• Runnpx mega-linter-runner --install to generate configuration files (you needNode.js installed).
• Commit, push, and create a pull request.
• Watch!

Notes:

• This repo is a hard fork ofGitHub Super-Linter, rewritten in Python to addmany additional features.
• If you are a Super-Linter user, you can transparentlyswitch to MegaLinter and keep the same configuration (just replacesuper-linter/super-linter@v3 withoxsecurity/megalinter@v9 in 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 theassisted installation.
• For a beginner-friendly example of getting started with MegaLinter, check outthis blog post by Alec Johnson.

All linters are integrated into theMegaLinter Docker image, which is frequently updated with their latest versions.

	Language	Linter	Additional
	BASH	bash-exec BASH_EXEC
	BASH	shellcheck BASH_SHELLCHECK
	BASH	shfmt BASH_SHFMT
	C	cppcheck C_CPPCHECK
	C	cpplint C_CPPLINT
	C	clang-format C_CLANG_FORMAT
	CLOJURE	clj-kondo CLOJURE_CLJ_KONDO
	CLOJURE	cljstyle CLOJURE_CLJSTYLE
	COFFEE	coffeelint COFFEE_COFFEELINT
	C++ (CPP)	cppcheck CPP_CPPCHECK
	C++ (CPP)	cpplint CPP_CPPLINT
	C++ (CPP)	clang-format CPP_CLANG_FORMAT
	C# (CSHARP)	dotnet-format CSHARP_DOTNET_FORMAT
	C# (CSHARP)	csharpier CSHARP_CSHARPIER
	C# (CSHARP)	roslynator CSHARP_ROSLYNATOR
	DART	dartanalyzer DART_DARTANALYZER
	GO	golangci-lint GO_GOLANGCI_LINT
	GO	revive GO_REVIVE
	GROOVY	npm-groovy-lint GROOVY_NPM_GROOVY_LINT
	JAVA	checkstyle JAVA_CHECKSTYLE
	JAVA	pmd JAVA_PMD
	JAVASCRIPT	eslint JAVASCRIPT_ES
	JAVASCRIPT	standard JAVASCRIPT_STANDARD
	JAVASCRIPT	prettier JAVASCRIPT_PRETTIER
	JSX	eslint JSX_ESLINT
	KOTLIN	ktlint KOTLIN_KTLINT
	KOTLIN	detekt KOTLIN_DETEKT
	LUA	luacheck LUA_LUACHECK
	LUA	selene LUA_SELENE
	LUA	stylua LUA_STYLUA
	MAKEFILE	checkmake MAKEFILE_CHECKMAKE
	PERL	perlcritic PERL_PERLCRITIC
	PHP	phpcs PHP_PHPCS
	PHP	phpstan PHP_PHPSTAN
	PHP	psalm PHP_PSALM
	PHP	phplint PHP_PHPLINT
	PHP	php-cs-fixer PHP_PHPCSFIXER
	POWERSHELL	powershell POWERSHELL_POWERSHELL
	POWERSHELL	powershell_formatter POWERSHELL_POWERSHELL_FORMATTER
	PYTHON	pylint PYTHON_PYLINT
	PYTHON	black PYTHON_BLACK
	PYTHON	flake8 PYTHON_FLAKE8
	PYTHON	isort PYTHON_ISORT
	PYTHON	bandit PYTHON_BANDIT
	PYTHON	mypy PYTHON_MYPY
	PYTHON	pyright PYTHON_PYRIGHT
	PYTHON	ruff PYTHON_RUFF
	PYTHON	ruff-format PYTHON_RUFF_FORMAT
	R	lintr R_LINTR
	RAKU	raku RAKU_RAKU
	RUBY	rubocop RUBY_RUBOCOP
	RUST	clippy RUST_CLIPPY
	SALESFORCE	code-analyzer-apex SALESFORCE_CODE_ANALYZER_APEX
	SALESFORCE	code-analyzer-aura SALESFORCE_CODE_ANALYZER_AURA
	SALESFORCE	code-analyzer-lwc SALESFORCE_CODE_ANALYZER_LWC
	SALESFORCE	sfdx-scanner-apex SALESFORCE_SFDX_SCANNER_APEX
	SALESFORCE	sfdx-scanner-aura SALESFORCE_SFDX_SCANNER_AURA
	SALESFORCE	sfdx-scanner-lwc SALESFORCE_SFDX_SCANNER_LWC
	SALESFORCE	lightning-flow-scanner SALESFORCE_LIGHTNING_FLOW_SCANNER
	SCALA	scalafix SCALA_SCALAFIX
	SQL	sqlfluff SQL_SQLFLUFF
	SQL	tsqllint SQL_TSQLLINT
	SWIFT	swiftlint SWIFT_SWIFTLINT
	TSX	eslint TSX_ESLINT
	TYPESCRIPT	eslint TYPESCRIPT_ES
	TYPESCRIPT	ts-standard TYPESCRIPT_STANDARD
	TYPESCRIPT	prettier TYPESCRIPT_PRETTIER
	Visual Basic .NET (VBDOTNET)	dotnet-format VBDOTNET_DOTNET_FORMAT

	Format	Linter	Additional
	CSS	stylelint CSS_STYLELINT
	ENV	dotenv-linter ENV_DOTENV_LINTER
	GRAPHQL	graphql-schema-linter GRAPHQL_GRAPHQL_SCHEMA_LINTER
	HTML	djlint HTML_DJLINT
	HTML	htmlhint HTML_HTMLHINT
	JSON	jsonlint JSON_JSONLINT
	JSON	eslint-plugin-jsonc JSON_ESLINT_PLUGIN_JSONC
	JSON	v8r JSON_V8R
	JSON	prettier JSON_PRETTIER
	JSON	npm-package-json-lint JSON_NPM_PACKAGE_JSON_LINT
	LATEX	chktex LATEX_CHKTEX
	MARKDOWN	markdownlint MARKDOWN_MARKDOWNLINT
	MARKDOWN	remark-lint MARKDOWN_REMARK_LINT
	MARKDOWN	markdown-table-formatter MARKDOWN_MARKDOWN_TABLE_FORMATTER
	PROTOBUF	protolint PROTOBUF_PROTOLINT
	RST	rst-lint RST_RST_LINT
	RST	rstcheck RST_RSTCHECK
	RST	rstfmt RST_RSTFMT
	XML	xmllint XML_XMLLINT
	YAML	prettier YAML_PRETTIER
	YAML	yamllint YAML_YAMLLINT
	YAML	v8r YAML_V8R

	Tooling format	Linter	Additional
	ACTION	actionlint ACTION_ACTIONLINT
	ANSIBLE	ansible-lint ANSIBLE_ANSIBLE_LINT
	API	spectral API_SPECTRAL
	ARM	arm-ttk ARM_ARM_TTK
	BICEP	bicep_linter BICEP_BICEP_LINTER
	CLOUDFORMATION	cfn-lint CLOUDFORMATION_CFN_LINT
	DOCKERFILE	hadolint DOCKERFILE_HADOLINT
	EDITORCONFIG	editorconfig-checker EDITORCONFIG_EDITORCONFIG_CHECKER
	GHERKIN	gherkin-lint GHERKIN_GHERKIN_LINT
	KUBERNETES	kubeconform KUBERNETES_KUBECONFORM
	KUBERNETES	helm KUBERNETES_HELM
	KUBERNETES	kubescape KUBERNETES_KUBESCAPE
	PUPPET	puppet-lint PUPPET_PUPPET_LINT
	ROBOTFRAMEWORK	robocop ROBOTFRAMEWORK_ROBOCOP
	SNAKEMAKE	snakemake SNAKEMAKE_LINT
	SNAKEMAKE	snakefmt SNAKEMAKE_SNAKEFMT
	TEKTON	tekton-lint TEKTON_TEKTON_LINT
	TERRAFORM	tflint TERRAFORM_TFLINT
	TERRAFORM	terrascan TERRAFORM_TERRASCAN
	TERRAFORM	terragrunt TERRAFORM_TERRAGRUNT
	TERRAFORM	terraform-fmt TERRAFORM_TERRAFORM_FMT

	Code quality checker	Linter	Additional
	COPYPASTE	jscpd COPYPASTE_JSCPD
	REPOSITORY	checkov REPOSITORY_CHECKOV
	REPOSITORY	devskim REPOSITORY_DEVSKIM
	REPOSITORY	dustilock REPOSITORY_DUSTILOCK
	REPOSITORY	git_diff REPOSITORY_GIT_DIFF
	REPOSITORY	gitleaks REPOSITORY_GITLEAKS
	REPOSITORY	grype REPOSITORY_GRYPE
	REPOSITORY	kics REPOSITORY_KICS
	REPOSITORY	ls-lint REPOSITORY_LS_LINT
	REPOSITORY	secretlint REPOSITORY_SECRETLINT
	REPOSITORY	semgrep REPOSITORY_SEMGREP
	REPOSITORY	syft REPOSITORY_SYFT
	REPOSITORY	trivy REPOSITORY_TRIVY
	REPOSITORY	trivy-sbom REPOSITORY_TRIVY_SBOM
	REPOSITORY	trufflehog REPOSITORY_TRUFFLEHOG
	SPELL	cspell SPELL_CSPELL
	SPELL	proselint SPELL_PROSELINT
	SPELL	vale SPELL_VALE
	SPELL	lychee SPELL_LYCHEE
	SPELL	codespell SPELL_CODESPELL

Just runnpx 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 (v9 , always corresponding to thelatest release)

• Docker image:oxsecurity/megalinter:v9
• GitHub Action:oxsecurity/megalinter@v9

You can also usebeta version (corresponding to the content of main branch)

• Docker image:oxsecurity/megalinter:beta
• GitHub Action:oxsecurity/megalinter@beta

1. Create a new file in your repository called.github/workflows/mega-linter.yml
2. Copy theexample workflow from below into that new file, no extra configuration required
3. Commit that file to a new branch
4. Open up a pull request and observe the action working
5. Enjoy your morestable, andcleaner code base

NOTES:

• If you pass theEnvironment variableGITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }} in your workflow, then theMegaLinter 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 theGitHub Secret as it's automatically set by GitHub, it only needs to be passed to the action.
• You can alsouse it outside of GitHub Actions (CircleCI, Azure Pipelines, Jenkins, GitLab, or even locally with a docker run) , and have status on Github Pull Request ifGITHUB_TARGET_URL environment variable exists.

In your repository you should have a.github/workflows folder withGitHub Action similar to below:

• .github/workflows/mega-linter.yml

---# MegaLinter GitHub Action configuration file# More info at https://megalinter.ioname:MegaLinteron:# Trigger mega-linter at every push. Action will also be visible from Pull Requests to mainpush:# 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 configurationAPPLY_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:truejobs:megalinter:name:MegaLinterruns-on:ubuntu-latestpermissions:# Give the default GITHUB_TOKEN write permission to commit and push, comment issues & post new PR# Remove the ones you do not needcontents:writeissues:writepull-requests:writesteps:# Git Checkout      -name:Checkout Codeuses:actions/checkout@v6with: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:MegaLinterid:ml# You can override MegaLinter flavor used to have faster performances# More info at https://megalinter.io/flavors/# MAJOR-RELEASE-IMPACTEDuses:oxsecurity/megalinter@v9env:# 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 sourcesGITHUB_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 artifactsif:success() || failure()uses:actions/upload-artifact@v4with:name:MegaLinter reportspath:|            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 fixesid:cprif: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@v7with:token:${{ secrets.PAT || secrets.GITHUB_TOKEN }}commit-message:"[MegaLinter] Apply linters automatic fixes"title:"[MegaLinter] Apply linters automatic fixes"labels:bot      -name:Create PR outputif: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 commitif: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 fixesif: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@v7with:branch:${{ github.event.pull_request.head.ref || github.head_ref || github.ref }}commit_message:"[MegaLinter] Apply linters fixes"commit_user_name:megalinter-botcommit_user_email:129584137+megalinter-bot@users.noreply.github.com

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:v9script:[ "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 REPOSITORYartifacts:when:alwayspaths:      -megalinter-reportsexpire_in:1 week

Create a Gitlab access token and define it in a variableGITLAB_ACCESS_TOKEN_MEGALINTER in the project CI/CD masked variables. Make sure your token (e.g. if a project token) as the appropriaterole for commenting a merge request (at least developer).

Use the following Azure PipelinesYAML template

You can configure abuild 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 anazure-pipelines.yaml file within your code repository:

# Run MegaLinter to detect linting and security issues  -job:MegaLinterpool:vmImage:ubuntu-lateststeps:# Checkout repo      -checkout:self# Pull MegaLinter docker image      -script:docker pull oxsecurity/megalinter:v9displayName: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@1condition:succeededOrFailed()displayName:Upload MegaLinter reportsinputs:targetPath:"$(System.DefaultWorkingDirectory)/megalinter-reports/"artifactName:MegaLinterReport

Add the following to anazure-pipelines.yaml file within a separate repository, for example a 'MegaLinter' repository:

# Run MegaLinter to detect linting and security issuestrigger:nonepool:vmImage:ubuntu-latestvariables: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:v9displayName: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@1condition:succeededOrFailed()displayName:MegaLinter Reportinputs:targetPath:$(System.DefaultWorkingDirectory)/megalinter-reports/artifactName:MegaLinterReport

To enable Pull Request comments, follow theconfiguration 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 thisexample for guidance.

You can also follow thisdetailed tutorial byDonKoning.

1. Create abitbucket-pipelines.yml file at the root of your repository.

2. Copy and paste the following template or add the step to your existing pipeline.

image:atlassian/default-image:3pipelines:default:    -parallel:      -step:name:Run MegaLinterimage:oxsecurity/megalinter:v9script:            -export DEFAULT_WORKSPACE=$BITBUCKET_CLONE_DIR && bash /entrypoint.shartifacts:            -megalinter-reports/**

Add the following stage to your Jenkinsfile.

You may activate theFile.io reporter orEmail 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=''"            reuseNodetrue        }    }    steps {        sh'/entrypoint.sh'    }    post {        always {            archiveArtifactsallowEmptyArchive: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 ajob.plan.get step that retrieves therepo containing your repository, as shown in the example.

---  -name:lintingplan:      -get:repo      -task:lintingconfig:platform:linuximage_resource:type:docker-imagesource:repository:oxsecurity/megalintertag:v9inputs:            -name:reporun:path:bashargs:            --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: true

OR

Create a reusable Concourse task that can be used with multiple pipelines.

1. Create task filetask-linting.yaml

---platform:linuximage_resource:type:docker-imagesource:repository:oxsecurity/megalintertag:v9inputs:-name:repo## uncomment this if you want reports as task output# output:# - name: reports#   path: repo/megalinter-reportsrun:path:bashargs:  --cxe  -|    cd repo    export DEFAULT_WORKSPACE=$(pwd)    bash -ex /entrypoint.sh

2. Use thattask-linting.yaml task in your pipeline.

Note:

1. Make suretask-linting.yaml is available in therepo input at the repository root.

2. Taskoutput isnot shown here.

resources:  -name:lintingplan:      -get:repo      -task:lintingfile:repo/task-linting.yaml# params:#   PARALLEL: true#   DISABLE: SPELL#   APPLY_FIXES: all#   DISABLE_ERRORS: true#   VALIDATE_ALL_CODEBASE: true

Warning: Drone CI support is experimental and is undergoing significant modifications (see issue#2047).

1. Create a.drone.yml file on the root directory of your repository

2. Copy and paste the following template:

kind:pipelinetype:dockername:MegaLinterworkspace:path:/tmp/lintsteps:-name:megalinterimage:oxsecurity/megalinter:v9environment:DEFAULT_WORKSPACE:/tmp/lint

This uses theDrone 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:pipelinetype:dockername:MegaLinterworkspace:path:/tmp/lintsteps:-name:megalinterimage:oxsecurity/megalinter:v9environment:DEFAULT_WORKSPACE:/tmp/linttrigger:event:  -push

The workflow above triggers only on push, and not in other situations. For more information about configuring Drone CI trigger rules, see thedocumentation.

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

Usemega-linter-runner to run MegaLinter locally with the same configuration defined in your.mega-linter.yml file.

See themega-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 withenvironment 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 theJSON schema stored onschemastore.org.

• VS Code: You need an extension likeRed 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.yml file, priority is given to the ENV variable.

MegaLinter has all linters enabled by default, but allows enabling or disabling specific ones.

• IfENABLE isn't set, all descriptors are activated by default. If set, all linters of listed descriptors are activated by default.
• IfENABLE_LINTERS is set, only the listed linters are processed.
• IfDISABLE is set, the linters in the listed descriptors are skipped.
• IfDISABLE_LINTERS is set, the listed linters are skipped.
• IfDISABLE_ERRORS_LINTERS is set, the listed linters will run, but if errors are found, they will be considered non-blocking.
• IfENABLE_ERRORS_LINTERS is 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,GROOVYDISABLE_LINTERS:JAVASCRIPT_STANDARDDISABLE_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_PSALM

If you need to lint only a folder or exclude some files from linting, you can use the optional environment parametersFILTER_REGEX_INCLUDE andFILTER_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 modeproject (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:all to 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 ofUpdated sources reporter)
• APPLY_FIXES_MODE:commit to create a new commit and push it on the same branch, orpull_request to 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 withContents: Read/Write, then copy the PAT value
  • Define environment secret variable namedPAT 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 namedPAT on your repository, and paste the PAT value

• You can use theUpdated 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_EVENT andAPPLY_FIXES_MODE cannot be defined in the.mega-linter.yml config file; they must be set as environment variables.
• If you useAPPLY_FIXES, add the following line to your.gitignore file:

megalinter-reports/

See variables related to a single linter behavior inlinters 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-whatevercwd:root# Will be run at the root of the MegaLinter Docker imagesecured_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-complexityvenv: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

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 testcwd:"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 yourCI/CD pipelines, the Docker image may haveaccess 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 totrust 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 propertySECURED_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 forPRE_COMMANDS, and only if you definesecured_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_KEY

If you overrideSECURED_ENV_VARIABLES_DEFAULT, it replaces the default list, so it's better to only defineSECURED_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 regex

Each 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 processed
• project: 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 it
• file: 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 thelinters documentation).

• Linters that default to thefile lint mode cannot be overridden to use thelist_of_files lint mode.
• Linters that default to theproject lint mode cannot be overridden to use either thelist_of_files orfile lint modes.

Allowingfile orlist_of_files to be overridden toproject 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 theproject lint mode ignore variables likeFILTER_REGEX_INCLUDE andFILTER_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, theSecretlint linter ignores files listed in~/.secretlintignore by default, or it can be configured to instead ignore files listed in~/.gitignore by settingREPOSITORY_SECRETLINT_ARGUMENTS to--secretlintignore .gitignore.

MegaLinter can generate various reports that you can activate or deactivate and customize.

To improve run performance, we provideflavored 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 fromMegaLinter v4 & v5 images.

	Flavor	Description	Embedded linters	Info
	all	Default MegaLinter Flavor	131
	c_cpp	Optimized for pure C/C++ projects	57
	ci_light	Optimized for CI items (Dockerfile, Jenkinsfile, JSON/YAML schemas,XML	22
	cupcake	MegaLinter for the most commonly used languages	89
	documentation	MegaLinter for documentation projects	50
	dotnet	Optimized for C, C++, C# or VB based projects	65
	dotnetweb	Optimized for C, C++, C# or VB based projects with JS/TS	74
	formatters	Contains only formatters	18
	go	Optimized for GO based projects	52
	java	Optimized for JAVA based projects	55
	javascript	Optimized for JAVASCRIPT or TYPESCRIPT based projects	60
	php	Optimized for PHP based projects	55
	python	Optimized for PYTHON based projects	66
	ruby	Optimized for RUBY based projects	51
	rust	Optimized for RUST based projects	51
	salesforce	Optimized for Salesforce based projects	57
	security	Optimized for security	24
	swift	Optimized for SWIFT based projects	51
	terraform	Optimized for TERRAFORM based projects	55

If you need a new flavor,post an issue 😉

You can also generate your owncustom 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 namedmaster, replacemain withmaster in the URLs.

• Format

[![MegaLinter](https://github.com/<OWNER>/<REPOSITORY>/workflows/MegaLinter/badge.svg?branch=main)](https://github.com/<OWNER>/<REPOSITORY>/actions?query=workflow%3AMegaLinter+branch%3Amain)

• Example

[![MegaLinter](https://github.com/nvuillam/npm-groovy-lint/workflows/MegaLinter/badge.svg?branch=main)](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%3Amain

Note: IF you did not useMegaLinter as GitHub Action name, please readGitHub 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!

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 thePLUGINS 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.yml

You can implement your own descriptors and load them as plugins during MegaLinter runtime.

• Descriptor format is exactly the same asMegaLinter embedded ones (see JSON schema documentation)
• Plugin descriptor files must be named**.megalinter-descriptor.yml and conform to theMegaLinter 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 onlyinstall attributes managed aredockerfile instructions starting byRUN

• (Brazilian) Qualidade e Segurança em Código com MegaLinter: automatizando análises em MAUI com GitHub Actions, byCanal dotNET

• (Brazilian) MegaLinter: Como Automatizar a Qualidade do Código para Todas Plataformas, byCodando TV

• How to: Secrets scanning, byHackitect's playground

• How to use MegaLinter with Jenkins, byDarin Pope /Cloudbees

• (FR) MegaLinter presentation atDevCon 20 / Programmez Magazine, byNicolas Vuillamy

• Code quality - Ep01 - MegaLinter, one linter to rule them all, byBertrand Thomas

• DevSecOps Webinar using MegaLinter, by5.15 Technologies{target=_blank}

• Ortelius Architecture Meeting, with a review of MegaLinter, bySteve Taylor{target=_blank} fromOrtelius

• 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}

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 withDISABLE: 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 matchingFILTER_REGEX_INCLUDE (if defined by user)
    • except files matchingFILTER_REGEX_EXCLUDE (if defined by user)
  • Collect files for each activated linter, matching theirown 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)
• Linting
  • Parallelly, foreach linter with matching files:
    • Call the linter on matching files (or the whole project for some linters like copy-paste detector)
    • Call activatedlinter-level reporters (GitHub Status Reporter…)
• Finalization
  • Call activatedglobal 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 definedDISABLE_ERRORS or<descriptor_or_linter_key>_DISABLE_ERRORS)
    • 1 if errors

Contributions to MegaLinter are very welcome: the more we are, the stronger MegaLinter becomes!Please followContributing 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!

• Kurt Von Laven
• Borja Dominguez
• Edouard Choiniere
• Nicolas Vuillamy (Creator)

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 arejected Pull Request{target=_blank} onGitHub Super-Linter{target=_blank}.

Even if I disagree with their decision to remain in Bash, the core team has always been nice and supportiveduring the time I was a Super-Linter contributor{target=_blank} :)

• GNU Affero General Public License

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.

MegaLinterhides 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 canautomatically 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 tomega-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

• Console

• Text files
• GitHub Pull Request comments

• Gitlab Merge Request comments

• Bitbucket Pull Request comments

• Azure Pull Request comments

• Markdown Summary

• Updated sources
• Email
• File.io

• 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)

• HTML documentation

• One page per linter documentation:
  • All variables that can be used with this linter
  • List offile extensions, names and filters applied by the linter
  • Link to MegaLinter default linter configuration
  • Link to linter website
  • Link to official page explaininghow to customize the linter rules
  • Link to official page explaininghow 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 toclasses and Python modules
• Everything related to each linter is in asingle descriptor YAML file
  • Easier ongoing maintenance
  • Fewer conflicts to manage between PRs
  • A few special cases require aPython 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