Avoid Ridiculous Failed Pipeline with Git Hooks

Let’s find out why this article’s thumbnail is a dog

Waiting for pipeline sucks (especially in PPL rush hour). So the last thing you want is making ridiculous mistake causing your pipeline failed.

Our project CI (Continuous Integration) script consists of four stages: test, report, build and deploy. The test stage including running test and lint check. This is where most mistakes made.

About Linter

Before we continue, in case you didn’t know what is linter and what is this to do with pipeline, here’s the explanation. If you already know it, you can skip this section.

What is lint check?

Lint check or linter is a tool that make sure everyone’s code style in team follow the agreed standard. Linter is important to ensure our code clean, consistent, and readable. In our team, we use Eslint as linter and Airbnb as style guide/rule.

Why can linter make pipeline failed?

This is where the “make sure” part works. My team add script to check code style in the CI script (at the test stage). If the code style doesn’t fit the rule, the test stage will be failed and your dev branch can’t be merged to the higher branch (e.g. staging).

So, how to setup Eslint?

Before that, make sure your project use javascript or typescript because this tool is specific for ECMAScript (superset of language above).

First, install Eslint and add it on dev depedencies.

npm install eslint --save-dev

Setup configuration file. This command will bring you to interactive configuration. Set up configuration according to your project detail.

npx eslint --init

To check code style, type:

npx eslint path/to/file.js
# or
npx eslint . # Check all files

This command will show you code style error and warning. To fix them, you can use --fix .

npx eslint path/to/file.js --fix
# or
npx eslint . --fix # Fix all files

Unfortunately, this command can’t fix all error. There’s some error that you must fix manually.

If you use Visual Studio Code, I strongly recommended install Eslint extensions to detect and fix code style error faster and easier.

Go to Eslint extension setting and set ESLint as formatter so your code style will be fixed automatically on save (or on type, depend on your formatting settings).

This extension will show the style error in red squiggly underline and warning in yellow. You also can hover the style mistake see what is mistake and how to fix it.

Besides fix on save, you also can fix style by press F1, type “fix” and choose Fix all auto-fixable problems or type Shift + Alt + . .

After that, add lint script on package.json. In my project, this is how to check and fix code style. Your project maybe have different command.

...
"scripts": {
  ...
  "lint": "eslint",
  "lint:fix": "eslint --fix",
},
...

To run in in CLI, type:

npm run lint . # All files
npm run lint:fix .

To enforce everyone’s code style fit style guide, add check lint script on CI script.

test-backend:
  stage: test
  ...
  script:
    - npm i
    - apt-get update
    - npm test -- --coverage
    - npm run lint . # Make sure the code passed lint check

That’s all. Now, all your teammates will (be enforced to) write clean and consistent code.

Using Git Hooks

Sometimes we forgot to run test and lint to make sure our code is fine and should be pass pipeline. This is one of the case git hooks needed. Git hooks will automatically run some command before we push our code. In this case, we want to run test and lint to avoid ridiculous failed pipeline.

Setup Husky

You can use our furry friend called Husky to implement git hooks easier.

npm install husky --save-dev

After that, you can defined your hook command ind package.json (this is optional)

"scripts": {
  ...
  "hook": "npm test && npm run lint ."
}

I combine npm test and npm run lint . so I can call these two command easily to check if my code is okay.

After that, add hooks command into package.json file using a pre-defined naming convention.

"husky": {
  "hooks": {
    "pre-push": "npm run hook"
  }
}

Now, npm run hook will be automatically run before git push. If somehow you need to bypass this hook, you can use --no-verify

git push origin master --no-verify

Actually, you also can add hook to commit using pre-commit. But for me it’s too overkill and impossible to use with TDD approach. (Red-Green-Refactoring, remember?)

With this git hooks, you and your team will never made ridiculous pipeline mistake anymore.

References:

Getting Started with ESLint

typicode/husky