-
Notifications
You must be signed in to change notification settings - Fork 13
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
Produce better logs and collect artifacts on failed setup #41
Conversation
This PR depends on #38, it starts with "misc: add SuccessChecker" commit. |
To reproduce, you can just raise an error in role setup. E.g. (sssd-test-framework) diff --git a/sssd_test_framework/roles/client.py b/sssd_test_framework/roles/client.py
index c3df1c7..e1a95e2 100644
--- a/sssd_test_framework/roles/client.py
+++ b/sssd_test_framework/roles/client.py
@@ -81,6 +81,10 @@ class Client(BaseLinuxRole[ClientHost]):
#. import implicit domains from topology marker
"""
super().setup()
+
+ self.logger.info("Raising error, this will be visible in logs. SSSD artifacts will be collected.")
+ raise Exception("Setup error")
+
self.sssd.stop()
self.sssd.clear(db=True, memcache=True, logs=True, config=True)
|
b6694de
to
2c88224
Compare
@justin-stephenson @danlavu Kind ping for a review. Thanks! |
pytest_mh/_private/misc.py
Outdated
Keep named states of operation. | ||
|
||
This can be used to mark certain operations as completed with success, | ||
failure or any other state state and act later upon it. |
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.
s/state state/state/
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.
Ack besides the one minor typo, works as expected.
Keep success/failure state of certain operations. This can be used to mark certain operations as completed with success or failure state and act later upon the result. add
Previously no artifacts are collected if a setup fails and teardown was logged under setup which was confusing. Now, the code is refactored and simplified, the setup and teardown are strictly separated and all artifacts are collected.
This simplifies the code by moving decision logic out of the inner methods.
This will improve the logs, now teardown really contains only teardown.
Before we did not collect any artifacts and logged teardown to a setup phase if an exception was risen during setup.
Now, setup and teardown are fully separated which makes the code easier and it is also separated in the logs. Additionally, we now collect available artifacts so we can actually learn why the setup phase failed.