Elevating IaC Workflows with Spacelift Stacks and Dependencies 🛠️

Register for the July 23 demo →


Introducing Context Auto-Attachment

Introducing Context Auto-Attachment

Adding bulk context attachments to stacks just got a whole lot easier!

Spacelift’s Context feature allows you to group environment variables and mounted files in a logical container that is managed in a separate way from stacks and is attachable to as many stacks as you want.

Until now, if you wanted to attach a context, you had to go to a stack’s settings, select contexts, and attach contexts one by one manually. This worked well, and if you wanted to have bulk attachments, you could add them easily via our Terraform provider.

What’s new in contexts?

Now you can add bulk attachments by auto-attaching contexts to multiple stacks at a time, and for convenience, we’ve added this functionality based on labels.

And that’s not all – at Spacelift, we like to stress flexibility, so now you can also add behavior hooks to contexts, through Context Hooks, taking reusability to the next level. This enables you to control what happens before and after all the runner phases. By adding this capability to your contexts, you can ensure that all stacks that have this context attached will perform the same commands in the respective runner phases, keeping your configuration DRY.

Let’s dive into the reasoning behind this and the steps for using the new functionality.

Why use contexts in the first place?

For some stacks, you will need to reuse the same variables and/or files and install/configure the same tools. As contexts are a shareable bundle of configuration items, it makes sense to manage these from a single place, rather than adding them to all the stacks and managing them independently.

You can still override the values you receive from contexts at the stack level if that is something you require.

Why auto-attach a context?

Auto-attaching a context to all stacks that have a specific label you set up when you create or edit a context, saves time when configuring your stacks. It enhances the overall efficiency of your processes while improving accuracy and consistency, keeping human error to a minimum.

Why define Context Hooks?

Some stacks will install and configure the same third-party tool, some require downloading a file, and others may need to run a particular script. If you don’t use hooks from the context level, you will need to define the same configuration repeatedly, which can lead to worse maintainability and mistakes, making the debugging process harder, especially with a growing number of stacks.

How to create a context with auto-attachment and hooks

Before showing how to define auto-attachment for a context, we will first need to create a context.

You will see that the context view has been revamped, giving you more flexibility with what you can do when you are creating them.

Let’s create the context. To do that, go to Contexts and select Create context.

create context

You will need to provide some details, such as the name of the context, the space in which the context will reside, an optional description, and labels – here is where the magic comes into play. If you add a label in the following format: autoattach:label_name, all stacks that have that label_name, will automatically attach this context.

For this example, I will use the label_name dev:

add context details

As soon as I’ve added the autoattach:dev to my context, it automatically finds all existing stacks that have the dev label (in my case, dev1 and dev2) and, as soon as this context is created, it will be attached automatically to these stacks.

In the next screen, you can select where else would you like to attach your context (stacks and modules):

attach context

After selecting the stacks and modules you want your context to be attached to, you can define environment variables and mounted files that will reside in this context:

setup environment

In the last screen, we arrive at another important point – adding hooks:

add hooks

You can choose which runner phase you want to customize the workflow in. There are six runner phases available:

  • Initialization
  • Planning
  • Applying
  • Destroying
  • Performing
  • Finally

In the above example, I am installing tfsec in a before init hook, running it, and redirecting the output in a file called tfsec.custom.spacelift.json (this will enable me to define custom policies for it as shown here).

All stacks that have this context attached will perform these steps before the initialization of the workspace.

After creating the context, we can see all the details in the revamped view:

dev contexts

You can easily check which environment variables and mounted files are defined, which hooks are in the context, and which stacks are using them.

Key points

At Spacelift, we always consider feedback – this is how we build a sophisticated product that addresses the problems customers are facing.

With the ability to auto-attach a context, the context hooks, and the view revamp, you can build a more powerful workflow, while keeping your configuration DRY and minimizing the chances of human error. 

If you want to learn more about Spacelift, create a free account today or book a demo with one of our engineers.

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 for infrastructure management.

Start free trial

How can Spacelift stacks & dependencies elevate your IaC workflows?

Don’t miss our July 23 webinar.

Register for the webinar