Adding `pylint` to your Github Actions flow

2021 January 21

Recently, I’ve been doing more CICD work, so I wanted to practice adding some of that to my personal projects. I’ve also taken a liking to pylint, so I decided to have Github Actions automatically check my code quality on push for my log-analysis repository. This is how I added that linting to my workflow.

Github actions provides free continuous integration for public repositories on their service. Otherwise they include some number of free build minutes for your personal private projects. The rules are defined by a yaml file in .github/workflows/ from the root of your repository. To setup pylint to run automatically on push the yaml looks like the following:

name: Pylint

on: [push]

jobs:
  build:

    runs-on: ubuntu-latest

    steps:
    - uses: actions/checkout@v2
    - name: Set up Python 3.8
      uses: actions/setup-python@v1
      with:
        python-version: 3.8
    - name: Install dependencies
      run: |
        python -m pip install --upgrade pip
        pip install pylint
    - name: Analysing the code with pylint
      run: |
        find . -name '*.py' -exec pylint {} \;

The above defines a task to be run on pushing a commit. This task is called “build”. It runs on a ubuntu host, and calls into some pre-defined actions from Github, such as getting the current code or setting up a specific version of Python. The next steps are a couple of shell commands to upgrade pip to the latest version and install pylint. The final step runs pylint on all of the python files in the repository.

For my log analysis project, I have a single python script which parses the log files and counts up the valid hits. However this pipeline can be extended out to as many python files as are in your repository.

The results can be viewed on the actions tab of your project page. From there you can look at some detailed results by selecting a specific execution. Here’s an example of a failure due to some minor issues when I was fixing some things up. It’s expanded by clicking the build step button.

Then after I fixed up all of the pylint issues, everything started passing.

So what did I learn from this?

1. It’s pretty easy to add CI-CD for public repositories.
2. Pylint is very noisy about what it complains about but getting into the habit of using it makes for better code quality.
3. Keeping the CICD with the code is very important as it makes life a lot easier.

I hope you found this a useful introduction to Github Actions.