GitHub Actions is an automated way of performing development workflows. These workflows, defined through YAML files, are stored in your GitHub repository under the .github/workflows directory. You can trigger these workflows three ways via an external event, a scheduled event, or a GitHub repository event (such as a push or pull request to a GitHub repo or issue creation). If you want to learn more about GitHub Actions, including the usage limits of the feature, see this documentation here

One way to use GitHub Actions is to create continuous integration (CI) workflows that build and test projects written in your application’s programming language. GitHub Actions is also able to publish artifacts to GitHub Packages or another package hosting provider such as Docker Hub. There is Dockerfile support for GitHub Actions, along with the ability to leverage actions built by other developers.

This blog post uses these GitHub Actions features with the Harness platform to continuously deliver a Kubernetes deployment. 

Ready Set Action!

If you’d like to follow along with this step by step guide you can find the now public repository with the application code here. Otherwise you may use your own application code and Dockerfile.

To get started with GitHub Actions create a workflow, by selecting the Actions tab of the GitHub repository.

GitHub Actions Workflow - Harness Continuous Delivery

If you select the option to “set up a workflow yourself,” GitHub creates a main.yml file with the .github/workflows directory for you with a templated workflow that you can edit. 

GitHub Workflow - Harness Continuous Delivery
Creating a CI workflow in GitHub Actions.

Here I am creating a “build” and “create_dockerfile” job within my CI workflow. These jobs are the sequential steps within the workflow. A pushed commit triggers this workflow to the repo. Any steps that fail cause the workflow to quit at that failure. 

Build and Create Dockerfile - Harness Continuous Delivery
Failed and passing workflows.
Dockerfile - Harness Continuous Delivery
The create_dockerfile job creates a new image to be published to Docker.

My create_dockerfile job requires credentials to my Docker account. To define those secrets go to Settings, Secrets, and Add a new secret. 

Docker Credentials - Harness Continuous Delivery
Pass secrets to GitHub Actions via Settings.

Also, note your Docker credential must have the authority to push and pull Docker images from your Docker Hub.

Docker Credentials - Harness Continuous Delivery
Ensure the credentials have proper read and write access with Docker Hub.

Once now trigger your GitHub Actions CI workflow, and view the details of each step within the workflow.

GitHub Actions CI Workflow - Harness Continuous Delivery
Trigger the CI workflow via pushed commit.

Here my image repository on Docker Hub has the newly pushed docker image named tictactoe as specified within my workflow. 

DockerHub - Harness Continuous Delivery
The CI workflow builds and pushes a new Docker image called tictactoe.

Harness Your Delivery

Now it’s time to deploy the new artifact to a Kubernetes environment with Harness. 

Under Setup, ensure you have a Harness Delegate installed in your environment, and it is currently running. Under Connectors, Artifact Servers ensure you have added an artifact server with valid Docker Credentials.

Harness Connectors - Harness Continuous Delivery
Docker credentials added as an Artifact Server.

Under Setup Create a new application called tictactoe. Use this application view to create a service, environment and workflow to deploy the tictactoe application.

Harness Setup - Harness Continuous Delivery
Create a new tictactoe application and configure a new deployment workflow.

Here my application is deploying a single service called tictactoe. To pull the Docker image from my public Docker Hub repository I need the proper Source Server defined earlier and the corresponding repository information.

Service Overview - Harness Continuous Delivery
Create a service called tictactoe to deploy the tictactoe Docker artifact.
Artifact Source - Docker Registry - Harness Continuous Delivery
Naming convention for Aritfact Source Docker Registry.

After specifying a targeted Kubernetes environment for deployment, create a Kubernetes deployment workflow. Here I am using a minikube environment to deploy the latest artifact.

Workflow Overview - Harness Continuous Delivery
Create a deployment workflow, here I used a Rolling deployment.

When you are ready to deploy the artifact, hit the Deploy button and view the application deployment status.

Deploy Artifact - Harness Continuous Delivery
A successful deployment occurs when all the workflow steps have succeeded.
Kubernetes Workflow - Harness Continuous Delivery
The newly deployed tictactoe application is now running in my minikube environment.

Creating a deployment workflow is really easy and can be done in less than 3 minutes. This video is a step-by-step guide to deploying the tictactoe artifact with Harness.

Creating a workflow trigger within Harness is also very simple. Here I trigger the “deploy to minikube” workflow on the condition there is a new tictactoe artifact (docker image) ready to be deployed.

GitHub Actions and Harness Continuous Delivery Explained

Master your development workflows

Github Actions allows developers to trigger software development workflows for a variety of application frameworks, runtimes, and languages. This blog posts how to set up a Continuous Integration workflow in GitHub Actions to build a deployable artifact. We then used Harness for Continuous Delivery of that artifact to a Kubernetes environment in less than 3 minutes. If you’d like to try Harness for free, go to Harness.io today to start delivering even with unique developer workflows.

Keep Reading