MegaLinter, by

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, no matter which IDE or toolbox is used by your developers. Powered by OX Security.

Supports 66 languages, 24 formats, 21 tooling formats, and is ready to use out of the box as a GitHub Action or with any CI system. It is highly configurable and free for all uses.

MegaLinter has native integrations with popular CI/CD tools and is compliant with most Coding Agents.

• Use the new LLM Advisor that will tell you how to fix linters issues
• Create your own MegaLinter Custom Flavors to improve performance

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

Table of Contents

• Why MegaLinter
• Quick Start
• Coding Agents
• Supported Linters
  • Languages
  • Formats
  • Tooling formats
  • Other
• Installation
  • Coding agents (skills)
  • Coding Agents (Plugins)
  • 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

Why MegaLinter

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.

Join a continuously growing community: MegaLinter Docker images are pulled hundreds of thousands of times every month.

Quick Start

• With a coding agent: install the MegaLinter agent skills with npx skills add oxsecurity/megalinter/skills, then ask your agent to "setup megalinter".
• Or with the interactive wizard: run npx mega-linter-runner --install to 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@v3 with oxsecurity/megalinter@v10 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 the assisted installation.
• For a beginner-friendly example of getting started with MegaLinter, check out this blog post by Alec Johnson.

Coding Agents

MegaLinter is designed to work hand in hand with your coding agent:

Get started

Install the MegaLinter agent skills at the root of your repository:

With Claude Code (the skills are copied directly into .claude/skills/):

npx skills add oxsecurity/megalinter/skills -s '*' -a claude-code -y

With another coding agent, replace claude-code with your agent's identifier (cursor, github-copilot, codex, antigravity, opencode... full list in the skills CLI documentation) — or let the CLI detect your installed agents and install the skills for all of them at once:

npx skills add oxsecurity/megalinter/skills -s '*' -y --copy

Then just talk to your agent:

• "Setup MegaLinter on this repo"
• "Run MegaLinter and fix the errors"
• "Why is the MegaLinter CI job failing? Fix it"

What the skills do

Sub-agents orchestration

On agents supporting sub-agents (Claude Code, OpenCode, GitHub Copilot custom agents...), megalinter-setup installs three sub-agents that keep large CI logs and linter outputs out of your main agent's context, and run on low-cost models when possible:

flowchart TD
    U(["👤 You: <i>run megalinter and fix the errors</i>"]) --> O["🎯 megalinter<br/>(orchestrator skill)"]
    O -->|"no config found"| S["🛠️ megalinter-setup"]
    S -->|"npx mega-linter-runner --install"| CFG[/".mega-linter.yml<br/>+ CI workflow"/]
    O --> C["🔍 megalinter-check"]
    C -->|"watch mode"| W[["👀 megalinter-watcher<br/>sub-agent, low-cost model"]]
    W --> CI[/"CI job logs<br/>GitHub / GitLab / Azure / Bitbucket"/]
    C -->|"local mode"| RUN[["🐳 megalinter-runner<br/>sub-agent, low-cost model"]]
    RUN --> IMG[/"MegaLinter Docker image<br/>docker or podman"/]
    W --> ERR[/"📋 Compact error list<br/>grouped by linter"/]
    RUN --> ERR
    ERR --> F["🔧 megalinter-fix"]
    F -->|"one sub-agent per failing linter,<br/>in parallel"| FX1[["🤖 megalinter-fixer<br/>+ python_ruff fix guide"]]
    F --> FX2[["🤖 megalinter-fixer<br/>+ markdown_markdownlint fix guide"]]
    FX1 --> RES[/"✏️ Fixed files<br/>+ proposed rule disables"/]
    FX2 --> RES
    RES -->|"you confirm disables"| RC["♻️ Targeted re-check<br/>parallel standalone linter images"]
    RC -->|"errors remain (max 3 loops)"| F
    RC -->|"clean"| DONE(["✅ Commit on a branch<br/>(never on main)"])

    classDef user fill:#e8f5e9,stroke:#2e7d32,stroke-width:2px,color:#1b5e20
    classDef skill fill:#ede7f6,stroke:#5e35b1,stroke-width:2px,color:#311b92
    classDef subagent fill:#e3f2fd,stroke:#1976d2,stroke-width:2px,color:#0d47a1
    classDef artifact fill:#fff8e1,stroke:#f9a825,stroke-width:1px,color:#5d4037
    classDef recheck fill:#e0f2f1,stroke:#00897b,stroke-width:2px,color:#004d40

    class U,DONE user
    class O,S,C,F skill
    class W,RUN,FX1,FX2 subagent
    class CFG,CI,IMG,ERR,RES artifact
    class RC recheck

The fix guides combine information generated from the linter descriptors (auto-fix support, rules documentation URLs, MegaLinter tuning variables) with curated fix, inline-disable and ignore instructions grounded in each linter's official documentation.

Safety rules

• Safe fixes are applied automatically; ambiguous ones are asked to you
• Disabling a linter or a rule always requires your confirmation
• Commits are never pushed to the default branch

See also the installation page for coding agents, or install everything at once as an agent plugin.

Supported Linters

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

Languages

	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
	JAVASCRIPT	biome JAVASCRIPT_BIOME
	JSX	eslint JSX_ESLINT
	JSX	biome JSX_BIOME
	KOTLIN	ktlint KOTLIN_KTLINT
	KOTLIN	detekt KOTLIN_DETEKT
	LUA	luacheck LUA_LUACHECK
	LUA	stylua LUA_STYLUA
	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	nbqa PYTHON_NBQA_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	code-analyzer-flow SALESFORCE_CODE_ANALYZER_FLOW
	SCALA	scalafix SCALA_SCALAFIX
	SQL	sqlfluff SQL_SQLFLUFF
	SWIFT	swiftlint SWIFT_SWIFTLINT
	TSX	eslint TSX_ESLINT
	TSX	biome TSX_BIOME
	TYPESCRIPT	eslint TYPESCRIPT_ES
	TYPESCRIPT	ts-standard TYPESCRIPT_STANDARD
	TYPESCRIPT	prettier TYPESCRIPT_PRETTIER
	TYPESCRIPT	biome TYPESCRIPT_BIOME
	Visual Basic .NET (VBDOTNET)	dotnet-format VBDOTNET_DOTNET_FORMAT

Formats

	Format	Linter	Additional
	CSS	stylelint CSS_STYLELINT
	CSS	biome CSS_BIOME
	ENV	dotenv-linter ENV_DOTENV_LINTER
	GRAPHQL	graphql-schema-linter GRAPHQL_GRAPHQL_SCHEMA_LINTER
	GRAPHQL	biome GRAPHQL_BIOME
	HTML	djlint HTML_DJLINT
	HTML	htmlhint HTML_HTMLHINT
	JSON	jsonlint JSON_JSONLINT
	JSON	v8r JSON_V8R
	JSON	prettier JSON_PRETTIER
	JSON	npm-package-json-lint JSON_NPM_PACKAGE_JSON_LINT
	JSON	biome JSON_BIOME
	LATEX	chktex LATEX_CHKTEX
	MARKDOWN	markdownlint MARKDOWN_MARKDOWNLINT
	MARKDOWN	markdown-table-formatter MARKDOWN_MARKDOWN_TABLE_FORMATTER
	MARKDOWN	rumdl MARKDOWN_RUMDL
	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 formats

	Tooling format	Linter	Additional
	ACTION	actionlint ACTION_ACTIONLINT
	ACTION	zizmor ACTION_ZIZMOR
	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
	ROBOTFRAMEWORK	robocop ROBOTFRAMEWORK_ROBOCOP
	SNAKEMAKE	snakemake SNAKEMAKE_LINT
	SNAKEMAKE	snakefmt SNAKEMAKE_SNAKEFMT
	TEKTON	tekton-lint TEKTON_TEKTON_LINT
	TERRAFORM	tflint TERRAFORM_TFLINT
	TERRAFORM	terragrunt TERRAFORM_TERRAGRUNT
	TERRAFORM	terraform-fmt TERRAFORM_TERRAFORM_FMT
	TERRAFORM	tofu-fmt TERRAFORM_TOFU_FMT

Other

	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	betterleaks REPOSITORY_BETTERLEAKS
	REPOSITORY	grype REPOSITORY_GRYPE
	REPOSITORY	ls-lint REPOSITORY_LS_LINT
	REPOSITORY	osv-scanner REPOSITORY_OSV_SCANNER
	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
	REPOSITORY	kingfisher REPOSITORY_KINGFISHER
	SPELL	cspell SPELL_CSPELL
	SPELL	proselint SPELL_PROSELINT
	SPELL	vale SPELL_VALE
	SPELL	lychee SPELL_LYCHEE
	SPELL	codespell SPELL_CODESPELL

Installation

Coding agents (skills)

MegaLinter ships agent skills making it easy to drive from coding agents like Claude Code, Cursor CLI, GitHub Copilot CLI, Codex, Antigravity or OpenCode:

With Claude Code (the skills are copied directly into .claude/skills/):

npx skills add oxsecurity/megalinter/skills -s '*' -a claude-code -y

With another coding agent, replace claude-code with your agent's identifier (cursor, github-copilot, codex, antigravity, opencode... full list in the skills CLI documentation) — or let the CLI detect your installed agents and install the skills for all of them at once:

npx skills add oxsecurity/megalinter/skills -s '*' -y --copy

Then just ask your agent to "setup megalinter" or "run megalinter and fix the errors". The skills handle:

• megalinter-setup: install or upgrade MegaLinter on the repository (non-interactive npx mega-linter-runner --install)
• megalinter-check: watch MegaLinter CI jobs (GitHub Actions, GitLab CI, Azure Pipelines, Bitbucket Pipelines) or run locally with Docker
• megalinter-fix: apply fixes guided by per-linter fix guides, with user confirmation before disabling anything or pushing
• megalinter: orchestrate the whole check → fix → re-check loop

On coding agents supporting sub-agents (Claude Code, OpenCode, GitHub Copilot custom agents...), dedicated MegaLinter sub-agents (running on low-cost models) watch CI jobs and digest linter outputs to keep large logs out of your agent's context, and fix several linters in parallel.

Coding Agents (Plugins)

The MegaLinter agent skills are also published as an agent plugin, so a single command installs all four skills at once, and keeps them updated.

Claude Code

/plugin marketplace add oxsecurity/megalinter
/plugin install megalinter@megalinter

The three MegaLinter sub-agents are installed with the plugin, so there is nothing else to set up.

Cursor

Add https://github.com/oxsecurity/megalinter as a plugin source from Customize → Plugins, then install MegaLinter. The sub-agents ship with the plugin.

GitHub Copilot

copilot plugin marketplace add oxsecurity/megalinter
copilot plugin install megalinter@megalinter

Codex

codex plugin marketplace add oxsecurity/megalinter

Then install MegaLinter from the /plugins browser.

Gemini CLI and Antigravity

gemini extensions install https://github.com/oxsecurity/megalinter

Other coding agents

Every other agent (Windsurf, Cline, Roo Code, Amp, OpenCode, Goose, OpenHands...) is covered by the skills installation with npx skills add oxsecurity/megalinter/skills.

Once installed, just ask your agent to "setup megalinter" or "run megalinter and fix the errors".

Assisted installation

Two assisted ways to setup MegaLinter on your repository:

• With a coding agent: install the MegaLinter agent skills with npx skills add oxsecurity/megalinter/skills, then ask your agent to "setup megalinter".
• With the interactive wizard: 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 :)

Which version to use ?

Docker registry change (since v9.5.0): MegaLinter Docker images are published only to GitHub Container Registry (ghcr.io). The Docker Hub registry (docker.io/oxsecurity/megalinter, formerly oxsecurity/megalinter:*) is frozen at v9.4.0 until we implement OIDC-based publishing to Docker Hub. Docker Hub does not have v10 images: if you pull oxsecurity/megalinter from Docker Hub you will stay on v9.4.0. To get v10, switch your image: / docker pull references to ghcr.io/oxsecurity/megalinter:v10 (same applies to :beta and all flavor tags like ghcr.io/oxsecurity/megalinter-python:v10). GitHub Action users (uses: oxsecurity/megalinter@v10) are not affected, as the action already pulls from ghcr.io.

The following instructions examples are using latest MegaLinter stable version (v10 , always corresponding to the latest release)

• Docker image: ghcr.io/oxsecurity/megalinter:v10
• GitHub Action: oxsecurity/megalinter@v10

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

• Docker image: ghcr.io/oxsecurity/megalinter:beta
• GitHub Action: oxsecurity/megalinter@beta

GitHub Action

1. Create a new file in your repository called .github/workflows/mega-linter.yml
2. Copy the example 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 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_URL environment variable exists.

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

• .github/workflows/mega-linter.yml

---
# 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

permissions: {}

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@v6
        with:
          # SECURITY NOTE: Using a Personal Access Token (PAT) is NOT
          # recommended. Open-source projects have been heavily targeted by
          # supply-chain attacks in recent months, and a leaked PAT can give
          # attackers broad write access to your repository: better safe
          # than sorry! If you only need workflows to re-trigger after
          # MegaLinter applies fixes, prefer one of these safer alternatives:
          #   - Manually re-run the workflow from the GitHub Actions tab, or
          #   - Push another commit on the branch to trigger workflows again.
          # Only define `secrets.PAT` if you fully understand the trade-off.
          token: ${{ secrets.PAT || secrets.GITHUB_TOKEN }}
          persist-credentials: false # Comment this line and uncomment the next one if you use APPLY_FIXES
          # persist-credentials: true # zizmor: ignore[artipacked]
          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/
        # MAJOR-RELEASE-IMPACTED
        uses: oxsecurity/megalinter@v10
        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@v7
        with:
          name: MegaLinter reports
          include-hidden-files: "true"
          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@v8
        with:
          # SECURITY NOTE: see the warning on the checkout step above —
          # using `secrets.PAT` is NOT recommended for security reasons.
          # Prefer manually re-running the workflow or pushing another
          # commit on the branch to trigger workflows again.
          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')
        env:
          PR_NUMBER: ${{ steps.cpr.outputs.pull-request-number }}
          PR_URL: ${{ steps.cpr.outputs.pull-request-url }}
        run: |
          echo "Pull Request Number - ${PR_NUMBER}"
          echo "Pull Request URL - ${PR_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@v7
        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: 129584137+megalinter-bot@users.noreply.github.com

GitLab CI

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: ghcr.io/oxsecurity/megalinter:v10
  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 week

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

Azure Pipelines

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.

Single 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 ghcr.io/oxsecurity/megalinter:v10
        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) \
            ghcr.io/oxsecurity/megalinter:v10
        displayName: Run MegaLinter

      # Upload MegaLinter reports
      - task: PublishPipelineArtifact@1
        condition: succeededOrFailed()
        displayName: Upload MegaLinter reports
        inputs:
          targetPath: "$(System.DefaultWorkingDirectory)/megalinter-reports/"
          artifactName: MegaLinterReport

Central Repository

Add 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 ghcr.io/oxsecurity/megalinter:v10
    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) \
        ghcr.io/oxsecurity/megalinter:v10
    displayName: Run MegaLinter

  # Upload MegaLinter reports
  - task: PublishPipelineArtifact@1
    condition: succeededOrFailed()
    displayName: MegaLinter Report
    inputs:
      targetPath: $(System.DefaultWorkingDirectory)/megalinter-reports/
      artifactName: MegaLinterReport

Pull Request Comments

To 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.

Detailed Tutorial

You can also follow this detailed tutorial by DonKoning.

Alternative: Azure DevOps Extension (Community)

Note: This is a community-maintained extension and is not affiliated with or maintained by the MegaLinter team.

As an alternative to the manual Docker configuration above, the community-maintained megalinter-ado Azure DevOps extension provides a native Azure Pipelines task for running MegaLinter.

Install from the Visual Studio Marketplace, then add the task to your pipeline:

- task: MegaLinter@1
  displayName: Run MegaLinter
  inputs:
    flavor: all
    fix: true
    createFixPR: true
  env:
    SYSTEM_ACCESSTOKEN: $(System.AccessToken)

See the extension repository for full configuration options.

Bitbucket Pipelines

1. Create a bitbucket-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:3
pipelines:
  default:
    - parallel:
      - step:
          name: Run MegaLinter
          image: ghcr.io/oxsecurity/megalinter:v10
          script:
            - export DEFAULT_WORKSPACE=$BITBUCKET_CLONE_DIR && bash /entrypoint.sh
          artifacts:
            -  megalinter-reports/**

Jenkins

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 'ghcr.io/oxsecurity/megalinter:v10'
            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!

PR Comment Reporting from Jenkins

When MegaLinter runs from a Jenkins Multibranch Pipeline, it can automatically post results as comments on pull requests / merge requests hosted on GitHub, GitLab, Azure DevOps, or Bitbucket.

MegaLinter auto-detects the git hosting platform by inspecting the GIT_URL environment variable (provided by Jenkins Git plugin). It then maps Jenkins environment variables (CHANGE_ID, GIT_COMMIT, BUILD_URL, etc.) to the native CI variables each comment reporter expects.

Requirements

• Jenkins Multibranch Pipeline with the appropriate Branch Source plugin (GitHub Branch Source, GitLab Branch Source, or Bitbucket Branch Source)
• The pipeline must be triggered by a pull request / merge request (so CHANGE_ID is set by Jenkins)
• An authentication token for the target platform, stored as a Jenkins credential

Platform Configuration

Jenkinsfile Example with GitHub PR Comments

// Lint with MegaLinter: https://megalinter.io/
stage('MegaLinter') {
    agent {
        docker {
            image 'ghcr.io/oxsecurity/megalinter:v10'
            args "-u root -e VALIDATE_ALL_CODEBASE=true -v ${WORKSPACE}:/tmp/lint --entrypoint=''"
            reuseNode true
        }
    }
    environment {
        GITHUB_TOKEN = credentials('github-token')
    }
    steps {
        sh '/entrypoint.sh'
    }
    post {
        always {
            archiveArtifacts allowEmptyArchive: true, artifacts: 'mega-linter.log,megalinter-reports/**/*', defaultExcludes: false, followSymlinks: false
        }
    }
}

Self-hosted / On-premise Platforms

MegaLinter detects the platform by looking for keywords in the GIT_URL hostname (e.g., gitlab.mycompany.com is detected as GitLab, github.internal.corp.com as GitHub).

If your self-hosted instance uses a hostname without the platform name (e.g., git.mycompany.com), set the JENKINS_REPO_PLATFORM environment variable to explicitly tell MegaLinter which platform to use:

environment {
    JENKINS_REPO_PLATFORM = 'gitlab'  // or 'github', 'azure', 'bitbucket'
    GITLAB_ACCESS_TOKEN_MEGALINTER = credentials('gitlab-token')
}

Additional Variables

For most setups, MegaLinter derives all needed variables automatically. In rare cases, you may need to set additional platform-specific variables:

• GitLab: Set CI_PROJECT_ID if the project path cannot be parsed from GIT_URL
• Azure DevOps: Set SYSTEM_ACCESSTOKEN as a Jenkins credential

Concourse

Pipeline step

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: v10
          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: true

OR

Use it as a reusable task

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

1. Create task file task-linting.yaml

---
platform: linux
image_resource:
  type: docker-image
  source:
    repository: oxsecurity/megalinter
    tag: v10

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

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

Note:

1. Make sure task-linting.yaml is available in the repo input at the repository root.

2. Task output is 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: true

Drone CI

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: pipeline
type: docker
name: MegaLinter

workspace:
  path: /tmp/lint

steps:

- name: megalinter
  image: ghcr.io/oxsecurity/megalinter:v10
  environment:
    DEFAULT_WORKSPACE: /tmp/lint

This uses the Drone CI Docker runner, so you need to install and configure it beforehand on your Drone CI server.

(Optional) Adjusting trigger rules

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: ghcr.io/oxsecurity/megalinter:v10
  environment:
    DEFAULT_WORKSPACE: /tmp/lint

trigger:
  event:
  - push

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

Docker container

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 ghcr.io/oxsecurity/megalinter:v10

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 ghcr.io/oxsecurity/megalinter:v10

Run MegaLinter locally

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.

Configuration

.mega-linter.yml file

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.yml file, priority is given to the ENV variable.

Common variables