How to Configure Github Actions the Easy Way. | by Salma El Shahawy | Towards Data Science

In my previous article, I walked you through a step by step tutorial to correctly setting up the python3 environment using pyenv on your local machine. However, some issues may arise in some circumstances due to some conflicts resulting from pull requests that use different python versions or even missing modules.
This tutorial will demonstrate the steps to build a standard workflow for any project utilizing Github actions plugins. Configuring Github actions in the project CI folder would protect the codebase pull requests that don’t meet the code standards regarding code formatting, syntax error, and version conflict. So, let’s get started!
Github account.Code editor — IDE, I prefer vscodeBasic Knowledge of YML syntax — quick review herePython 3 installed on your local machine — follow the steps here.
Github account.
Code editor — IDE, I prefer vscode
Basic Knowledge of YML syntax — quick review here
Python 3 installed on your local machine — follow the steps here.
Github actions are plugins that automate and manage the project workflow complete development life cycle. It is similar to Circleci, Travis, and Gitlab in functionality; however, it is free if the project repository is public.
Workflows for GitHub actions are a series of steps or directions written in the yml file that run every time you push to a specific branch on Github.
Setting up a workflow is a timesaver in the long run, where you can have peace of mind during pushing/merging code. The workflow could be customized to check against different tests stated as steps on the yml file. These checks could be using the correct version of the coding language, install dependence, or even check against code formatting and syntax error. This way, you could guarantee to be less anxious about merging code into the main branch — at least nothing would break!
You might have multiple workflows, and each one might have multiple jobs. The workflow is triggered every time, pushing to a specific branch.
In this guide, I will use the following:
pyenv-action was developed by Gabriel Falcão to pick the correct python version.Postgress docker image to configure Postgres as a database.Flak8 to check against syntax errorPylint to check against code formatting.
pyenv-action was developed by Gabriel Falcão to pick the correct python version.
Postgress docker image to configure Postgres as a database.
Flak8 to check against syntax error
Pylint to check against code formatting.
Github actions could be configured either on existing repos or creating one from scratch. For the sake of simplicity, I would start a new one from scratch; navigate to GitHub, and create a new repo and name it; I will name it github_actions . Then clone the repo into your local machine and create a GitHub workflow action file on .github/workflows/main.yml — this where the steps would be defined.
You could use the github workflows template by heading to the action tap and trigger the yml file.
You might include a requirements.txt file by running the following command in the terminal:
$ pip freeze > requirements.txt
Each workflow might have a bunch of jobs, and each job contains several steps to execute.
I am using the pyenv-action action developed by Gabrial. This action would do the following:
Installs pyenv 1.2.21.
Exports PYENV_ROOT environment variable.
Injects $PYENV_ROOT/bin in the PATH.
Injects pyenv shims in the PATH.
Pre-install specified python versions.
Set default python version (through pyenv local). — pyenv-action
Open the main.yml file and start configuring pyenv and pick the right python version. The following snippet is installing pyenv using the pyenv-action version 7, then upgrading the pip after picking version 3.8.6 and set it as the default. Following that, create a virtual environment with the default version and install project dependencies.
It has a successful build, and a green health check would appear associated with the commit id, as demonstrated above.
It is the same as the previous step; however, we will define the Postgres database connection in the services section using the Postgres docker image. Some health checks were configured to wait until Postgres started. Finally, port 5432 was mapped from the service container to the host.
The db_service service container has a successful build 😏.
Utilizing pylint would check every code snippet pushed to the master branch against errors and enforce a coding standard.
Pylint is a tool that checks for errors in Python code, tries to enforce a coding standard and looks for code smells. It can also look for certain type errors, it can recommend suggestions about how particular blocks can be refactored and can offer you details about the code’s complexity. — pylint 2.6.1-dev1
We could install pylint after installing the requirements and run pylint as a next step
- name: Install dependencies  run: pip install -r requirements.txt --upgrade pip       pip install pylint- name: Analysing the code with pylint  run: |    pylint `ls -R|grep .py$|xargs`
The final main.yml file might look like the following:
Now it is time to add some code and try to push it to the GitHub repository. I started by creating a demo file and developed a method for generating random sampling from an input array of distinct elements and size. All subsets should be equally likely.
The next step would be committing and pushing the Github repository changes using a pull request or direct push to master. Once the changes are made to the remote, different tests would be run against the changes before merging the changes into master.
As shown in the above image, there was an error generating because of inadequate formatting according to the pylint package; some of the errors were because I didn’t follow the snake_case naming conventions. As you can see, the pushed code had a rate of 4.29/10.
If you want to ignore the pylint checks for docstring, you could create a newfile named .pylint and add the following snippet into it to ignore docstring module.
[MASTER]disable= C0114, # missing-module-docstring
Now commit and push the Github repository changes after creating the pylint file, the build should be successful, and a healthy green check would appear near the repo 😎.
Github action is a powerful plugin that empowers the process of automating the machine learning development cycle. You could add more steps and jobs to the workflow, including deployment to different platforms, such as Iaas, Paas, Saas, and onsite premises. Also, it allows you to use docker containers as well as Kubernetes. There are plenty of GitHub-actions built by the community’s marketplace; you can even create your customized action if you have a programming background or follow the documentation.
Some of the references that helped me to configure this workflow are:
Workflow syntax for Github actionsPostgresql Github action by HarmonGithub actions documentations — environment variablesLearn Github actionsPyenv-action by Gabriel FalcãoPylint documentation
Workflow syntax for Github actions
Postgresql Github action by Harmon
Github actions documentations — environment variables
Learn Github actions
Pyenv-action by Gabriel Falcão
Pylint documentation
Finally, I hope this provided a comprehensive guide to utilizing the GitHub actions to automate machine learning projects. If you followed along and have a question or suggestion, please post them in the comment section below; I would be more than happy to help. Thanks for reading and happy learning👍