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 .
- With every each change , are some of the queries failing which consumers have written . consumers would be user interface or other backend applications .
- Is there mechanism by which i can validate that existing queries are working fine . This needs to be verified with each change.
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
- Any changes for hasura models are done through hasura console
- As soon developer performs model change using hasura ui, corresponding changes are emitted to migration scripts and metadata files . Important point to note here is that changes to models needs to be done through hasura ui invoked using hasura console . ( Do not directly invoke hasura ui url and perform the change ⚠️)
- Migration scripts and metadata yaml will be version controlled .
- Once we push migration and metadata yaml to github ( or for that matter any version controlled repository) , we should be able to create hasura instance using these scripts . This would be like building hasura instance on every integration request.
- On every hasura instance , we can test graphql queries . If they are working fine , that would mean , there is no regression . These graphql queries would be the ones which are used by front end or any other consumers of graphql application ( a.k.a consumer driven testing )
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
- post every check in of migration file or metadata file
- run a github action workflow , which will launch test set up
- run test cases against hasura graphql server and verify that there is no regression and tear down
Context diagram for test set up
Continuous integration — test set up
From the context diagram , it would be clear that whole continuous pipeline would be made of 3 containers .
- Hasura docker container
- postgres docker container
- Test container : Test container would be a set of graphql queries and their json responses . I have chosen node container for running tests as it would be easy to run graphql queries as client and verify the responses
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>or127.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
- line 3 — running job as container job
- line 5- test container is node 10 container
- line 8 — defining services container for test
- line 12 — configuring service container postgres -12
- line 22 — configuring service container hasura
- line 36 — install curl on test machine
- line 38 — install hasura cli .would be used in applying migration and metadata
- line 49 — carry out hasura migration
- line 54 — testing graphql queries
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
