GitHub Actions: Reusable Workflows

With that being said, we can jump to the demo. I have prepared three examples. In this case, I’m going to show you the first example. This is a workflow. It’s called demo one. And here you can see that it will be triggered on workflow dispatch. This is basically when I go into the GitHub UI and press the Run button for this pipeline. Go into the deal, we have to go to the jobs part. Here in the jobs, we find a demo job. What this does is print a message on the console. To print a message on the console, what we should do is run an echo and then print “hello.” This will print the word “hello” in our console. Very basic. But as an example, instead of just running the command, Echo Hello, what I did is I’m using a reusable workflow that is located in my folder .GitHubActions and then print. If we go to .GitHubActions, and then print. This will automatically search for the action that YAML files. If we try to understand what’s inside this YAML file, we’ll see that we have an input, and this input is waiting for a message. The description is this is a message to print. We are sending what we want to print to the workflow. It’s as simple as running the command echo and then the input that we are sending. If I go to GitHub, go into the Actions tab, and then run the first demo, this may take a moment. This will run the demo one workflow. It will call the reusable workflow in this case to print a message and since we are passing the message in a variable, this is a message. This is the string that we’re passing. What we want our workflow to print in the console. We should see an output of “this is a message.” The workflow is already finished. If we go step by step, we’ll see that the first thing that the workflow did was pull the repository successfully. Then it went into the print message step here. This is called the reusable workflow in the repository, and sent the message, “this is a message” parameter. Here, we can see the command that ran. This has echoed, “this is a message” and here we have the output.

This might sound pretty boring because it’s pretty basic. I did another example of what we can do. Certainly, when we use workflows, we need to set up credentials for our AWS accounts for this in order to will get a list of objects in a bucket or a list of EC2 instances or whatever you need from AWS services. I have prepared a second example. This has an input that is called environment. In this environment, this is a type of choice. That means that you can choose one option between all of the options you have right here. In this case, is dev, staging, or prod. I did it like this because in the outside world or with the client’s environment, you’ll probably have more than one environment to choose from. If we dive into the jobs, we’ll see the steps and the first steps. The first step we find is the checkout step, where we get the code from our repository. The second step we find is Connect to AWS. This is calling our reusable workflow again located into our .GitHubActions in Connect folder. Here is our action, our action YAML file. Here is where it’s going to be run into workflow firm. Also, we are sending the environment variable with the value that we selected from the input. Diving into the workflow, we can see that we are using input for the environment. After that, we are using an Action to set up the AWS credentials here and the role to assume I have a function. This is being used to select one of the role errands depending on which environment we sent. Let’s say we selected the dev or the input is the dev environment, then this function will take charge of selecting the dev. If you notice, all of these errands are the same. This is because I use the nClouds account to create a show in order for this Friday demo. But in the real world, you’ll probably have different roles from different accounts. What this will do is let us access AWS resources, and set up AWS credentials for our action. We can proceed. We’ll do AWS CLI operations. In this case, what we’re doing is we’re listing all of the buckets in the nClouds account. I’m running the demo two action. I’m going to run it with the dev environment so that the action runs successfully. Again, going through the SSH. The first thing is checking out the repository. That means pulling the files to the machine where this is running, then we connect it to AWS. This is what I was talking about, that it’s using the reusable workflow. Then it’s connecting to AWS, as well as setting up the credentials for AWS. Finally, it’s getting all of the S3 buckets now that we have the permissions to do that. Here is a list of all of the S3 buckets that are existing in the AWS account.

I have prepared a third example. This is very similar to what we did for one of our latest clients. Basically, the task was to create an ephemeral environment every time a developer would want to develop a new feature. So let me show you the third and last example. We have this workflow with the name demo three. This works again, on workflow dispatch, which means it’ll run every time we go into the GitHub UI and press the wrong workflow. We have an input for the environment because we can have different environments, as I said before, and diving into the job. What this will do, going through the steps is that it will check out the repository in order to get the code that we need, then it will connect to AWS using the action that I showed you in the previous example, and then it will set up a Terraform. This is using, again, our reusable workflow that is located in .GitHubActions and then in the folder, TF.GitHubActions, and then in the folder TF. We are sending two variables to inputs, the working directory, where we have our Terraform code. This is the directory, TF, and workspace where we would like to create our resources. This is the workspace for Terraform. Basically, this is the workflow. Here we have three inputs, the workspace, which I have already explained, and the working directory, too. We have one more for the Terraform rubber. But we are not going to use this because we’re not going to deploy Terraform with other tools. So basically, we are using GitHub Action from HashiCorp, to set up Terraform. Then we are running Terraform in it. This is a process that we need to do in order to run our Terraform files. You can see that we are passing the working directory two. This is the working directory that we are defining in the inputs. Finally, we select a Terraform workspace. In this case, we tried to select the workspace and if the workspace is not created, then we create the workspace. With that workflow, when that workflow runs, basically we have Terraform to use it in our action.

So here in the next step, I am running a Terraform plan in order to see what resources are being created, so going into the TF folder, and then running Terraform plan. For those who are a bit curious. The Terraform I have here is very basic. I’m just defining a provider for AWS defining a region and for the main TF, defining a simple S3 bucket. Nothing too complicated. If we run this, we should go to the GitHub UI. Go to demo three and then run the workflow.

Again, I’m going to use the development environment, but I could use any of those options. We should see the demo running the pipeline completed successfully going through the steps again. First, we have the checkout. This is running successfully, then we connect to AWS, again with the reusable workflows that I showed you before. After that, we do the Terraform setup. Again, using the reusable workflow. This uses the HashiCorp, setup Terraform v2, which basically installs Terraform into the machine and lets us use the Terraform command line. After that, we run the Terraform init command. This will enter the folder where we have our code on. After that, we try to select the dev workspace. But this doesn’t exist. So we created a workspace. And finally, after that, we were on the Terraform plan. So we run into the TF folder and then Terraform plan. Here we can see the plan for the resources that we are trying to create. As I said before, this is an example of a deployment with it for a client. I think reusable workflows are a great help for this because if not, we’ll have to, let’s say for example, we’ll have to have this piece of code in every time we call this action. We would have it in one or two workflows. We are saving code. We are not repeating ourselves and it’s way easier to manage and for people to understand when they are starting to see the pipelines that you’re working on.