GitHub Actions is GitHub’s new build server, just like Gitlab’s gitlab pipeline. It allows you to automate your workflow directly from your GitHub repository, without having to configure and manage a third-party server like jenkins, Bamboo, CircleCI.

For example, we can define an action that allows us to build our project and run a set of unit, integration and security tests that we will then use in a workflow that will be launched at each pull request.

We can also add another action to the workflow that allows us to publish the previous results on the discussion queue by applying labels (Bug, non-secure, code-sale etc.). We can also create actions that execute our requests and reuse them in our workflows.

Why GitHub Actions?

Workflow automation is a necessity in the software development world today. The success of the DevOps philosophy is proof of this. It brings a culture of automation by defining a set of best practices to automate certain redundant tasks that were previously manual, sources of errors and loss of velocity in the delivery of products, such as the integration and deployment phases. This is why almost all development teams today use CI/CD servers to integrate continuous integration and deployment (CI/CD) processes into their software lifecycle.

That’s why GitHub, the most popular source code manager with the largest open source community in the world, has just launched the beta version of its own CI/CD server called “Github Actions” which allows its users to build, test and deploy their code directly from GitHub. Offering the ability to build end-to-end continuous integration (CI) and continuous deployment (CD) features directly from a GitHub repository, without relying on a third-party server like Jenkins, Bamboo, CircleCI or others.

GitHub Actions, an embedded CI/CD server

There are two ways to implement CI/CD features. One can either use a third party CI/CD server like Jenkins, or use CI/CD servers embedded by your own versioning server.

Third party CI/CD server

This approach, while offering the most flexibility and portability, is the one that requires the most resources and technical skills.

Indeed, it requires a good mastery of the CI/CD server to be used and obliges you to provision yourself the CI/CD server execution environment, configure it and maintain it.

Example: Jenkins, Bamboo, CircleCI, Aws codeDeploy etc.

Embedded CI/CD server

This approach frees you from the management and maintenance tasks of the CI/CD server and runtime environment. It is by far the easiest to use and requires the least technical skills. You can easily define your pipelines and roll them out in record time without using any tool other than your own versioning server.

Nevertheless it is restrictive and less portable because each CI/CD server is intrinsically linked to the versioning server that embeds it.

Example: GitHub Actions, Gitlab-CI, Bitbucket pipeline etc.

How GitHub Actions works

With GitHub Actions, you can easily create workflows using actions that you define in your action repository found in a public GitHub repository or a Docker image. And furthermore, you can automate these workflows through events in your GitHub source code manager such as push, create Pull Request, Issue, Release, Tag.

Actions are individual tasks that you can combine to create your own workflows. As an example, you can create an action that:

• executes your unit, integration and/or security tests,
• allows you to block a Pull Request if your tests don’t pass,
• allows you to build your docker image and publish it on your repository,
• allows you to deploy your application on aws, heroku or other
• combine everything in a workflow.
• And the most important thing with GitHub actions is that they are reusable, you don’t have to create the same action twice. You just create a reusable action once for the next time you need it, at the workflow level. And you have the ability to use public actions built and maintained by the GitHub community and share your actions. That’s why most of the actions you’ll need for your workflows will already be available in the marketplace (GitHub has a very strong community.

Github Actions Workflow example for Django PostgreSQL Application

The action must be created inside a .github/workflow/ folder for it to be accessible by Github.

Next, let’s create our workflow files inside the workflows folder, this file should be a yml file

touch .github/workflows/ci.yml

You can easily find other actions on Github (repositories) and implement them to the yml file.