fix(ske/ske-starterkit): provision dummy stackit-ai secret and use a valid DNS zone in e2e#217
Merged
Merged
Conversation
…lid DNS zone in e2e
The ske-starterkit smoke test failed because the app deploy never became ready
and `helm --wait --atomic` rolled back:
- The app chart mounts a `stackit-ai` secret via envFrom (required), but the e2e
never provisioned it, so pods stayed in CreateContainerConfigError
("secret \"stackit-ai\" not found"). Inject a dummy secret via the
forgejo-connector's additional_kubernetes_secrets — smoke tests don't exercise
real inference, they just need the secret to exist. (Static foundations like
trial inject a real STACKIT model-serving token via their own ai.tf.)
- dns_zone_name was the zone's resource name ("meshcloud-dev-ske-starterkit"),
not a valid FQDN, so cert-manager rejected the ingress hostname. Take it from
test_context.dns_zone_name (meshcloud-dev.stackit.run) instead of hardcoding a
dev-specific domain here.
Co-Authored-By: Claude Opus 4.8 (1M context) <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 — ✅ all passingmeshstack_integration.tf conventions — applies to 1 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 1 modules
Testing — Summary
|
|
This pull request is automatically being deployed by Amplify Hosting (learn more). |
grubmeshi
force-pushed
the
fix/ske-starterkit-smoke-e2e
branch
from
e161b4e to
db48927
Compare
…ver TLS Reaching SUCCEEDED only proves the app was deployed, not that its ingress serves traffic with a valid cert-manager-issued certificate. Add a data.external probe (probe_app_endpoints.py) that GETs both app_link_dev and app_link_prod over TLS verified against the system trust store, retrying while cert-manager issues the cert, and assert both return 200. Validated live against meshcloud-dev: dev + prod both 200 over verified TLS. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
grubmeshi
force-pushed
the
fix/ske-starterkit-smoke-e2e
branch
from
db48927 to
5caf7fd
Compare
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.
Problem
The
ske/ske-starterkite2e test failed on every smoke-test run. The starterkit app'sdeployjob could not start its pods:
The app chart mounts a
stackit-aisecret viaenvFrom, but the e2e test never provisioned it,so
helm upgrade --install --wait --atomicrolled the release back. Secondarily,dns_zone_namewas a bare resource name rather than a valid FQDN, so cert-manager rejected the ingress hostname.
Changes
stackit-aisecret via the forgejo-connector'sadditional_kubernetes_secrets(smoke tests don't exercise real inference), and takedns_zone_namefromtest_context.dns_zone_name(the realmeshcloud-dev.stackit.runzone).data.externalPython script GETsboth
app_link_dev/app_link_prodover TLS verified against the system trust store (retryingwhile cert-manager issues the cert) and the test asserts both return 200. Reaching SUCCEEDED
alone doesn't prove the ingress serves traffic with a valid certificate; this does.
Validation
Applied locally against
meshcloud-devend-to-end (viatask e2e:apply): composite BB reachedSUCCEEDED, app pods Running (dev 1/1, prod 2/2), and the probe returned 200 over verified TLSfor both endpoints (
…-dev.meshcloud-dev.stackit.runand….meshcloud-dev.stackit.run). Alsoexercised in the full smoke-test CI matrix.
Cross-repo PRs
dns_zone_nameviatest_context, unifies e2e discovery, addstask e2e:apply/destroysmoke-test-analysisdebugging skill