GUIDE Using Pull Requests For Release Gating

 

Introduction

This lab introduces GitHub Actions workflow, and challenges us to build and push a container to Docker Hub. The application container may then be deployed to Kubernetes clusters via Flux and the required deployment YAML.

Prerequisites

We need our own GitHub and Docker Hub accounts. In our Docker Hub account, we'll need a repository that we can push to from GitHub.

The Scenario

Our manager is interested in using Flux to synchronize a Kubernetes Cluster with Kubernetes Manifests stored in a GitHub Repo. The Development organization needs to push releases of their application up to Docker Hub, so that they can be deployed by Flux. The team would like us to set up a repository with the YAML required to use GitHub Actions Workflow to build the container, tag it, and push it to Docker Hub.

Fork the linuxacademycontent-gitops Repo in GitHub

Let's log into our GitHub account, and go to the content-gitops repository. Click the Fork button, and we'll land in a new fork in our own repository. We need to enable the workflow, so click on the Actions tab, then hit the green I understand my workflows, go ahead and run them button.

Create a Docker Hub Repository

In our Docker Hub account, we need to have a repository set up that we'll be pushing container images to. What we'll need from this on the Github end are our Docker username, password, and repository name.

Edit the Workflow to Push Your Container Images to the Docker Hub Registry

In the GitHub repository, get into the .github/workflows directory and click on the pythonapp.yml file in there. Click the pencil icon to edit it. We need to alter the last section:

        cd ./python
        docker login --username=cloud_user --password=${{ secrets.DOCKERPW }}
        docker image build -t cloud_user/gitops:hellov1.0 .
        docker push cloud_user/gitops:hellov1.0

We have to change the login information, the username (cloud_user here) and make sure the path is correct in the image build and docker push lines. We've also got to decide what we want to give this for a tag. Currently it's 1.0, but if we've already got images sitting in our repository, we'd want to bump that up to something higher like 1.1 or 1.2. It will depend on the newest version that's already up there.

Now press the Start commit button, then the Commit changes button.

With that finished, we have to make a change to that application. Navigate (in GitHub) to content-gitops/python and click on the app.py file. Edit the file, and change this:

return "Hello World!"

to something like this:

return "Hello LA Students!"

When we scroll down and click Commit changes, it creates an event on a push. If we go to the Actions tab, we should see that an instance of the workflow has now fired. If we click on that event, we can watch the process live.

It will fail now, because we haven't set a secret yet. Let's set one up now.

Click on the Settings tab, then Secrets in the left-hand menu, and then Add a new secret. Give the secret a name (DOCKERPW is a good idea, since that's how it's referred to in pythonapp.yml), and then enter the password for the Docker Hub account owning the repository that we're pushing to. Click the green Add secret button.

Once that's done, we can head back into app.py and make a new change. We'll edit that same line we did before so that now it says:

return "Hello LA Students Again!"

Click the Commit changes button again, and watch the execution in the same place we watched the failure. This one should succeed though.

Now let's go back to our Docker Hub browser tab, and refresh the page. Our new hellov1.x should be sitting there (where x is whatever we specified in pythonapp.yml).

Change The Python Application And Open A Pull Request

Instead of things firing off on push event, we want it to happen on a pull request. Edit pythonapp.yml again, and change the lines:

on:
  push:
    paths:
    - 'python/*'

We have to change push to pull:

on:
  pull_request:
    paths:
    - 'python/*'

Now we're going to create a feature branch, so back out at the main GitHub content-gitops page (ours, the one we've been working with, not the Linux Academy one) click on the Branch master dropdown. Put feature branch in the text box, and click on Create branch: feature branch. We'll be dumped into that new branch.

Get into this branch's app.py and change it. Make that line with hello read like this now:

return "Hello LA Student!"

Commit the changes.

Now get back into the master branch, out in the main content-gitops directory, and we've got a new green button, Compare & pull request. Click on it to start a pull request. On the next screen, there are a couple of dropdowns. The first is where we're pulling to, which we want to be our own master branch (the one in our content-gitops repository, not the Linux Academy one). The second should be the feature branch. As long as we get a green "Able to merge" note, we're good to go. Put a comment in there (something like Create Pull Request for Lab Demo), and we can click on Create pull request.

Out in the Pull requests tab, once we have no conflicts and all tests have passed, we can click on Merge pull request, and then Confirm merge. We'll get a message telling us it's safe to delete the feature branch.

If we look up in our Actions tab, we'll see the pull request fired off the application build. Further, if we go look in our Docker Hub repository page (and refresh it), we'll see that the new build got updated.

What about Flux?

So far, what we've done is essentially set up communication between Github and a Docker Hub repositories. We configured Github to send a rebuilt app.py to Docker Hub in a couple of scenarios, a push or a pull request.

But our manager wants to use Flux, and we haven't touched it. We're not going to either, but we are going to get ready for it.

Let's head into the docs folder in our master branch. In there is a Sample_YAML.md. Click on that to get it open. Grab the code under the The following is a YAML file to create a deployment of the sample Python Application. line.

Now navigate to the repository's workloads directory. Click the Create new file button. Name it hello.yaml, and paste that code we copied. Now we can set our version number correctly. The last line of code ends in hellov1.0. Set that 1.0 to our current version and click Commit new file.

Flux, if it was set up and running, would see this new version, and then deploy the new container to a Kubernetes cluster.