test(ske/ske-starterkit): make the e2e module dual-mode - #304
Draft
JohannesRudolph wants to merge 1 commit into
Draft
test(ske/ske-starterkit): make the e2e module dual-mode#304JohannesRudolph wants to merge 1 commit into
JohannesRudolph wants to merge 1 commit into
Conversation
The starter kit e2e module could only build its own BBD from hub source. That covers a fresh hub deployment, but says nothing about the starter kit a foundation actually ships to its users. Add foundation mode the same way every other dual-mode e2e module has it: the optional `test_context.bbd_version_ref` selects it, and everything the build-from-source backplane stands up — the ephemeral meshPlatform, the git-repository and forgejo-connector definitions, the starter kit BBD itself — is gated behind `count`. The foundation already deployed all of that, so it supplies neither those fixtures nor the backplane secrets. What remains is the part worth running against a live foundation: order a starter kit building block, wait for it, and probe both app endpoints for HTTP 200 over verified TLS. The kubernetes provider moves from `provider.tf` into `main.tf`, matching stackit/storage-bucket. A foundation e2e unit generates its meshstack provider into `provider.tf`, which would silently overwrite a file of that name shipped by the module. Its arguments become null-tolerant because foundation mode has no kubeconfig — and needs none, since nothing is created on the cluster. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Contributor
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 1 modules
Core Structure — Summary
Integration — some checks failingmeshstack_integration.tf conventions — applies to 1 modules
Integration — Summary
AWS Backplane — not applicableAWS automation principal conventions (WIF or cross-account StackSet) — applies to 0 modules No applicable modules. Azure Backplane — not applicableAzure UAMI-based automation principal conventions — applies to 0 modules No applicable modules. GCP Backplane — not applicableGCP workload-identity-federation 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 1 modules
Testing — Summary
|
|
This pull request is automatically being deployed by Amplify Hosting (learn more). |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Prerequisite for running the SKE StarterKit smoke test against deployed cloud foundations
(likvid-bank/likvid-cloudfoundation and meshcloud/trial-cloudfoundation).
Why
modules/ske/ske-starterkit/e2eonly had build-from-source mode: it stands up an ephemeralmeshPlatform, a
stackit/git-repositoryand aske/forgejo-connectordefinition, builds thestarter kit BBD from hub source, and orders a building block against it. That verifies a fresh hub
deployment. It says nothing about the starter kit a foundation actually ships to its users.
Every other dual-mode e2e module already has the second mode. This adds it here so the foundations
can run the same test against their deployed BBD.
What
test_context.bbd_version_ref(optional) is the mode discriminator, per thee2e-testskill.count: the ephemeral platform,the two child definitions, and the starter kit module itself.
forgejo_base_url,forgejo_organizationanddns_zone_namebecomeoptional(); the five backplane secrets getdefault = null.kit building block, wait for it, and probe the dev + prod app endpoints for HTTP 200 over
verified TLS.
depends_onon the building block now lists all four source-built modules, so the delete runalways finishes before any backplane resource is torn down.
provider.tfintomain.tf(matchingstackit/storage-bucket).A foundation e2e unit generates its meshstack provider into
provider.tf, which would silentlyoverwrite a file of that name shipped by the module. Its arguments are null-tolerant because
foundation mode has no kubeconfig — and needs none, since nothing is created on the cluster.
Verification
tofu planin both modes evaluates the full graph and stops only at the dummy provider credentials:bbd_version_refset, no secrets) — the kubernetes provider configures cleanlywith all-null arguments, confirming it is never needed there.
The live run is the nightly
ske/ske-starterkitcase inmeshcloud/meshstack-smoke-test, whichstill exercises build-from-source mode.
🤖 Generated with Claude Code
Consumers of this change (both draft):
Both currently pin this PR's branch head and need re-pinning to the squashed main commit before merge.