Environment
This article describes the environment in which each workload (run, task) is executed
Last updated
Was this helpful?
This article describes the environment in which each workload (run, task) is executed
Last updated
Was this helpful?
If you take a look at the Environment screen of a stack you will notice it's pretty busy - in fact it's the second busiest view in Spacelift ( being the undisputed winner). Ultimately though, all the records here are either or . The main part of the view represents the synthetic outcome determining what your run will "see" when executed. If this does not make sense yet, please hang on and read the remainder of this article.
...and so is editing:
Overriding a computed value is almost like editing a regular stack variable, although worth noticing is Override replacing Edit and the lack of Delete action:
When you click Override, you can replace the value computed at runtime with a static one:
Note how it becomes a regular write-only variable upon saving:
If you delete this variable, it will again be replaced by the computed one. If you want to get rid of the computed variable entirely, you will need to disable the integration that originally led to its inclusion in this list.
The Spacelift flow can be broken down into a number of stages - most importantly:
The first token will potentially be exposed to less-trusted code, so it makes sense to create it with read-only permissions. The second token on the other hand will only be exposed to the reviewed code and can be given write or admin permissions.
A similar approach can be used for AWS, GCP, Azure, or any other cloud provider credentials.
It's almost like creating an environment variable, though instead of typing (or pasting) the value you'll be uploading a file:
When discussing mounted files, it is important to understand the structure of the Spacelift workspace. Every Spacelift workload gets a dedicated directory /mnt/workspace/, which also serves as a root for all the mounted files.
Mounted files may be put into /mnt/workspace/source/ as well and it's a legitimate use case, for example, to dynamically inject backend settings or even add extra infra definitions. Just beware of path clashes as mounted files will override your project source code in case of conflict. Sometimes this is what you want, sometimes not.
...and here they are in the form for the new mounted file:
The concept of environment variables is instinctively understood by all programmers. It's represented as a key-value mapping available to all processes running in a given environment. Both with Pulumi and Terraform, environment variables are frequently used to configure providers. Additionally, when prefixed with TF_VAR_ they are used in Terraform to input variables.
Spacelift does not provide a dedicated mechanism of defining because the combination of TF_VAR_ environment variables and mounted files should cover all use cases without the need to introduce an extra entity.
Adding an environment variable is rather straightforward - don't worry yet about the visibility (difference between plain and secret variables). This is described in a :
You will possibly notice some environment variables being marked as <computed>, which means that their value is only computed at runtime. These are not directly set on the stack but come from various integrations - for example, AWS credentials (AWS_ACCESS_KEY_ID and friends) are set by the and SPACELIFT_API_TOKEN is injected into each run to serve a number of purposes.
You cannot set a computed value but you can override it - that is, explicitly set an environment variable on a stack that has the same name as the variable that comes from integration. This is due to precedence rules that warrant its own .
The Spacelift environment section lists a special subset of that are injected into each run and that provide some Spacelift-specific metadata about the context of the job being executed. These are prefixed so that they can be used directly as input variables to Terraform configuration, and their names always clearly suggest the content:
, where we prepare the workspace;
, which calculates the changes;
, which makes the actual changes;
In this model, only the phase makes any actual changes to your resources and your state and needs the credentials that support it. Yet frequently, the practice is to pass the same credentials to all stages. The reason for that is either the lack of awareness or - more often - the limitations in the tooling. Depending on your flow, this may be a potential security issue because even if you before it reaches the stage, .
Spacelift supports a more security-conscious approach by allowing users to define variables that are passed to read (in practice, everything except for ) and write stages. By default, we pass an environment variable to all stages, but prefixes can be used to change the default behavior.
An environment variable whose name starts with the ro_ prefix is only passed to read stages but not to the write () stage. On the other hand, an environment variable whose name starts with the wo_ prefix is only passed to the write () stage but not to the read ones.
Combining the two prefixes makes it easy to create flows that limit the exposure of admin credentials to the code that has been thoroughly reviewed. The example below uses a GITHUB_TOKEN environment variable used by the variable split into two separate environment variables:
Every now and then an environment variable is not what you need - you need a file instead. Terraform Kubernetes provider is a great example - one of the common ways of configuring it involves setting a which needs to be present in your workspace as well.
Similar to environment variables, mounted files can have different visibility settings - you can learn more about it . One thing to note here is that plaintext files can be downloaded back straight from the UI or API while secret ones will only be visible to the executed for the .
Mounted files are limited to 128kB in size. If you need to inject larger files into your workspace, we suggest that you make them part of the , or retrieve them dynamically using something like wget or curl.
Your Git repository is cloned into /mnt/workspace/source/, which also serves as the working directory for your project, unless explicitly overridden by the project root configuration setting (either on the or on in the ).
While contexts are important enough to , it's also crucial to understand how they interact with and set directly on the , as well as with . Perhaps you've noticed the blue labels on one of the earlier screenshots. If you haven't, here they are again, with a proper highlight:
The highlighted label is the name of the that supplies those values. The sorted list of attached contexts is located below the calculated environment view, and each entry can be unfurled to see its exact content.
Similar to , those coming from contexts can also be overridden. Here's an example:
Note how we can now Delete the variable - this would revert it to the value defined by the context. Contexts can both provide as well as , and both can be overridden directly on the stack.
If you want to get rid of the context-provided variable or file entirely, you will need to .
Perhaps you may have noticed how and come in two flavors - plain and secret. Here they are in the form for the new environment variable:
Functionally, the difference between the two is pretty simple - plain values are accessible in the web GUI and through the , and secret ones aren't - they're only made available to and . Here's an example of two environment variables in the GUI - one plain, and one secret (also referred to as write-only):
Mounted files are similar - plain can be downloaded from the web GUI or through the , and secret can't. Here's the difference in the GUI:
While the content of secret (write-only) environment variables and mounted files is not accessible through the GUI or , the checksums are always available so if you have the value handy and just want to check if that's the same value as the one set in Spacelift, you can compare its checksum with the one reported by us - check out the most recent schema for more details.
Though all of our data is , secret (write-only) values enjoy two extra layers of protection.
