Refactor logic of referenced versions#17
Conversation
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
💤 Files with no reviewable changes (1)
📝 WalkthroughWalkthroughThe Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Merging this branch will increase overall coverage
Coverage by fileChanged files (no unit tests)
Please note that the "Total", "Covered", and "Missed" counts above refer to code statements instead of lines of code. The value in brackets refers to the test coverage of that file in the old version of the code. |
ProviderConfig.machineImages were originally included in the referenced version calculation because it contains the resolved image mappings produced from the OCI source, and we treated it as part of the available version set for a CloudProfile.
After reviewing the reconciliation flow more carefully, it was realized that ProviderConfig is a derived artifact that is fully regenerated on each reconciliation from OCI and does not represent either user intent or actual runtime usage.
Including it in the referenced set causes inflated reference counts (as seen in logs with hundreds of versions) and prevents effective garbage collection of unused image versions.
Therefore, it's needed to adjus the logic so that only actual usage sources as Shoot is considered when determining referenced versions. ProviderConfig is excluded because it is not a lifecycle authority but a transient resolution layer.