Getting started with Gitlab CI/CD: Eslint

Getting up and running with Gitlab's Continuous Integration can take less than 10 minutes (depending on what you want to do, YMMV) I'm going to show you how:

To begin with - I just want to setup a simple task that will run eslint on our code. Luckily for us, we're already half way there.

Starting from version 8.0, GitLab Continuous Integration (CI) is fully integrated into GitLab itself and is enabled by default on all projects.

If you head on over to a project within Gitlab and click on Settings and CD / CD (https://gitlab.com/{username}/{project}/settings/ci_cd) you will see a drop down for Runners. You should see two columns. Specific Runner and Shared Runners. Awesome! (You don't have to do anything).

Runners

You should have some shared runners available. Shared runners are free to use for public open source projects and limited to 2000 CI minutes per month per group for private projects.

Runners are virtual machines that run jobs specified in a .gitlab-ci.yml. This file will tell the runner what jobs to do.

# At the root of your repository, add the .gitlab-ci.yml file.
$ touch .gitlab-ci.yml

Runners use docker to pull an image and run our application in a container, so we need to tell it what image to pull, what things to install and what scripts to run.

Since I'm using node, we want to pull that image from Docker

# We're pulling and installing node into our virtual container, neat!
image: node

Now we want to add a stage. Stages tell the runner what functions to run and when. For example you might have build, test and deploy stages. Stages can have multiple Jobs.

image: node

stage:
 # I just want to lint, so I will create a "lint" stage
 - lint

# Lets name our Job eslint, because that's what it's doing.
eslint:
 # tell eslint what stage it is. (This could also be build or test for example)
 stage: lint
 # What scripts do we want to run?
 script:
    # install eslint
    - npm i eslint
    # Run eslint
    - node_modules/eslint/bin/eslint.js .

Commit the .gitlab-ci.yml and push it to gitlab!

Head on over to https://gitlab.com/{username}/{project}/-/jobs to see your job in action.

Assuming you have some eslint errors, your job will fail - Woohoo!

But I have plugins, and presets!

You can simply install these along side the npm i eslint statement.

If you have multiple, you can use a backslash \ to move it onto a new line for a multiline command

image: node

stages:
  - lint

eslint:
  stage: lint
  script:
    # Install eslint
    - |
      npm install eslint \
      eslint-config-airbnb \
      eslint-config-prettier \
      eslint-plugin-flowtype \ # Any ideas on what I might want to do next?
      eslint-plugin-import \
      eslint-plugin-jsx-a11y \
      eslint-plugin-prettier \
      eslint-plugin-react
    # Run eslint
    - node_modules/eslint/bin/eslint.js .

Now go and get rid of all your eslint errors and you're on your way to a passing pipeline!

Comments

[Gaurav Gupta]

I get that this code would run eslint everytime you push to the gitlab repo.
Do you have any idea about how to run eslint on only the files that have changed in a particular merge request?

[kambala yashwanth]

Are Shared runners only for testing purpose or , can we deploy some react site to it

[ajv]

You can use a shared runner to build and deploy a site. Note that you don't deploy a site to a runner. The runner is a temporary container dedicated to your pipeline, so you use it as an environment to run your build/deploy commands.

[Tom Dohnal]

How'd you go about running Eslint with autofix in the CI? :)

[Karl Taylor]

I'm not sure how this would work Tom, you would be auto-fixing in the CI runner which I think is just ephemeral. I guess you would need to figure how to run auto fix which would write to disk and commit them to git, which would technically run another CI build. Would be interesting to see it!