Get in touch with Binary

Binary Studio website uses cookies to enhance your browsing experience. By continuing to use our site, you agree to our Privacy Policy and use of cookies.

Learn more more arrow
Vladyslav Zubko 21.12.2021

Lint your project with Github Actions

Init Simple project

Let's set up a simple project to see how it works!

Install ESLint. ESLint is a tool for identifying and reporting on patterns found in JavaScript code.

ESLint configuration file example:

Also, do not forget to update the scripts section in the package.json.

Github Actions in general

Github Actions are commands for github to run some code every time an event occurs (Push, Merge, PR and etc.). The code runs on github virtual machines.

What does this code do? Anything. It allows you to automate things necessary for your development process: run tests/lints, deployment, and notify people.

Github Actions give a nice and free CI/CD and also allow you to create a flexible and easily configurable system for development.

Let's look at a simple example — for each push to one of the environment branches (development, staging, production) we will run linting (example will use JavaScript).

Action Example:

Steps syntax

  • name — needed to be displayed in the github interface;
  • uses — specify the name of custom actions if we want to use it. You can find many ready-made actions in the marketplace;
  • with — parameters for custom actions;
  • run — runs commands in the shellIt is forbidden to use a shell commands with custom actions.

That's it, we took apart a small but useful example of the github action!

In the github interface, the runs will look like this:


Run History

Inside Each Run

Branch protection

To prohibit merging a pull request when linting fails, go to the repository settings and set the merge rules for the branch you want. To do this we need to check the Require status checks to pass before merging checkbox and select the checks we need. In our case, this is Linting (the name is taken from the action config).

Now in each pull request to the branch we need we will see the result of the action. If all is well, the action will be passed:

But if we broke something the action will fail:

Inside each action we can find out what exactly went wrong. For example, here the action tells us that there are unused variables in the code:

Linting other files

For now, we only check the format of the js files. It is not very good. Attention should be paid not only to js files, as there are usually other file formats that developers pay less attention to. Let's fix this and add additional linters to protect our code.

Style Lint

Stylelint is a mighty, modern linter that helps you avoid errors and enforce conventions in your styles.

I use a simple example in which I just extend the config from the recommended. But even with this couple of lines we will protect our styles.

Stylelint supports a huge number of configuration options. Be sure to check the documentation to find the rules that fit your project.

Stylelint configuration file example:

Updated package.json:

// scripts in package.json

EditorConfig Lint

EditorConfig helps maintain consistent coding styles for multiple developers working on the same project across various editors and IDEs.

EditorConfig configuration file example:

Updated package.json:

Ls Lint

Ls-lint — file and directory name linter. Bring some structure to your project directories.

Ls Lint configuration file example:

Updated package.json:

// scripts in package.json

Now 4 linters will run for each pull request. I hope you and your team will follow and improve the linters configs. And you will always see the linter result without errors:


Github actions are not free. Now the free plan gives ~2000 minutes. Usually this is enough for small and medium projects.

You can always find up-to-date information on the use-plan here.


You know the basics of Github Actions now, and I hope this article clarifies all of the basic principles.

This example does not cover all the opportunities. Github has a wonderful documentation, which describes many interesting things!

Linting code is just an example. Everything can be automated.

Some examples:

  • Running tests on each pull request;
  • Deploying on push to production branch;
  • Prettify your code before merging;
  • Publishing packages;
  • Sending notifications on each pull request/issue, etc.