Suppose you’re working on a client application that interacts with some AWS backend services. You want to ensure that your backend is in place while you focus on your main application. As you might have anticipated, we’ll look at how to set up a workflow that ensures our infrastructure provisioner consistently delivers what is needed to run our apps on.

In the context of infrastructure testing and system interaction checks, GitHub Actions can be used to automate and streamline essential tasks, such as infrastructure testing, integration testing, and end-to-end testing.

The infrastructure we have:

Let’s say that all of these resources are configured using Terraform. It may not look like much, but the file creating these services can get lengthy, so monitoring it and ensuring that everything is there might be hard. Not to mention, there are roles and permission policies at play that we don’t often see. Luckily, there’s a way to set up a mechanism that has repetitive actions with predictable outcomes, which will be our safety check that the services we need are always there. We achieve this through GitHub Actions.

TL;DR: GitHub Actions is a powerful CI/CD (continuous integration and continuous deployment ) platform that allows you to automate various workflows, such as building, testing, and deploying your code directly from your GitHub repository.

A workflow configuration file specifies the steps and actions to be executed whenever a certain event occurs, such as a push to the repository. GitHub Actions will automatically detect the new workflow configuration and execute the defined steps whenever a push event occurs. The workflow status and logs will be visible in the "Actions" tab of your GitHub repository.

Our entire YAML file can be found in the https://github.com/tinyg210/stack-bytes-apigw-lambda-s3 repository under the .github/workflows folder, where it will be automatically picked up from.

Whenever we build a workflow, there are key aspects that should not go unnoticed:

Name and Purpose: A clear and self-explanatory title that can answer the following: What does it do? Why is it useful? Create and Verify Infrastructure on LocalStack - a concise yet descriptive sentence.

Workflow Triggers: Indicate when and under what conditions the action is triggered. We’ll run our checks on each push against the main branch but ignore changes to the README.md file, as those are irrelevant here.

Environment: Define the environment or context in which the action runs. We’re storing our LOCALSTACK_API_KEY as a secret that GitHub will encrypt and manage.

Steps and Actions: The steps or actions composing the workflow. The steps we need to have in our infrastructure-check workflow are actually quite simple, and GitHub Actions uses YAML-based configuration files to define this process:

Dependencies: If the action depends on other services, tools, or resources, we need to bring them in for successful execution and prepare the workflow context. We start with runner (VM executing the workflow) - ubuntu-latest , and we also set up a JDK, install Python, aws-local CLI, terraform-local CLI, etc. In our diagram, we’re interested in what happens after the dotted line. Anything before that is just preparing the ground.

Error Handling: How the action handles errors or failures. In this case, It’s enough to check the logs and the messages they’re presenting, but also get a diagnose report from a LocalStack endpoint, in case that’s where the process failed.

By covering these aspects in your GitHub Action description, you'll provide your team with a clear understanding of what the action does, how to use it, and what to expect when incorporating it into other workflows. This is how you ensure that your dependencies are in place every time.