Occasionally you might want to add additional information to your Runs which isn’t handled on a first-class basis by Spacelift. You can attach this kind of information using the run metadata parameter, which is available through as well as the GraphQL API.
Usage
Let’s start with a small example. You’ll need a private worker for this.
On the machine where the worker resides, create a simple policy in a file:
package spacelift
sample { true }
And then start the worker with an additional environment variable:
This policy will make our launcher sample each evaluation and print it as a log on stderr.
We’ll also need a to which .
We can now trigger a run and provide an arbitrary metadata string:
~> spacectl stack deploy --id testing-spacelift --run-metadata "deploy-metadata"
You have successfully created a deployment
The live run can be visited at http://cube2222.app.spacelift.tf/stack/testing-spacelift/run/01FEKAGP4AYV0DWP4QDFTANRES
And in the private worker logs we should suitably see (formatted for readability):
~> spacectl stack confirm --id testing-spacelift --run-metadata "confirm-metadata" --run 01FEKAGP4AYV0DWP4QDFTANRES
You have successfully confirmed a deployment
The live run can be visited at http://cube2222.app.spacelift.tf/stack/testing-spacelift/run/01FEKAGP4AYV0DWP4QDFTANRES
In the policy sample log for the relevant metadata key we’ll see an additional entry, which was added when confirming:
And that's basically it! It's a very flexible building block which lets you build various automation and compliance helper tooling.
Run signatures
A standard use case for this feature would be to sign your runs when you’re creating them.
You'll have to bring the infrastructure for managing keys and signatures yourself - usually you'll already have something like that internally. But in short you can create a cryptographic signature of the parameters for a run you’re about to create - based on the commit SHA, run type, stack, date, etc. - and then you can pass that signature to Spacelift when creating the run.
Later, in the initialization policy you can use the to run your custom binary for verifying that signature. This way - for your most sensitive stacks - you can verify whether runs you are receiving from the Spacelift backend are legit, intentionally created by an employee of your company.