internal/storage: address unpredictable behavior of image names #7299
Conversation
The current implementation of image names exhibits unpredictable behavior for users, as it relies on the order in which names were pulled, which is not guaranteed by the API. To address this issue, this commit proposes processing all names in image.Names through the filter. Signed-off-by: Sohan Kunkerkar <[email protected]>
|
Skipping CI for Draft Pull Request. |
|
related to #6862 (comment) |
Codecov Report
Additional details and impacted files@@ Coverage Diff @@
## main #7299 +/- ##
==========================================
- Coverage 49.23% 49.23% -0.01%
==========================================
Files 136 136
Lines 15622 15626 +4
==========================================
+ Hits 7692 7693 +1
- Misses 7018 7020 +2
- Partials 912 913 +1 |
|
cc @mtrmac |
mtrmac
left a comment
There was a problem hiding this comment.
LGTM, this looks reasonable (disclaimer: I know a bit about c/storage, quite little about CRI-O).
Thanks!
|
/approve can you add a release-note about this? |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: haircommander, sohankunkerkar The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/retest |
|
@cri-o/cri-o-maintainers PTAL |
|
/lgtm |
The current implementation of image names exhibits unpredictable behavior for users, as it relies on the order in which names were pulled, which is not guaranteed by the API. To address this issue, this commit proposes processing all names in image.Names through the filter.
What type of PR is this?
/kind bug
What this PR does / why we need it:
Which issue(s) this PR fixes:
Special notes for your reviewer:
Does this PR introduce a user-facing change?