Refactor: Align CUE compatibility caching with pkg/cache
- Dominant language
- Go
- Stars
- 126
- Forks
- 66
- Avg merge
- 1h 40m
- Merged PRs (30d)
- 1
Description
**Is your feature request related to a problem? Please describe.**
CUE compatibility caching already lives under `github.com/kubevela/pkg/cue/upgrade` and is consumed by this repo through the pkg dependency. As `github.com/kubevela/pkg/cache` becomes the shared cache surface, CUE compat caching should align with that package (in pkg) and workflow should pick up the dependency bump so there is one cache story across repos.
**Describe the solution you'd like**
Scope for this workflow issue:
1. Coordinate / land the pkg-side alignment of `cue/upgrade` caching with `pkg/cache` (kubevela/pkg), if not already done there.
2. Bump `github.com/kubevela/pkg` in this repo and fix any call-site fallout.
3. Do **not** add a parallel CUE-compat cache implementation inside workflow.
Keep CUE upgrade behavior equivalent; this is an alignment / dependency update, not a new feature.
**Describe alternatives you've considered**
- Reimplement CUE compat caching inside workflow on `pkg/cache`. Rejected: ownership belongs in pkg; duplication would drift.
- Leave `cue/upgrade`'s private cache forever. Rejected long-term if the project standardizes on `pkg/cache`.
**Additional context**
- Primary code ownership: `kubevela/pkg/cue/upgrade`.
- Related: #239 / #240, #247 / #249, kubevela/pkg#130 / #136 / #138.
- Sibling migrations in this repo: email `sync.Map`, optional in-memory context storage, workflow memory context store.
- Good first issue for the workflow half once the pkg change exists: mostly a module bump and smoke/tests. Prefer pairing with a pkg issue if the pkg-side work is still open.
Contributor guide
No contributing guide indexed for this repository
Research direction
Start by checking the kubevela/pkg/cue/upgrade alignment and the related kubevela/pkg issues, then inspect this repository's github.com/kubevela/pkg dependency and CUE upgrade call sites. The work is done when the dependency is bumped, any fallout is fixed, smoke/tests pass, and CUE upgrade behavior remains equivalent without adding a parallel cache in workflow.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- backend
- Issue type
- Refactor
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Active
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100