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
qemu: Automatically create swtpm device #1834
Conversation
9bd83cd
to
813154f
Compare
813154f
to
0f98be1
Compare
Codecov Report
@@ Coverage Diff @@
## master #1834 +/- ##
==========================================
+ Coverage 67.36% 67.47% +0.10%
==========================================
Files 62 62
Lines 6877 6887 +10
==========================================
+ Hits 4633 4647 +14
+ Misses 2244 2240 -4
Continue to review full report at Codecov.
|
0f98be1
to
54d92ec
Compare
FYI expecting one test failure for the "default" case. I'm guessing I'm missing something obvious but I can't make much sense of the output and I don't see the issue in my code. |
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.
I suppose it would work but have you conducted a complete test run?
Seems like that was artifacts from debug code I'd forgotten to revert. However I did forget to commit the
FYI the test here runs qemu and swtpm, although it doesn't examine the device further. I was going to run the test from poo#101015 but that deleted, and I couldn't find existing tests relying on swtpm. Trying to get that from Richard. |
54d92ec
to
dc3864b
Compare
https://build.opensuse.org/package/show/devel:openQA:TestGithub:OPR-1834/os-autoinst shows that swtpm can not be resolved so this won't work. Do we actually need swtpm for testing? I would prefer if we don't need it at all. If you are just checking the log for what would be called I guess we should be ok :) |
I think it's rather good to know that it works. And we run a real qemu already If the benefit is not obvious enough, remember what checking for hypothetical commands got us for image compression |
This pull request is now in conflicts. Could you fix it? 🙏 |
dc3864b
to
d5b4b9d
Compare
I was confused why |
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.
Please rephrase the git commit message subject line to answer the "Why", not the "What". Consider reading the changelog on openqa.opensuse.org/changelog which only shows the git commit message subject line. Think about what you would want to read as a user.
Also, what changes did you apply regarding #1834 (comment) ?
It might be better to do d5b4b9d in a separate PR as changing the commands on the command line might introduce backward incompatible changes. You might fix a warning on Tumbleweed but introduce problems for older Leap or SLE for example.
d5b4b9d
to
15851c2
Compare
I made the dependency Tumbleweed-specific similar to what we do with e.g. opencv. We don't run the test on OBS either way. |
af02059
to
f42df28
Compare
Unfortunately it fails like so in the
@rfan1 Can you confirm if this is the right reproducer? |
No problem, let me revise my code and see. |
@kalikiana you can start a new job with the below one and add needed "swtpm" configuration: :)
|
That seems to work, see https://progress.opensuse.org/issues/101015#note-15 |
- Create device if QEMUTPM is set - Recommend swtpm packages See: https://progress.opensuse.org/issues/101015
f42df28
to
7ae93f9
Compare
The test is not fully covered because of the |
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.
so I wonder why [this code] wasn't covered before thinking
Because automated tests did not exist before 2021 maybe ;P
It is just that it looks like this branch is actually covered. Maybe the coverage (of the forked process) isn't collected. |
@kalikiana why did you merge now? I am ok if you merge and state why you want to overrule checks. IMHO would have been a good opportunity to increase test coverage beyond the patch coverage check limit |
See: https://progress.opensuse.org/issues/101015