内容简介: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.TheThe
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.
以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网
猜你喜欢:本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们。