Skip to content

refactor(starterkits): use parent_building_block_refs for parent building blocks - #251

Merged
grubmeshi merged 4 commits into
mainfrom
feature/parent-building-block-refs
Aug 12, 2026
Merged

refactor(starterkits): use parent_building_block_refs for parent building blocks#251
grubmeshi merged 4 commits into
mainfrom
feature/parent-building-block-refs

Conversation

@grubmeshi

@grubmeshi grubmeshi commented Aug 12, 2026

Copy link
Copy Markdown
Collaborator

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) renames spec.parent_building_blocks of meshstack_building_block to spec.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 of buildingblock_uuid and definition_uuid, and both call sites point at the parent resource's new computed ref:

parent_building_block_refs = [meshstack_building_block.repo.ref]

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:

  • ske: var.building_block_definitions becomes var.building_block_definition_version_refs, and the value shrinks from {uuid, version_ref} to the version ref.
  • aks: github_repo_definition_version_uuid and github_actions_connector_definition_version_uuid become one var.building_block_definition_version_refs, and github_repo_definition_uuid goes away without a replacement.

meshStack fills those maps in as static building block definition inputs, so each meshstack_integration.tf moves with its buildingblock/. A caller of either module passes the version_ref member of the building_block_definition output of the module that owns each definition, as the ske e2e test now does. Neither starter kit's own building_block_definition output 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.tf still move from >= 0.24.0 to >= 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 run terraform init on these two modules. The release closes that window.

Checks

build (pre-commit hooks: terraform-docs, fmt, whitespace, module validation) and scorecard pass; the scorecard is unchanged for both modules. terraform validate cannot run against the registry until v0.24.4 is published, and nothing here works around that.

Refs: meshcloud/terraform-provider-meshstack#273

@github-actions

github-actions Bot commented Aug 12, 2026

Copy link
Copy Markdown
Contributor

Scorecard Check

Scorecard run on commit 805aeadf1f40a06b1448bd3ed954f3ad7f97269c relative to origin/main

📊 meshstack-hub Module Scorecard

Generated: 2026-08-12 | Modules scanned: 2 | Categories: 5

📋 Per-Module Category Summary

Score per category per building block. n/a = category does not apply to this module.

Module Overall Core Structure Integration Azure Backplane STACKIT Backplane Testing
aks/starterkit 🟢 82% 🟢 100% 🟢 92% n/a n/a 🔴 0%
ske/ske-starterkit 🟢 91% 🟢 100% 🟢 92% n/a n/a 🟡 67%

⚠️ 2 modules have failing checks — failing categories are expanded below.

Core Structure — ✅ all passing

Basic module file structure and documentation — applies to 2 modules

Module Score 📦 🔗 📋 📝 🖼️ 📌 🔒
aks/starterkit 🟢 100%
ske/ske-starterkit 🟢 100%

Core Structure — Summary

Emoji Criterion Coverage Status
📦 buildingblock/ directory exists 2/2 🟢 100%
🔗 meshstack_integration.tf present 2/2 🟢 100%
📋 buildingblock/APP_TEAM_README.md present (no-integration fallback) n/a
📝 buildingblock/README.md with YAML front-matter 2/2 🟢 100%
🖼️ buildingblock/logo.png included 2/2 🟢 100%
📌 buildingblock/versions.tf present 2/2 🟢 100%
🔒 Provider versions use minimum constraint (>=) 2/2 🟢 100%
Integration — some checks failing

meshstack_integration.tf conventions — applies to 2 modules

Module Score 🏷️ 🏢 📤 🔌 📎 🔀 📋 🏷️ 🧱 📖 📝 📊 🚫 🔄
aks/starterkit 🟢 92%
ske/ske-starterkit 🟢 92%

Integration — Summary

Emoji Criterion Coverage Status
🏷️ variable "hub" in integration 2/2 🟢 100%
🏢 variable "meshstack" in integration 2/2 🟢 100%
📤 building_block_definition output exposed 2/2 🟢 100%
🔌 meshcloud/meshstack in required_providers 2/2 🟢 100%
📎 backplane source uses var.hub.git_ref 2/2 🟢 100%
🔀 ref_name uses var.hub.git_ref 2/2 🟢 100%
📋 version_spec.draft uses var.hub.bbd_draft 2/2 🟢 100%
🏷️ BBD metadata.tags forwards var.meshstack.tags 2/2 🟢 100%
🧱 BBD input argument vars with optional() have explicit defaults 0/2 🔴 0%
📖 BBD readme field present 2/2 🟢 100%
📝 BBD readme starts with plain-text description (no heading) 2/2 🟢 100%
📊 BBD readme has shared responsibility table (✅/❌) 2/2 🟢 100%
🚫 No documentation_md output in backplane 2/2 🟢 100%
🔄 meshstack_platform has lifecycle ignore_changes = [availability] n/a
Azure Backplane — not applicable

Azure UAMI-based automation principal conventions — applies to 0 modules

No applicable modules.

STACKIT Backplane — not applicable

STACKIT WIF-based automation principal conventions — applies to 0 modules

No applicable modules.

Testing — some checks failing

End-to-end test coverage — applies to 2 modules

Module Score ⚙️ 🧪
aks/starterkit 🔴 0%
ske/ske-starterkit 🟡 67%

Testing — Summary

Emoji Criterion Coverage Status
⚙️ backplane/ directory (optional tier) 0/2 🔴 0%
🧪 e2e/ test directory exists 1/2 🟡 50%
e2e/ contains .tftest.hcl files 1/2 🟡 50%

📈 Overall Summary

Overall Average Score: 87%

Score Distribution

  • 🟢 High maturity (≥80%): 2 modules
  • 🟡 Medium maturity (50–79%): 0 modules
  • 🔴 Low maturity (<50%): 0 modules

@aws-amplify-eu-central-1

Copy link
Copy Markdown

This pull request is automatically being deployed by Amplify Hosting (learn more).

Access this pull request here: https://pr-251.d1o16zfeoh2slu.amplifyapp.com

@grubmeshi
grubmeshi marked this pull request as ready for review August 12, 2026 11:48
…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>
@grubmeshi
grubmeshi force-pushed the feature/parent-building-block-refs branch from a43a833 to e9e5df3 Compare August 12, 2026 13:24
grubmeshi and others added 2 commits August 12, 2026 15:33
…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>
@grubmeshi
grubmeshi force-pushed the feature/parent-building-block-refs branch from e9e5df3 to 2c69bbe Compare August 12, 2026 13:33
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>
@grubmeshi
grubmeshi merged commit c9c35a2 into main Aug 12, 2026
3 checks passed
@grubmeshi
grubmeshi deleted the feature/parent-building-block-refs branch August 12, 2026 20:53
grubmeshi added a commit to likvid-bank/likvid-cloudfoundation that referenced this pull request Aug 12, 2026
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>
grubmeshi added a commit to meshcloud/trial-cloudfoundation that referenced this pull request Aug 13, 2026
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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant