Employee leave maintenance - using GitHub actions for continuous integration

Introduction

As part of development using hasura , we would develop a set of graphql apis using database models . Hasura models will be available as set of migration scripts and metadata file . As requirements keep on adding ( or rather changing ) , there would be further migration scripts generated and metadata changes . As developer , you would get worried about the quality of migration scripts . Main cause of worry will be that of regression .

Continuous integration

Martin fowler defines — Continuous Integration is a software development practice where members of a team integrate their work frequently, usually each person integrates at least daily — leading to multiple integrations per day. Each integration is verified by an automated build (including test) to detect integration errors as quickly as possible. Many teams find that this approach leads to significantly reduced integration problems and allows a team to develop cohesive software more rapidly

Continuous integration for Hasura based model development

Git hub actions for continuous integration

Github actions is a great way to develop workflow for continuous integration. Flow i am going to demonstrate is rather simple one

Context diagram for test set up

Test set up for continuous integration pipeline

Continuous integration — test set up

From the context diagram , it would be clear that whole continuous pipeline would be made of 3 containers .

Service containers for git hub actions

service container feature offered by github actions helps to launch dependent services ( hasura and postgres ) very easily . You can configure service containers for each job in a workflow. GitHub creates a fresh Docker container for each service configured in the workflow, and destroys the service container when the job completes.

There are 2 ways to run service containers

Running jobs in a container

When you run jobs in a container, GitHub connects service containers to the job using Docker’s user-defined bridge networks. For more information, see “Use bridge networks” in the Docker documentation.

Running the job and services in a container simplifies network access. You can access a service container using the label you configure in the workflow. The hostname of the service container is automatically mapped to the label name. For example, if you create a service container with the label hasura, the hostname of the service container is hasura.

You don’t need to configure any ports for service containers. By default, all containers that are part of the same Docker network expose all ports to each other, and no ports are exposed outside of the Docker network.

You don’t need to configure any ports for service containers. By default, all containers that are part of the same Docker network expose all ports to each other, and no ports are exposed outside of the Docker network.

Running jobs on the runner machine

When running jobs directly on the runner machine, you can access service containers using localhost:<port> or 127.0.0.1:<port>. GitHub configures the container network to enable communication from the service container to the Docker host.

When a job runs directly on a runner machine, the service running in the Docker container does not expose its ports to the job on the runner by default. You need to map ports on the service container to the Docker host. For more information, see “Mapping Docker host and service container ports.

Git hub workflow file .

Finally some code 😉.

I have used running job on container as option . started with running jobs on runner machine . however i constantly encountered errors for using localhost ( service not found )

Code explanation

Hasura migration as part of continuous integration

Please note that , since we are using containers , HASURA_HOST is passed as environment variable to bash script . HASURA_HOST is mapped to label hasura. 👈

Complete source code

Conclusion

Continuous integration and build is important practice for developer to make sure that code is in good quality .Git hub action gives good mechanism to make that validation possible . Approach of service containers is clean and simple to use . It helps to avoid installing docker or docker-compose inside Continuous pipeline

Interests : software design ,architecture , search, open banking , machine learning ,mobility