It uses which by default checks out the code of the branch you are making the PR from - i.e., your feature branch.
lint is just the identifier for the job in case we need to reference it elsewhere.) It creates an ubuntu-20.04 VM with three steps that will execute on it. (Note that we could have called it anything. There is currently only one job in this workflow, lint. We can make our code changes and run git push again to re-trigger the check. This is useful for example if we create a PR and then it fails the linting step. This is part of the default behavior for the pull_request event trigger. Subsequent pushes to the feature branch will also trigger this workflow. The workflow is triggered by the event of a pull request being made against the main branch. name: Run terraform fmt check run: terraform fmt -check -diff -recursive.
name: Check out code uses: name: Setup Terraform uses: with: github/workflows/plan-on-pr.yml like this: Let’s make it so when we create a PR against the main branch it will run terraform fmt and let us know if our code complies with canonical format and style.Ĭreate a workflow file at.
#Plain text workflow full
Lintīefore we do a full terraform plan let’s do something a little easier. This takes one job definition and creates multiple separate jobs that can execute in parallel. For each job there is a VM created and then its steps execute on said VM.įor some of our jobs we will employ the matrix strategy. Workflows contain one or more jobs while jobs contain one or more steps. Steps run on said VMs and can share files and env vars as they are on the same machine Jobs create individual “runners” - you can think of them as VMs. They can also be manually triggered through the GitHub UI. They are triggered by events like pushing to the main branch or creating a pull request.
If you aren’t familiar with GitHub Actions here is a little bit to help you follow along. We will start simple - such that the code runs - and then progressively throw on enhancements like shorter plan messages, and colored diffs. When a PR is merged to the main branch we want to run terraform apply.When a PR is created against the main branch (or when a PR is updated) we want to run terraform plan.What we really want to exhibit is the workflows. It’s deployed into three virtually identical environments: dev, stage, and prod.Īll we need to know is that it takes a single input variable to restrict which account the code will be run against.ĭescription = "The id of the one AWS account this code is permitted to run against"Īllowed_account_ids = It creates a dummy application that consists of a single EC2 instance. It’s there as a placeholder just so there is something to run the workflows against. GitHub Actions will run terraform apply using the approved plan.Once the code and the plan output is reviewed and accepted it is merged to the main branch.GitHub Actions will generate a Terraform plan and put it in the PR comments for review.When you are happy with the plan description create a PR against the main branch in GitHub.Develop code against a feature branch and locally run terraform plan as you make changes.The code herein fits the use case of your average GitOps workflow for Terraform: Enhanced formatting on the terraform plan output.One to cover the terraform plan phase and another to cover the terraform apply phase. If you are already using GitHub and Terraform this guide should serve as a considerable shortcut in making your own infrastructure deployment pipeline.įirst we’ll cover some of the basics of GitHub Actions, then we’ll dig into building two distinct GitHub Action workflows. You can find all of the code from this post in the repo. The results are compelling and worth sharing so I built a small example repo to demonstrate some of our findings. We experimented with using GitHub Actions, Terraform, and AWS together in a GitOps-style workflow. I’ve recently had the exciting opportunity to work with Pathstream on their infrastructure automation.
0 kommentar(er)
