What happened

PR #3053 bumped the x2a workspace to 2.0.0 for RHDH 1.10 / Backstage 1.49.4. The smoke tests failed because the x2a and x2a-mcp-extras backend plugins register a x2a-kubernetes service that attempts to connect to a Kubernetes cluster at startup. The smoke test environment has no cluster, so the plugins crash with BackendStartupError: Failed to connect to namespace smoke-test-namespace: HTTP protocol is not allowed when skipTLSVerify is not set or false.

This is a recurring failure since April 2026 when PR #2252 added appConfigExamples with Kubernetes config to the x2a-backend metadata. The smoke test injects this config (via test.env placeholder values), causing the plugins to attempt a real cluster connection. At least 3 PRs have hit this: #2529, #2535, and #3053. In each case, the reviewer had to manually verify the failure was expected rather than a real regression.

Reviewer gashcrumb suggested adding a smoke-tests/app-config.test.yaml to suppress the errors, following the established pattern from the backstage workspace.

What could go better

The smoke test for the x2a workspace produces a recurring false negative that erodes confidence in the smoke test signal. Reviewers must manually determine whether the failure is expected (Kubernetes connectivity) or indicates a real packaging regression. This wastes reviewer attention on every x2a PR and normalizes ignoring smoke test failures, which could mask real issues.

Confidence: High. The failure cause is well-understood (Kubernetes connectivity in a container-only environment), the pattern is established (3 of 32 workspaces already use app-config.test.yaml overrides), and a maintainer has already identified the fix. The only uncertainty is the exact configuration needed to suppress the Kubernetes connection attempt without masking real plugin startup errors.

Proposed change

Create workspaces/x2a/smoke-tests/app-config.test.yaml with configuration that prevents the x2a-kubernetes service from attempting a real cluster connection during smoke tests. This follows the established pattern from workspaces/backstage/smoke-tests/app-config.test.yaml (SCM integration stubs) and workspaces/mcp-chat/smoke-tests/app-config.test.yaml (provider config stubs).

The override should provide a Kubernetes config block that satisfies the x2a plugin's startup validation without requiring a real cluster — for example, configuring skipTLSVerify: true for the dummy namespace or disabling the Kubernetes service initialization path. The exact config depends on the x2a plugin's Kubernetes client configuration schema.

The test.env file already exists with placeholder values (X2A_KUBERNETES_NAMESPACE=smoke-test-namespace). What is missing is the app-config layer that controls how the plugin interprets those values at startup.

Validation criteria

After the fix: (1) Smoke tests pass for the x2a workspace on the next PR that touches workspaces/x2a/. (2) All 5 x2a plugins (x2a, x2a-dcr, x2a-backend, x2a-mcp-extras, scaffolder-backend-module-x2a) load without BackendStartupError. (3) The /health endpoint returns 200 with all plugins registered. Verify across at least 2 consecutive x2a workspace PRs.

Generated by retro agent from #3053