MegaLinter in Azure DevOps

MegaLinter in Azure DevOps

Lint Terraform, Bicep, GH Action Workflows, ARM, Python, PowerShell, and more....

Play this article

What is MegaLinter

MegaLinter is an Open Source tool powered by OX Security. It can be used in CI/CD tools like Azure DevOps and installed on local devices. This post will focus on the CI/CD operation using Azure DevOps.

As of writing this, MegaLinter supports 55 languages, 24 formats, and 20 tooling formats. The tool checks codebases to make sure code is clean and formatted consistently and analyses for security concerns based on what it supports.

The tool has features, including the ability to output reports into multiple formats and post these reports into Pull Requests.

The Pipeline Template

The below template can be stored in its own YAML file called megalinter.yaml:

    - checkout: self

    - script: docker pull oxsecurity/megalinter:v7
      displayName: Pull MegaLinter

    - script: |
        docker run -v $(System.DefaultWorkingDirectory)/REPO:/tmp/lint \
            --env-file <(env | grep -e SYSTEM_ -e BUILD_ -e TF_ -e AGENT_) \
            -e SYSTEM_ACCESSTOKEN=$(System.AccessToken) \
            -e GIT_AUTHORIZATION_BEARER=$(System.AccessToekn) \
            -e MEGALINTER_CONFIG=.megalinter.yml \
       displayName: Run MegaLinter

You can then call the template within your actual pipeline configuration file. In the below example, my pipeline triggers on Pull Requests:

trigger: none

        - main


- stage: linter
  displayName: Linter
  - job: megalinter
    displayName: MegaLinter
        vmImage: 'ubuntu-latest'
    - template: mega-linter.yaml

Configuration File

Without the configuration file, MegaLinter will autodetect what it can lint. This is not 100% accurate, and you may not want to lint everything, for example, Markdown files. As such, you can use the configuration file you specify what to lint, and any custom settings for the linter.

The configuration file should be stored in the root of the repository and named .mega-linter.yml:



The above is an example of a basic configuration file where I have specified curtain linters to be enabled and enabled reports to be submitted as a comment in the Azure DevOps Pull Request. All the linters will use their default configuration to analyse the code.

Below is an example of specifying a Javascript ES config file:




Running the pipeline configured with either of these .mega-linter.yaml configuration files will post to the Azure DevOps Pull Request. If you don't want the report to post as a comment, you can set the AZURE_COMMENT_REPORTER to false. Without the report being commented on the PR, you will be able to visually see from the output logs a table containing the results of the analyses.

Did you find this article valuable?

Support James Cook by becoming a sponsor. Any amount is appreciated!