You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
fix: compute manual building block outputs from the API
Manual building block definitions have their outputs derived from the
inputs on the backend (one output per input, assignment type NONE, with
SINGLE_SELECT/MULTI_SELECT/LIST translated). Configuring outputs that
mirror the inputs caused "Provider produced inconsistent result after
apply" whenever the backend added or changed an output the config did not
predict, especially when toggling draft false->true together with input
changes (#131, #176).
version_spec.outputs is now Optional+Computed without a static default:
omit it for manual building blocks and it is reconciled from the API. The
plan leaves outputs (and the content hash) unknown when the inputs or the
configured PLATFORM_TENANT_ID outputs change, and reuses the reconciled
state value otherwise. ValidateConfig rejects manual outputs with any
assignment_type other than PLATFORM_TENANT_ID, which the backend still
honors to mark the tenant-id output. The mock client mirrors the backend's
manual output generation so unit tests cover the behavior.
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Copy file name to clipboardExpand all lines: CHANGELOG.md
+4Lines changed: 4 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -1,6 +1,10 @@
1
1
# v0.21.1
2
2
3
+
BREAKING CHANGES:
4
+
-`meshstack_building_block_definition`: For manual building blocks, `version_spec.outputs` is now computed from the API and must be omitted from configuration — the backend derives one output per input. Configuring an output with any `assignment_type` other than `PLATFORM_TENANT_ID` is now rejected. Remove `outputs` blocks from manual building block definitions; you may still declare an output with `assignment_type = "PLATFORM_TENANT_ID"` to mark which output carries the tenant id.
5
+
3
6
FIXES:
7
+
-`meshstack_building_block_definition`: Fixed "Provider produced inconsistent result after apply" for manual building blocks whose outputs the backend auto-generates from inputs (e.g. `SINGLE_SELECT`/`STATIC` inputs), including when toggling `version_spec.draft` from `false` to `true` together with input changes ([#131](https://github.com/meshcloud/terraform-provider-meshstack/issues/131), [#176](https://github.com/meshcloud/terraform-provider-meshstack/issues/176)). Outputs are now reconciled from the API response.
4
8
- When no `runner_ref` is provided, the new shared building block runner UUID `98520496-627d-43e6-82da-ce499179ff3f` is used which is suitable for all implementation types.
5
9
Existing `building_block_definition` resources will see a plan change addressing this migration to a single shared runner.
6
10
Using the old shared runner UUIDs is deprecated but handled gracefully by the API.
# Output keys must match with inputs, as the backend copies over inputs to outputs
219
-
outputs = {
220
-
approval_required = {
221
-
display_name = "Approval Required"
222
-
type = "BOOLEAN"
223
-
assignment_type = "NONE"
224
-
}
225
-
}
218
+
# Outputs are omitted for manual building blocks: the backend derives them from the inputs
219
+
# (one output per input), so version_spec.outputs is computed and must not be set here.
226
220
}
227
221
}
228
222
```
@@ -395,7 +389,7 @@ Optional:
395
389
-`dependency_refs` (Attributes Set) Set of refs to building block definitions this definition depends on. Prefer reusable refs from `meshstack_building_block_definition.<name>.ref` or `one(data.meshstack_building_block_definitions.<name>.building_block_definitions).ref`. (see [below for nested schema](#nestedatt--version_spec--dependency_refs))
396
390
-`inputs` (Attributes Map) Map of input definitions for the building block. Keys are input names, values are input configuration objects. Inputs define parameters that building blocks can receive. (see [below for nested schema](#nestedatt--version_spec--inputs))
397
391
-`only_apply_once_per_tenant` (Boolean) Whether this building block can only be applied once per tenant.
398
-
-`outputs` (Attributes Map) Map of output definitions for the building block. Keys are output names, values are output configuration objects. Outputs define values that building blocks produce and can be consumed by other building blocks. (see [below for nested schema](#nestedatt--version_spec--outputs))
392
+
-`outputs` (Attributes Map) Map of output definitions for the building block. Keys are output names, values are output configuration objects. Outputs define values that building blocks produce and can be consumed by other building blocks. If implementation type is `manual`, outputs are computed from the API response, so omit this attribute entirely unless you want to specify a static `assignment_type = "PLATFORM_TENANT_ID"` as part of a landing zone. (see [below for nested schema](#nestedatt--version_spec--outputs))
399
393
-`permissions` (Set of String) Set of API permissions required by this building block. Will provide building block runs with an ephemeral API token with the specified workspace permissions. See [Workspace Permissions](https://docs.meshcloud.io/api/authentication/api-permissions/) for available values and [documentation on ephemeral API keys](https://docs.dev.meshcloud.io/concepts/building-block/#ephemeral-api-keys).
400
394
-`runner_ref` (Attributes) Reference to the runner to run the implementation. If omitted, the pre-defined shared runner is used suitable for the given `implementation` choice (see [below for nested schema](#nestedatt--version_spec--runner_ref))
0 commit comments