Show building block logs to workspace users
complete
Jelle den Burger
At the moment the logs for workspace users show basically no information. But in the admin area I can see everything.
I wish workspace users could also simply see the full logs so they could possibly troubleshoot simple issues themselves like strings being too long or invalid regexes, etc.
J
Johannes Rudolph
This is available now in meshStack since yesterday's release
https://docs.meshcloud.io/blog/2025/09/10/Release-0/#introducing-building-block-run-control
We'd be very happy to hear your feedback whether this feature now enables your intended use cases.
This post was marked as
complete
J
Johannes Rudolph
in progress
Hi all and thanks for voting for this feature. We have started implementing this feature and are currently testing it. We plan to make it available in one of the next releases.
Based on feedback we have received we see two related concepts that platform engineers would like to control
- who can see system logs on building block runs
- who can trigger new runs directly (e.g. to recover from a transient error condition)
To keep the feature simple, we have decided to call this feature "Building Block Run Control" and combine both concepts into a single setting on the building block definition.
When enabled by setting to "Platform team and workspace users", workspace users can see all logs and re-run building blocks. This gives app teams more visibility and control over their building block runs, improving troubleshooting and self-service.
All existing building block definitions will have "Building Block Run Control" set to "Platform Team only" so that this new feature is an opt-in per building block.
The concepts of user messages and system messages refer to their equivalent concepts on the meshObject API. https://docs.meshcloud.io/api/index.html#_update_sources_and_steps
It's worth noting that the OpenTofu runner included by meshStack emits systemMessages only by default, but GitHub actions or GitLab CI/CD based runners may send both types of messages.
We'd be very happy to hear from you if that implementation matches your use case and if you have any further questions or ideas for improvement.
Jelle den Burger
planned
F
Fabian
Absolutely crucial. Otherwise the platform team will be the bottleneck if users have failed deployments which they cannot debug.
For a team of 5 people and close to 1000 cloud accounts this is absolutely untenable.
I am wondering why this was not implemented in the first place?
Jelle den Burger
Fabian: Hey Fabian we will implement this soon.
We intended building blocks to be isolated from the app teams initially.
What is the exact intention that you want them to see the logs? Do they fail often? And do they fail because of wrong user input then? Is it feasible that the app teams fix this themselves?
F
Fabian
Jelle den Burger one example is that we have a building block which allows users to create azure custom roles.
this means, they have a textbox in which they can provide actions the role should have, e.g.:
actions = [
"Microsoft. Compute/virtualMachines/read",
"Microsoft. Compute/virtualMachines/start/action",
"Microsoft. Compute/virtualMachines/deallocate/action",
]
one colleague used chatgpt to generate this role, and the actions were heavily hallucinated, resulting in a back and forth between us and the collegaue.
generally, things can go wrong when providing custom building blocks and if users have a little more information other than "failed", everyone would be better off i think.