Per-Run Execution Context for Building Blocks
Sebastian
As an engineer, I want to be able to provide temporary, run-specific information to a Building Block that can be used during that run without permanently changing its configured state.
The implementation could be per-run metadata, temporary input overrides, or a one-off input change. The information should be available to the Building Block for that specific run and does not affect subsequent (manual) runs.
Use case:
We have a Building Block orchestrator that triggers scheduled runs in different modes. The orchestrator needs to provide additional information or partial input changes, so the Building Block can determine how it should execute.
These orchestrated runs should:
- appear normally in the Building Block's run history,
- provide the temporary information to the Building Block during execution,
- allow the Building Block to use that information to select its execution mode, and
- leave the Building Block's previously configured state unchanged for the next run.
The goal is to support one-off, orchestrated executions with temporary context or inputs, without requiring a second run to restore the Building Block's normal configuration.
J
Johannes Rudolph
Interesting use case for sure. Linking https://feedback.meshcloud.io/feature-requests/p/operator-escape-hatch-one-off-maintenance-runs-for-building-blocks which describes a related set of problems, mostly looking at pre-run script injection
Janny the AI Product Manager
Thanks for taking the time to write this up — this is a really clear and thoughtful request.
Per-run context / temporary input overrides for Building Block runs makes a lot of sense, especially for orchestrated or scheduled executions where you don’t want to mutate the saved configuration just to influence a single run. We’ll share this with the product team.
To help us understand the best shape of this, could you clarify a couple things?
1) What kind of “temporary info” do you envision most often (e.g., a small metadata map, specific input fields overridden, or an explicit “mode” parameter)?
2) Should this per-run context be visible in the run details/audit trail (and if so, should it be editable or strictly read-only once the run starts)?
3) How should conflicts be handled if a per-run override provides a value for an input that’s also set in the Building Block’s saved configuration (override wins, or validation error)?
Sebastian
Janny the AI Product Manager
1) A string, that can carry a JSON object.
2) Yes that would be nice for audit trails.
3) I would treat it as additional input and let the building block decide what has precedence.
Currently, we use an OSB that we want to replace with a building block.
Our OSB is based on the
unipipe-service-broker
project, which we use to manage instance status updates, among other things.The OSB stores instance status information in a Git repository that serves as our inventory. Changes to this repository, as well as a nightly schedule, trigger an orchestrator pipeline.
For each affected instance, this pipeline initiates a deployment pipeline within the respective customer AWS account and subsequently writes the updated status back to the Git repository.
A key feature of our current solution is that the orchestrator pipeline passes different parameters depending on the trigger:
During a scheduled nightly run, only specific components are deployed.
When the orchestrator pipeline is triggered manually, we can also specify which components should be deployed.
With Building Blocks, we aim specifically to avoid the redundant management of instances within the Git repository.
We already know how to trigger Building Block runs via a pipeline. However, it is not yet clear to us how we can pass dynamic inputs to a Building Block run at the time of triggering so that inputs would subsequently be forwarded to the Building Block's deployment pipeline.
Our goal is to set parameters for instances within our orchestrator pipeline that influence the deployment behavior of a specific Building Block run for that single execution. This would allow us to deploy specific components selectively without having to make permanent configuration changes.