refactor(starterkits): use parent_building_block_refs for parent building blocks - #251
Conversation
Scorecard Check
📊 meshstack-hub Module Scorecard
📋 Per-Module Category SummaryScore per category per building block.
Core Structure — ✅ all passingBasic module file structure and documentation — applies to 2 modules
Core Structure — Summary
Integration — some checks failingmeshstack_integration.tf conventions — applies to 2 modules
Integration — Summary
Azure Backplane — not applicableAzure UAMI-based automation principal conventions — applies to 0 modules No applicable modules. STACKIT Backplane — not applicableSTACKIT WIF-based automation principal conventions — applies to 0 modules No applicable modules. Testing — some checks failingEnd-to-end test coverage — applies to 2 modules
Testing — Summary
📈 Overall SummaryOverall Average Score: 87%Score Distribution
|
|
This pull request is automatically being deployed by Amplify Hosting (learn more). |
…ding blocks meshstack Terraform provider v0.24.4 renames spec.parent_building_blocks of meshstack_building_block to spec.parent_building_block_refs and turns every element into a meshObject ref of kind and uuid. meshStack derives the parent definition from the referenced building block, so the definition uuid is not sent any more. The same release adds a computed ref output on meshstack_building_block, so each child points at the parent resource with a single expression. The aks starterkit and the ske starterkit are the only places in the hub that declare a parent relation between building blocks. Both raise the meshstack provider constraint to >= 0.24.4, because the new attribute does not exist before that release. The variables that fed the old definition uuid stay: the aks starterkit keeps var.github_repo_definition_uuid, and the ske starterkit keeps the uuid member of var.building_block_definitions, because meshstack_integration.tf still passes both and removing them would change the module interface. Refs: meshcloud/terraform-provider-meshstack#273 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
a43a833 to
e9e5df3
Compare
…arter kit No resource in modules/ske/ske-starterkit/buildingblock reads the definition uuid any more. Each child building block names its parent through spec.parent_building_block_refs, and meshStack derives the definition of the parent from the referenced building block. Both call sites read only the version ref of a definition. The variable therefore carries only what the module reads. It keeps the map and the keys "git-repository" and "forgejo-connector", but the value of each key is now the version ref alone, and the name says so: building_block_definitions becomes building_block_definition_version_refs. meshStack fills the variable in as a static input of the building block definition, so both sides move together. meshstack_integration.tf renames the input and the variable that the input encodes, and the e2e test passes the version_ref member of the building_block_definition output of each module that owns a definition. A caller of the module modules/ske/ske-starterkit renames the argument and passes module.<name>.building_block_definition.version_ref instead of module.<name>.building_block_definition. The building_block_definition output of the starter kit itself does not change. Refs: meshcloud/terraform-provider-meshstack#273 Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The starter kit took the version uuid of each definition it builds from in a variable of its own, github_repo_definition_version_uuid and github_actions_connector_definition_version_uuid. Both become one map keyed by definition name, building_block_definition_version_refs, with the keys git-repository and github-actions-connector. The ske starter kit already takes its definitions this way, and a new child building block now needs one more map entry instead of one more variable. github_repo_definition_uuid goes away without a replacement. A parent building block ref names the parent with kind and uuid alone, and meshStack derives the definition from the referenced block, so no resource reads that variable any more. meshStack fills the map in as a static building block definition input, so both sides move together: the definition's two STRING inputs become one CODE input, and the parent module takes the `version_ref` member of the `building_block_definition` output of the module that owns each definition. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
e9e5df3 to
2c69bbe
Compare
The description of the map said which member of which output a caller passes, and why the definition uuid is not part of it. The first is a fact about another module, the second explains an absence. Neither tells the reader what the map is, so both go, and the type says the rest. The comment above the variable keeps the one fact the code cannot show: the input in meshstack_integration.tf fills the map in, so the two names have to move together. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The ske starter kit in meshstack-hub changed its module interface, so this unit moves to the ref-based inputs and pins hub commit c9c35a2. - building_block_definitions, a map of objects that each carried a definition uuid and a version ref, becomes building_block_definition_version_refs, a map of version refs alone. - full_platform_identifier and landing_zone_identifiers become platform_ref and landing_zone_refs. The platform unit exports both, taken from the provider's computed ref attributes, and drops the identifier outputs because the starter kit was their only reader. - The starter kit root raises the meshstack provider from ~> 0.22.0 to ~> 0.24.4, and the platform unit from ~> 0.19.3 to the same, because meshstack_landingzone only gained its computed ref in provider v0.24.0. The two units' provider locks are regenerated for darwin_arm64, darwin_amd64 and linux_amd64, so they record meshstack 0.24.4 instead of the 0.19.3 and 0.22.x the old constraints resolved to. A plan against live state shows three building block definitions updated in place and one in-place update on meshstack_platform (spec.access_information, an empty string the provider now sends as null). Nothing is created, replaced or destroyed. c9c35a2 is the head of hub main, from meshcloud/meshstack-hub#251. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
The ske starter kit in meshstack-hub changed its module interface, so this unit moves to the ref-based inputs and pins hub commit c9c35a2. - building_block_definitions, a map of objects that each carried a definition uuid and a version ref, becomes building_block_definition_version_refs, a map of version refs alone. - full_platform_identifier and landing_zone_identifiers become platform_ref and landing_zone_refs. The platform unit exports both, taken from the provider's computed ref attributes, and drops the identifier outputs because the starter kit was their only reader. - The starter kit root raises the meshstack provider from ~> 0.22.0 to ~> 0.24.4, and the platform unit from ~> 0.19.3 to the same, because meshstack_landingzone only gained its computed ref in provider v0.24.0. The two units' provider locks are regenerated for darwin_arm64, darwin_amd64 and linux_amd64, so they record meshstack 0.24.4 instead of the 0.19.3 and 0.22.0 the old constraints resolved to. No other provider changes version. This is applied against live state. The platform unit only rewrites its outputs and touches no infrastructure, and the starter kit updates three building block definitions in place, which raises the starter kit definition to version 11. Nothing is created, replaced or destroyed. c9c35a2 is the head of hub main, from meshcloud/meshstack-hub#251. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
What changes
The two starter kits are the only places in the hub that use a parent relation between building blocks. Provider v0.24.4 (merged to
main, not yet released, meshcloud/terraform-provider-meshstack#273) renamesspec.parent_building_blocksofmeshstack_building_blocktospec.parent_building_block_refs, and each element becomes a{kind, uuid}ref. meshStack derives the parent's definition from the referenced block, so one ref replaces the former pair ofbuildingblock_uuidanddefinition_uuid, and both call sites point at the parent resource's new computedref:No building block is replaced: the resource schema moves to version 1 and the provider migrates existing state by itself, so only the HCL here had to change.
The definition uuid became dead weight once the ref carried the parent, so the two starter kits now take their definitions the same way, each as one map keyed by definition name:
var.building_block_definitionsbecomesvar.building_block_definition_version_refs, and the value shrinks from{uuid, version_ref}to the version ref.github_repo_definition_version_uuidandgithub_actions_connector_definition_version_uuidbecome onevar.building_block_definition_version_refs, andgithub_repo_definition_uuidgoes away without a replacement.meshStack fills those maps in as static building block definition inputs, so each
meshstack_integration.tfmoves with itsbuildingblock/. A caller of either module passes theversion_refmember of thebuilding_block_definitionoutput of the module that owns each definition, as the ske e2e test now does. Neither starter kit's ownbuilding_block_definitionoutput changes.Why this merges before the provider release
The smoke tests build the provider from
origin/main, which already renames the attribute, so the hub staying on the old one is what breaks them.Both
buildingblock/versions.tfstill move from>= 0.24.0to>= 0.24.4, because a consumer who resolves the provider from the registry does need that release. Until v0.24.4 is published, such a consumer cannot runterraform initon these two modules. The release closes that window.Checks
build(pre-commit hooks: terraform-docs, fmt, whitespace, module validation) andscorecardpass; the scorecard is unchanged for both modules.terraform validatecannot run against the registry until v0.24.4 is published, and nothing here works around that.Refs: meshcloud/terraform-provider-meshstack#273