Feature Requests

As a Building Block developer, I want to execute tofu import statements in order to import existing resources into the terraform/tofu state. This action is needed, if I want to modify an existing building block or if I want to migrate an existing OSB to a building block representation. Since the tofu workspace name is not known in advance, it is currently impossible to write a proper migration script. One solution could be to pass an initialization script (with the tofu import statements) before executing tofu apply inside the building block Terraform runner.

I’m facing an issue where SSH keys are not allowed in my GitHub/GitLab environment. I want to use a GitLab deploy token instead, which works with the following URL format: https://gitlab+deploy-token-00000:gldt-00000000@gitlab.com/my-instance/my-project.git However, during Git operations, the SSH configuration still pops up automatically, and I have to enter dummy values just to proceed. It would be much better if I could consistently use HTTPS with a deploy token, but unfortunately, this exposes the token in plain text in the URL, which is a security concern.

In the "General" tab of the BB definition you can only select platform types for the supported platforms even though the header "supported platforms" suggests, that you should be able to select individual platforms. This is at the very least misleading. We would like to be able to select the platform instead of the platform type here.

I would like to have the ability to perform "dry-run" executions on Terraform building blocks. This would allow me to preview the output of terraform plan before executing an actual terraform apply . This feature would be especially useful in scenarios such as: Upgrading building blocks: Validate changes introduced by version updates before applying them. Testing inputs: Confirm that inputs to a module behave as expected. Essentially getting insights on potential changes without affecting infrastructure.

As a Platform Team we want to create and define Building Blocks which follows security principals regarding the permission for the azure automation user. SPNs often requires higher permission (or more privileges RBAC roles) than actually required. Therefore providing a way to authenticate e.g. via AZ CLI or other means for normal users (Entra Users) for the automation instead of SPNs would be required. Actual examples of the limitation of SPNs and required need of higher permissions: https://www.reddit.com/r/AZURE/comments/1b1mhs3/service_principal_not_able_to_modify_app/ https://github.com/hashicorp/terraform-provider-azuread/issues/807

As a platform engineer I want to get an ephemeral (short-lived, limited purpose) API key for meshStack in my building block run. This would enable me to interact with meshStack as part of a building block run (e.g. provision a new building block in the background) without needing almighty admin permissions. The UI should show in the marketplace when a building block uses this so it is transparent to users what side effect certain building blocks might have. It could show for examlpe "This building block has the permission to provision other building blocks in your workspace.". My use case is that I want to provide an "extension" of another building block. Rather than defining a dependency and having the user book both, I want to automatically create a Building Block via Terraform in the background.

Similar to a Tenant Building Block, we would like to have the option to use the Workspace permissions as an input in a Workspace level Building Block. Use case: We have a Building Block that creates Entra ID Groups. The user currently has to provide a list of email addresses that will be added as owners to the group. It would be easier to just set all Workspace managers and owners as the group owners. And the Building Block would update itself whenever the permissions change in the Workspace.

As a developer adding and testing a new building block version is cumbersome as an existing building block can not be "upgraded" into the draft version. Currently, especially if its a "apply once" building block you need to create a new tenant/project to apply it or remove the old one and re-apply the new building block as draft. This might not always be easily possible. It also only allows testing the "upgrade" procedure once the building block is released and an admin actually performs the upgrade into the new version. If you could already "upgrade" into a draft version this transition could be tested beforehand.

When I have a terraform module with a name like "workspace_identifier" meshStack right now detects this as a simple string user input. It would be a nice convenience if meshStack automatically recognized a few common patterns and set the right types instead workspace_identifier => Source: Workspace Identifier project_identifier => Source: Project Identifier account_id, subscription_id, project_id => Source: Platform Tenant Id

I'm working on a new building block and have a few runs failing due to issues with my terraform code. I have to go back from runs to the definition a lot to fix inputs and outputs configuration. When I'm on the run page there's no direct link to help me fix my output configuration. The run list screen on the other hand includes two links to the definition (big button at the top right and the definition name underneath the UUID is also a link).