
Terraform is a popular tool used for infrastructure automation. With Terraform, it becomes easy to manage complex infrastructure deployments across multiple cloud providers. However, managing the infrastructure as code with Terraform can become tedious and time-consuming when done manually. To solve this problem, many teams are using Git-based workflows and tools like GitHub Actions to automate the process. In this blog post, we will discuss how to automate Terraform pull requests using GitHub Actions.
A pull request (PR) is a feature of Git-based code repositories like GitHub. It allows contributors to propose changes to a codebase, and then submit those changes for review by other members of the team. Once the PR is approved, the changes can be merged into the main codebase.
GitHub Actions
GitHub Actions is a CI/CD tool that allows users to automate workflows for their GitHub repositories. It integrates with GitHub repositories, and can be used to automate the building, testing, and deployment of code.
GitHub Actions also allows users to define custom workflows using YAML files. These workflows can be triggered by various events, including pull requests, pushes to a branch, or scheduled events.
To automate Terraform pull requests with GitHub Actions, we need to create a workflow that performs the following tasks:
Let's take a look at how we can accomplish each of these tasks using GitHub Actions.
Step 1: Check out the Pull Request Branch
The first step is to check out the pull request branch. This can be accomplished using the actions/checkout action in the GitHub Actions workflow.
name: Terraform Pull Request
on:
pull_request:
types: [opened, synchronize]
jobs:
terraform:
runs-on: ubuntu-latest
steps:
- name: Checkout Pull Request
uses: actions/checkout@v2
with:
ref: ${{ github.event.pull_request.head.ref }}
This workflow defines a job named "terraform" that runs on an Ubuntu virtual machine. The job has a single step that checks out the pull request branch using the actions/checkout action. The "ref" input is set to the pull request head reference, which ensures that the workflow checks out the correct branch.
Step 2: Initialize Terraform
The next step is to initialize Terraform. This can be accomplished using the hashicorp/setup-terraform action.
- name: Setup Terraform
uses: hashicorp/setup-terraform@v1
with:
terraform_version: 1.1.0
This step uses the hashicorp/setup-terraform action to install Terraform on the virtual machine. The "terraform_version" input is set to the version of Terraform that we want to use.
Step 3: Plan the Terraform Changes
The next step is to plan the Terraform changes. This can be accomplished using the hashicorp/terraform-action action.
- name: Terraform Plan
id: plan
uses: hashicorp/terraform-action@v2
with:
terraform_version: 1.1.0
args: plan -out
Stream is the AI-native platform built to fight AI-enabled attacks. It autonomously prevents, detects, hunts, and remediates exposures and threats across production at machine speed - driving risk toward zero. It replaces the fragmented stack of scanners, runtime agents, exposure tools and playbooks with one live model of production.Defending Production needs a new approach: Stream is the only Autonomous Production Defense Platform that works across your entire production estate. It runs on a patented CloudTwin®, a high-fidelity security data harmonization layer that models Cloud, SaaS, identity, runtime, AI, network, perimeter, on-prem, security controls, and the behavior running on top of them into one live model of production: real-time, fully correlated, continuously updating. Not a snapshot. And it does not stop at boundaries - the boundaries that fragment every other tool are the same boundaries an attacker moves across. Inside CloudTwin they are one system.