The changes in ksctl/ksctl#568 (feat: Modularisation the core package for multiple clients) will require several updates in the ksctl/cli repository to ensure compatibility and leverage the new caching mechanism.
Refer:
Here's a summary of the expected changes:
1. Dependency Management
- Update
go.mod in ksctl/cli to the new version/commit of ksctl/ksctl that includes these changes.
- Run
go mod tidy to sync dependencies.
2. Cache Integration
- Import New Package: Add
github.com/ksctl/ksctl/v2/pkg/cache to imports.
- Initialize Cache:
- Create an instance of
cache.InMemCache (or use the cache.Cache interface) in the CLI's main initialization sequence.
- Example:
import (
"context"
"github.com/ksctl/ksctl/v2/pkg/cache"
)
// ...
cliCache := cache.NewInMemCache(context.Background())
// Ensure cliCache.Close() is called appropriately (e.g., defer in main)
- Pass Cache Instance: Propagate the
cliCache instance to any ksctl/ksctl components or functions that now require it (e.g., pollers, controllers, handlers).
3. API and Function Call Updates
- Review and update calls from
ksctl/cli to ksctl/ksctl functions that have modified signatures.
- Key areas:
- Poller Initialization: Functions like
poller.InitSharedGithubReleaseFakePoller now require a cache.Cache argument.
- Example - Old:
poller.InitSharedGithubReleaseFakePoller(myPollerFunc)
- Example - New:
poller.InitSharedGithubReleaseFakePoller(cliCache, myPollerFunc)
- Handlers/Controllers: Components like
AddonController (from pkg/handler/addons/addons.go) might now expect cache instances or configurations including cache (e.g., via KsctlWorkerConfiguration).
4. Configuration (If Applicable)
- Check if
ksctl/cli uses configuration objects (e.g., KsctlWorkerConfiguration) from ksctl/ksctl that have been updated to include cache settings. Ensure these are correctly populated.
5. Testing
- Update tests in
ksctl/cli to provide mock or real cache instances if the components under test now depend on the caching mechanism. Follow the pattern seen in ksctl/ksctl PR #568's test updates.
This list should serve as a good starting point for the necessary refactoring in ksctl/cli. It's recommended to create a dedicated issue or PR in the ksctl/cli repository to track these changes.
The changes in ksctl/ksctl#568 (feat: Modularisation the core package for multiple clients) will require several updates in the
ksctl/clirepository to ensure compatibility and leverage the new caching mechanism.Refer:
Here's a summary of the expected changes:
1. Dependency Management
go.modinksctl/clito the new version/commit ofksctl/ksctlthat includes these changes.go mod tidyto sync dependencies.2. Cache Integration
github.com/ksctl/ksctl/v2/pkg/cacheto imports.cache.InMemCache(or use thecache.Cacheinterface) in the CLI's main initialization sequence.cliCacheinstance to anyksctl/ksctlcomponents or functions that now require it (e.g., pollers, controllers, handlers).3. API and Function Call Updates
ksctl/clitoksctl/ksctlfunctions that have modified signatures.poller.InitSharedGithubReleaseFakePollernow require acache.Cacheargument.poller.InitSharedGithubReleaseFakePoller(myPollerFunc)poller.InitSharedGithubReleaseFakePoller(cliCache, myPollerFunc)AddonController(frompkg/handler/addons/addons.go) might now expect cache instances or configurations including cache (e.g., viaKsctlWorkerConfiguration).4. Configuration (If Applicable)
ksctl/cliuses configuration objects (e.g.,KsctlWorkerConfiguration) fromksctl/ksctlthat have been updated to include cache settings. Ensure these are correctly populated.5. Testing
ksctl/clito provide mock or real cache instances if the components under test now depend on the caching mechanism. Follow the pattern seen inksctl/ksctlPR #568's test updates.This list should serve as a good starting point for the necessary refactoring in
ksctl/cli. It's recommended to create a dedicated issue or PR in theksctl/clirepository to track these changes.