When collaborating on infrastructure-as-code in a team environment, users typically follow a pull-request-driven workflow. This pattern is quite common throughout the software development industry, and there are various approaches in branching strategies that can be taken when working with pull requests.
For simplification during this article, we will be assuming that users are following a GitHub Flow branching strategy, which utilizes short-lived feature branches.
When following GitHub Flow with Spacelift, a user will create Spacelift stack(s) configured to track a specific repository and branch (and sometimes even for specific folders within a repository’s branch when working with mono-repositories).
When ready to make changes, the user will then create a feature branch based on the stack’s tracked branch, typically “main,” which represents the source of truth. After making their feature branch, the user will complete changes in their infrastructure-as-code to add/update/remove resources in the code itself and then commit/push these changes to their feature branches on the remote repository.
The user will then wish to review the result of the plan command on the pull request itself (executed by Spacelift) after their changes have been pushed to the remote. For Terraform users, the plan result is the output of the terraform plan command. Similarly, for other backends (e.g., AWS CloudFormation), the plan result is the outcome of the changeset generated from the changes made.
Spacelift supports two different methods for receiving the plan result from your pull request, which we will cover in this article: Pull Request Checks and Pull Request Plan Commenting. In addition to this functionality, users can also optionally take action(s) in Spacelift based upon pull request comments or label events.
Note: With Spacelift, you can also obtain the result of the plan command locally using the spacectl local preview functionality.
By default, when changes are pushed to a feature branch with an open pull request for a repository configured as a Spacelift Stack – Spacelift will create “Checks” on your pull request with the outcome of any plan(s) that were related to any proposed runs triggered on the appropriate stack(s). This behavior is highly customizable, but in general – the outcome of a “Check” looks like this, accessible from your pull request:
As an optional feature, the ability to comment the result of the plan directly on your pull request can be enabled on a per-stack basis. This feature is optional, as commenting on pull requests can become quite noisy in terms of receiving notifications.
To enable this feature, you’ll need to add the label feature:add_plan_pr_comment onto any stack you wish to enable plan commenting for. Once the label is added, on future pull requests which create proposed runs, the result of the plan will be added as a comment to your pull request. Here’s a quick video showing this functionality:
In addition to simply being able to receive the output of the plan on your pull request, Spacelift also supports the ability to take action in Spacelift based upon a comment by a user on the pull request itself. This feature is most commonly used for achieving comment-driven deployments.
Why would I want this feature, you may ask? Well, some users prefer the ability to deploy their changes before merging, a functionality that seemingly originated from Atlantis, an open source tool used for Terraform deployments. Whether or not to allow the ability to deploy your changes before merging is up to you at the end of the day.
As an example, a user may configure a Push policy on their stack that looks as follows:
package spacelift
track {
input.pull_request.action == "commented"
input.pull_request.comment == concat(" ", ["/spacelift", "deploy", input.stack.id])
}To help us understand how this works, let’s imagine an example scenario where the policy above was attached to a hypothetical example stack we’ll call stack-a. This policy will listen for pull request “commented” events, and if a user adds the comment “/spacelift deploy stack-a” to their pull request then a tracked run would be created for the stack, allowing users to deploy changes directly from their pull request if desired.
Note: Spacelift will only monitor for comments that begin with “/spacelift” to help prevent unintended actions within Spacelift.
Similar to the comment-driven deployment functionality mentioned, you can also utilize pull request labels to take action within Spacelift. For example, perhaps you would like to trigger a deployment when the label “ephemeral” is added to your pull request. To achieve this result, you would attach a Push policy to your Spacelift stack similar to the following:
package spacelift
track {
label := input.stack.labels[_]
startswith(label, "ephemeral")
pr_label := input.pull_request.labels[_]
label == pr_label
}Users can always customize Push policies such as this one to their liking, providing a lot of flexibility.
Spacelift supports two primary ways of obtaining the outcome of your plan commands on your pull request: PR Checks and PR Plan Comments. Furthermore, you can also utilize comments or labels on your pull request to take action in Spacelift.
Thank you for reading this article. If you found any value in this article, please feel free to share it on your favorite social media platform of choice. Wishing you the best of luck in your infrastructure-as-code efforts!
Also, if you aren’t already using Spacelift, get started on your journey by signing up for a Free Trial and taking it for a spin around the world!
The Most Flexible CI/CD Automation Tool
Spacelift is an alternative to using homegrown solutions on top of a generic CI. It helps overcome common state management issues and adds several must-have capabilities s for infrastructure management.
