-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
🐛 Fix unnecessary lastUnpacked status updates #397
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #397 +/- ##
==========================================
+ Coverage 35.29% 35.55% +0.26%
==========================================
Files 17 17
Lines 731 734 +3
==========================================
+ Hits 258 261 +3
Misses 443 443
Partials 30 30 ☔ View full report in Codecov by Sentry. |
0fffaed
to
d6fea36
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm ^^
d6fea36
to
e0d7dab
Compare
doh - didn't realize it was draft - apologies |
Ready for review now |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Previously, we'd be updating the last unpacked time on every reconcile if the unpack directory (given by the catalog name and the image digest) already exists. In this PR we address this by checking if the ResolvedSource.Image is set and taking the last unpack time from that. Otherwise, set last unpacked to now
. LGTM.
My only question is whether we ought to add a test where Status.ResolvedSource or Status.ResolvedSource.Image isn't set.
We should not be updating lastUnpacked status fields when we read from the cache Signed-off-by: Mikalai Radchuk <mradchuk@redhat.com>
e0d7dab
to
9e007c1
Compare
@perdasilva this question made me think that we should probably set We already had several test cases where we do not set this status field, but we had not assertions on PR updated. Please take another look. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm ^^ thank you!
We should not be updating lastUnpacked status fields when we read from the cache
Fixes #389