GitHub Actions -> kubeval

3 min readApr 13, 2020

It’s been nearly one year since GitHub Actions is released, but guess what? I learned it today… So, why don’t we use this well-thought beast in Kubernetes Operator’s favor! I take the lead.

What is GitHub Actions?

In one short sentence, GitHub Actions automate your workflows. You can use it to build, test, validate and even to deploy your codebase.

For more information, click on this.

In this post, I’m going use Github Actions to validate my Kubernetes manifests with kubeval command.

Steps to Implement

There are two reeeeally simple steps to achieve success in this (Did you buy that?). Hop on in either case!

1. We need to create two repositories

The first repository will be the one with the Kubernetes manifests to validate, obviously. I just threw some dummy manifests that we can use. We will create the GitHub Action here under .github/workflow directory as a .yaml file.

Now, the latter one is a bit different. It’s a special kind of repository. You can think Actions like repositories with Dockerfiles and stuff. When an Action gets triggered, it will execute steps declared in this repository’s Dockerfile, which in our case, is kubeval command. Please have a look at the repository to understand more.

2. We need to configure these two repositories

Let’s start with the former one by creating the .yaml file that I mentioned before.

You need to create this file under .github/workflow directory and you can give it an arbitrary name. Why don’t we go with validate-my-parchment.yaml? Oh yeah, that’s a good name right there.

Inside this file, we have:

validate-my-parchment.yaml

It’s pretty self explanatory, right? On pushes, by ubuntu-latest self-hosted GitHub runner, manifests inside /manifests directory will be validated by our own configured action/repository kubeval command with strict flag.

Now, the latter one is named kubeval-action. This special repository is where we reference on line 10 above.

Three files are needed in our case. Dockerfile, entrypoint.sh and action.yaml.

Dockerfile

I’ve used gareth/kubeval as my base image since it already has the kubeval command installed.

entrypoint.sh

Since gareth/kubeval image doesn’t have bash installed, I needed to use sh. I will explain what $INPUT_COMMAND is in a bit.

Also, a side note, don’t forget to chmod +x entrypoint.sh. Otherwise you get the old exec permision denied error.

action.yaml

Coming back to $INPUT_COMMAND, this is where the magic happens. The command we’ve sent in the validate-my-parchment.yaml is sent as an input named command. This becomes an environment variable in our latter repository/action called INPUT_COMMAND and then we can use it like that in the entrypoint.sh.