Everything you need to know about GitHub Super Linter

Table of Contents

This article explains everything about GitHub Super Linter – A Source Code repository to detect errors in your code for different languages.

Traditionally, when you were trying to set up a new repository, setting up the right linters for the various codes was a very complicated and time-consuming task.

For those, who don’t know what Linters are, Linters are tools that scan all your source code and find all the formatting errors, bugs, and poorly constructed codes. And uploading codes with these errors is not a good idea at all.

To address this issue, GitHub has released an open-source tool, “Super Linter,” which makes our lives easier when it comes to testing and finding inconsistencies in our source code.

Super Linter Goals

GitHub describes the goals of the super Linter to be:

It will prevent the wrong, broken codes from being uploaded to the master branches.
Cross-Languages coding practices will be very smooth.
Now even for various languages, a single rule will be there.
The code reviews will be faster than ever as the whole linting process is automated.
And after all this, we can ship better and clean code.

What is GitHub’s Super Linter?

The super Linter is a source code repository that is packed in a Docker Container. It can be called by GitHub’s actions. Any Repository on GitHub.com can call this Super Linter and start utilizing its benefits.

List of Languages GitHub Super Linter Supports

Currently, The Super Linter Supports 16 programming languages. They are Ansible, CSS, CoffeeScript, Dockerfile, Golang, JavaScript, JSON, Markdown, Perl, Python3, Ruby, Shell, Terraform, TypeScript, XML, and YAML. The point to be noticed here is that It still not supports popular programming languages like JAVA, C, and C++. As per the officials soon, they’ll include more language support.

GitHub Linter was initially created by the GitHub Services DevOps Engineering team to maintain the team’s code consistency while making communication across the company. Now GitHub has made it opensource.

How does GitHub Super Linter work?

Once you’ve set up this action in your repository and when you try a pull request. I will automatically start linting your source code and return the status of the source code as a Status API. This will contain whether your code has some errors or not, what were those errors, where were those errors were the formatting correct.

After analyzing this status, the developer can return to the branch and start to fix the errors. This is super easy now. Earlier, we have to do it manually by checking our code on various other Linters.

How to set up Super Linter in your repository?

You have to add the Super-Linter Action in your Git-Hub Actions workflow. Your repository will be having (.github/workflows) this section. Here you need to set up your Super Linter.

For the detailed process, you can read from here.

Custom Rules can be set for Linting.

Since every user has his/her style of coding, then what rules will the Linter examine the code? To address this issue, GitHub allows you to set your own rules, which you think suits best for your repository. If you are not choosing any rule, then some standard rules are there for each supporting language. If you choose your own custom rule, then the Linter will check your source code based on that particular rule. But if you haven’t chosen any custom rule, then it will use the standard rule as a reference and then check your source code based on that standard rule.

Super Linter Limitations

There are some limitations to Super Linter as well.

Neither can you update individual linters nor your dependencies can be updated, as this is packaged at run time.
In the case of JSON packages, it won’t read additional details.
You can’t download new codebases from private repositories and use them as dependencies.