Stop using kots to install the app #3257
Conversation
|
This PR has been released (on staging) and is available for download with a embedded-cluster-smoke-test-staging-app license ID. Online Installer: Airgap Installer (may take a few minutes before the airgap bundle is built): Happy debugging! |
sgalsaleh
force-pushed
the
stop-using-kots
branch
2 times, most recently
from
d130bdc to
1b48b5c
Compare
sgalsaleh
force-pushed
the
stop-using-kots
branch
from
1b48b5c to
ca9ab68
Compare
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
| return fmt.Errorf("create metadata client: %w", err) | ||
| } | ||
| m.mcli = mcli | ||
| } |
There was a problem hiding this comment.
Bug: Potential nil pointer dereference in namespace reconciler
In setupClients(), mcli (metadata client) is only created when restClientGetter != nil. If kubernetesEnvSettings is nil, mcli remains nil. Later, when hostCABundlePath is non-empty, ensureCAConfigmap calls adminconsole.EnsureCAConfigmap which uses mcli.Resource(...) without a nil check. This will cause a nil pointer dereference panic. The ensureCAConfigmap function checks hostCABundlePath but not mcli.
Additional Locations (1)
| Archive: []byte("chart-archive-data"), | ||
| Values: map[string]any{"key": "value"}, | ||
| }, | ||
| } |
There was a problem hiding this comment.
Bug: Test creates InstallableHelmChart with nil CR field
The test data creates InstallableHelmChart structs without setting the CR field, leaving it nil. While this test uses mocks and doesn't exercise the real installHelmChart code path, the getChartDisplayName function calls chart.CR.GetName() without nil checking. If a chart with a nil CR were passed to the real install function, it would panic. The production ExtractInstallableHelmCharts always sets CR, but the test data doesn't reflect this contract.
| Values: map[string]kotsv1beta1.ConfigValue{}, | ||
| }, | ||
| configValues: types.AppConfigValues{ | ||
| "key1": {Value: "value1"}, |
There was a problem hiding this comment.
Bug: Test for empty config values uses non-empty values
The test case named "handles empty config values" was incorrectly refactored and now passes non-empty config values ("key1": {Value: "value1"}). The original test used an empty map to verify the code handles empty config values correctly. The comment at line 826 still says "Get and verify secret was created even with empty values", confirming the test intent was to test empty values. This test regression means empty config value handling is no longer tested, potentially masking bugs in that code path.
What this PR does / why we need it:
Which issue(s) this PR fixes:
Does this PR require a test?
Does this PR require a release note?
Does this PR require documentation?