Implement pull request-based workflow using Terraform, Infracost, Checkov, and GitHub Actions

The software development process has continuously evolved over the past several years. The evolution process continued with the wide-scale availability of cloud platforms like AWS and Azure. We realized the practice of infrastructure as code (IAC) when the development practice of coding was merged with the operations practice of creating and managing cloud infrastructure. Then, with the infrastructure as code mindset, we realized benefits like versionable, repeatable, and testable processes. In this note, I explore the nuances of deploying an infrastructure change of operations process using the familiar pull request-based workflow of the development process.
As a reader of this note, you might be familiar with the development practice of using a pull request-based workflow. So that we are all on the same page, a pull request-based workflow encourages collaborative development within a team. It acts as a gate for new changes before merging them into the stable version of the product/application, which generally is managed via the project’s branching-merging strategy.

A pull request highlights the code difference between the stable version of the product (generally in the main branch) and the changes in the incoming branch (in the pull request). A pull request could contain a fix to a bug or add new features to the product/application. The pull request reviewer must review the difference in the incoming code and decide whether merging that code enhances the existing code in the main branch. Reviewing pull requests can become cognitively demanding and time-consuming for the reviewer, and hence there are additional workflows that can improve the experience.

In the case of IAC code using Terraform, I have automated three review workflows in a pull request that can help the reviewer better understand the code changes in the pull request. These are:
1. Executing the terraform plan step and updating the pull request comments with the proposed changes.
2. Generating a cost estimate report of the resources before the pipeline provisions them.
3. Scanning the code for security vulnerabilities.
I will cover each of these workflows in the following few paragraphs.

In this note, I show how to implement a pull request-based workflow using InfraCost, Checkov, and Terraform using GitHub Actions.

1. Execute terraform plan and update the pull request comment.

There are two steps to achieving the above objective -(i) Run the terraform plan command in the GitHub actions pipeline, and (ii) update the pull request comment with the findings of the command.

Below is an image of the terraform plan step. As you can see from the if condition, this step will run for either of the two conditions – if the branch is not main (generally when working on a separate private branch) and if the pipeline trigger event is a pull_request.

After running the terraform plan command, the below step updates the pull request comment with the findings of the terraform plan output.

Here is an example of a pull request to view the comment posted by the above step. You can also expand the **Show plan** button to view the command output. As you can see, the pull request comment makes it convenient for the reviewer to review the infrastructure changes without leaving the pull request console. Moreover, since the pull request executes only the terraform plan step, the changes are not deployed, which provides necessary guardrails to the development process. If you want to learn more, you may access this article, where I have a link to my GitHub repo with a sample code.

2. Generate a cost estimate of the resources.

Knowing what infrastructure changes will be deployed by the pipeline in a pull request is helpful if the reviewer can also get a resource cost estimate. That is possible using Infracost. I came across Infracost and integrated the pipeline into my GitHub repository. In less than 15 minutes, I had the YAML file ready and checked into my repository. On a subsequent pull request, Infracost added a cost estimate of the infrastructure changes in the pull request comment. I have a detailed note on how I used Infracost -using the HCL code option or the Terraform plan option in my note at  –Estimate AWS Cloud resource cost with Infracost, Terraform, and GitHub Actions.

3. Scan the code for security vulnerabilities.

Automating the security code review of the incoming changes in a pull request ensures that the code is scanned for security vulnerabilities before it is merged to the stable version of the code, which is usually the main branch. The automated process creates a code review report that informs the pull request submitter and the reviewer of the code quality in the pull request. I have a detailed note on integrating GitHub Actions with Checkov at automate-terraform-configuration-scan-with-checkov-and-github-actions.

These three integrations in a pull request empower and educate the entire project team working with the code repository to create workable infrastructure code and ensure it is secure and cost-efficient.

And that brings us to the end of this note. If you followed me here, thanks, and do not hesitate to ask me any questions.