Introducing GitHub Super Linter: one linter to rule them all
Setting up a new repository with all the right linters for the different types of code can be time consuming and tedious. So many tools and configurations to choose from…
Setting up a new repository with all the right linters for the different types of code can be time consuming and tedious. So many tools and configurations to choose from and often more than one linter is needed to cover all the languages used.
The GitHub Super Linter was built out of necessity by the GitHub Services DevOps Engineering team to maintain consistency in our documentation and code while making communication and collaboration across the company a more productive experience. Now we are open sourcing that so everyone can use and improve it!
The Super Linter solves many of these requirements through automation. Some included features:
- Prevent broken code from being uploaded to master branches
- Help establish coding best practices across multiple languages
- Build guidelines for code layout and format
- Automate the process to help streamline code reviews
- With these basic criteria, we should be shipping better, cleaner, and more stable code internally and to our customers and partners
What is it?
The Super Linter is a source code repository that is packaged into a Docker container and called by GitHub Actions. This allows for any repository on GitHub.com to call the Super Linter and start utilizing its benefits.
The Super Linter will currently support a lot of languages and more coming in the future. For details on languages, check out the README.md
.
How it works
When you’ve set your repository to start running this action, any time you open a pull request, it will start linting the code case and return via the Status API. It will let you know if any of your code changes passed successfully, or if any errors were detected, where they are, and what they are. This then allows the developer to go back to their branch, fix any issues, and create a new push to the open pull request. At that point, the Super Linter will run again and validate the updated code and repeat the process. You can configure your branch protection rules to make sure all code must pass before being able to merge as an additional measure.
There’s a ton of customization with flags and templates that can help you customize the Super Linter to your individual repository. Just follow the detailed directions at the Super Linter repository and the Super Linter wiki.
This tool can also be helpful for any repository where multiple types of code and/or documentation all live together (monorepo).
Default rules
Standardizing a rule set across the Super Linter has been an interesting challenge as each developer is unique in how they code. This is why we allow users to use any rules for the linter as they see fit for their repository. But, if no ruleset is defined, we must default to a certain standard.
The rule set for Ruby and Rails are pulled from the Ruby gem: rubocop-github
and follow the same rules and versioning we use on GitHub.com.
For other languages, we choose what is the default when installing the linter such as: coffeelint
or yamllint
. For others, we try to find a happy middle ground that lays the simple groundwork and helps establish some best practices like: Markdownlint
or pylint
.
The beauty of this is, out of the box you will start establishing the framework, and your team can decide at any point, if additional customization is needed, you have all the ability to do so.
Just navigate to the Super Linter and copy templates from the TEMPLATES
folder to your local repository.
Join in the fun
We encourage you to set up this action and start the process of cleaning up your codebase and building your team’s standards and best practices.
How can I contribute?
We’re always looking to update best practices, add additional languages, and make the tool easier for consumption. If you’d like to help contribute to this action, check out our contributing guide.
Learn more about our Super Linter
Written by
Related posts
Code referencing now generally available in GitHub Copilot and with Microsoft Azure AI
Announcing the general availability of code referencing in GitHub Copilot and Microsoft Azure AI, allowing developers to permit code suggestions containing public code matches while receiving detailed information about the match.
The nuances and challenges of moderating a code collaboration platform
Sharing the latest data update to our Transparency Center alongside a new research article on what makes moderating a code collaboration platform unique.
GitHub Copilot now available in github.com for Copilot Individual and Copilot Business plans
With this public preview, we’re unlocking the context of your code and collaborators—and taking the next step in infusing AI into every developer’s workflow.