Workspace building blocks as context metadata input in building block definition
L
Lucas Kuhring
We would like to request the feature to retrieve information about all created building blocks in the workspace as part of a building block definition. A possible and probably elegant way to do that would be to extend the "context metadata" input variable types with a type for "Workspace Building Blocks".
Comparable to other "context metadata" input types, this input would hold a list of building blocks that are currently booked under the workspace (probably including the one that contains the input itself in case that building block was created), and would dynamically trigger updates on the building block with this input as soon as new building blocks are created/updated/removed. The list of building block can then be iterated, filtered and processed inside the Terraform code.
Having this kind of input would allow to handle relations between building blocks, that are currently very limited (one building block can only depend on one other), in the most flexible way. One building block might want to get information about other building blocks in order to implement certain permission structures or other "orthogonal" concerns.
Maximilian Wipplinger
Maybe the context metadata could even be filtered/configured to only "listen" to changes to building blocks from specific building block definitions.
A specific use case example would be the following:
We deploy a GitHub Org/Repository via a Building Block. This is usually the starting point for a new Project. Then customers book new instances in several other development tools like an artifact repository and code scanning tools. Every project has different needs so each additional booked service is optional as not every tool is used for every project.
Now that some additional Tools have been booked we would like the GitHub Building Block to trigger again and be able to ingest the information of other optional booked services in the workspace/project and automatically provision the necessary secrets on the repository/org.
I hope I was able to communicate the idea and what kind of use cases we would see for a feature like this.
Potential dangers of a feature like this would be the chance to create "infinite" update loops when two Building Blocks would listen to changes to one another and have outputs that always change.