-
Notifications
You must be signed in to change notification settings - Fork 87
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
[RHELC-126] Stop if the booted kernel is not owned by any package #424
Conversation
e9bd43b
to
0f251ac
Compare
This now looks good to me (but I have been helping Andrew to write it so another pair of eyes is welcome). |
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.
Looking good, one minor comment about the code.
Codecov Report
@@ Coverage Diff @@
## main #424 +/- ##
==========================================
+ Coverage 87.51% 87.53% +0.02%
==========================================
Files 17 17
Lines 2419 2423 +4
Branches 418 419 +1
==========================================
+ Hits 2117 2121 +4
Misses 241 241
Partials 61 61
Continue to review full report at Codecov.
|
8878709
to
d0283bd
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.
Pretty good work, @Andrew-ang9! I just left some minor comments for you that might improve the readability of the code in general!
4b5b0f9
to
1775331
Compare
@SpyTec, @bocekm I suppose we will not need an integration test for this, right? |
@danmyway, there is an added functionality which will catch the situation where the booted kernel (vmlinuz) is not owned by any installed package. I'd say it's quite an unlikely situation to happen though. From what I know even if you build a custom kernel you build an rpm package which you then install. So even then the kernel is owned by some package. What you'd need to do to simulate the situation is backing up all the kernel package files, removing the kernel package, and then restoring the files from a backup. Or tweak the rpm database. All in all, I don't think it's worth covering this piece of code by an integration test. @abadger, let us know if you think otherwise. |
I agree with @bocekm. The additonal case is likely to be encountered extremely infrequently. |
Alright, thank you, @bocekm and @abadger ! |
3a71e86
1775331
to
3a71e86
Compare
…ing called with the right arguments * This check is to fix that if the rpm qurery format is wrong it will catch it * This fix is not the best because if the formating is wrong in the unit test and the code then the test might pass but still not be vaild for rpm
3a71e86
to
c6c3040
Compare
/packit retest-failed |
1 similar comment
/packit retest-failed |
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.
PR has been previously approved by @abadger, @bocekm and @SpyTec
No issues or test fails after rebasing to upstream
Great job, @Andrew-ang9 !
adds a unit test to catch where the tag "{{NAME}}" has an extra set of curly brace.
This error was fixed in the PR #389
if you'd like to test this use the commit hash 31a304c to use the istant with the error
and use commit hash 9a1c5f5 for the fix for this error
Jira ticket: https://issues.redhat.com/browse/RHELC-126