Ansible plugin now saves output and produces prepare/finish result#3738
Conversation
6cf5b15 to
28d7b93
Compare
28d7b93 to
ef718d4
Compare
5b70831 to
99a5f56
Compare
|
Saving the ansible output seems quite useful, could be an interesting change for users, would it possibly deserve a short release note? |
Possibly. It can be argued it would be interesting, on the other hand, tmt is still pretty silent about these logs as they and their paths are not shown, unlike test logs. So my instict is to not bother user with something they would need to dig into a workdir to find it, and wait with the release to the moment |
Understand the point. Would that possibly be just a single |
More complicated, at least in my vision: I would like to reuse the Note how Anyway, what I'd like to see is not a oneliner, although not complex either, the raw patch I have has 160 lines. |
|
@coderabbitai full review |
✅ Actions performedFull review triggered. |
📝 WalkthroughWalkthroughThe changes introduce a new Changes
Sequence Diagram(s)sequenceDiagram
participant Step as Prepare/Finish Step
participant Plugin as Plugin (Prepare/Finish)
participant Guest
participant Logger
Step->>Plugin: go(guest, environment, logger)
Plugin->>Guest: (e.g., run playbook, install, etc.)
alt Success
Plugin-->>Step: PluginOutcome (results, exceptions=[])
else Exception
Plugin-->>Step: PluginOutcome (results, exceptions=[...])
end
Step->>Logger: Log results and exceptions
Step->>Step: Aggregate results and exceptions
alt Exceptions present
Step->>Step: Raise Error with collected exceptions
else
Step->>Step: Save results
end
sequenceDiagram
participant MultiGuestTask
participant Guest
participant Logger
MultiGuestTask->>Guest: run_on_guest(guest, logger)
alt Success
Guest-->>MultiGuestTask: TaskResultT (e.g., PluginOutcome)
else Exception
Guest-->>MultiGuestTask: Exception raised, captured in PluginOutcome
end
MultiGuestTask->>MultiGuestTask: Store result in futures[Future[TaskResultT]]
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
There was a problem hiding this comment.
Actionable comments posted: 1
♻️ Duplicate comments (1)
tmt/steps/finish/__init__.py (1)
230-236: Exception handling logic is correct.The results are properly added on line 230 before handling exceptions and continuing. The past review concern has been adequately addressed.
🧹 Nitpick comments (2)
tmt/steps/provision/__init__.py (1)
1631-1631: Update the docstring to document the return value.The return type annotation was correctly changed from
Nonetotmt.utils.CommandOutput, but the method's docstring should be updated to document what is returned.:param silent: if set, logging of steps taken by this function would be reduced. + :returns: command output from the executed Ansible playbook, including + stdout and stderr. """tmt/steps/prepare/__init__.py (1)
486-486: Address the TODO comment for error message improvementConsider providing a more descriptive error message that includes context about which prepare plugins failed.
Would you like me to suggest a more informative error message or open an issue to track this improvement?
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (12)
tests/finish/ansible/test.sh(1 hunks)tmt/queue.py(2 hunks)tmt/steps/__init__.py(4 hunks)tmt/steps/finish/__init__.py(6 hunks)tmt/steps/finish/shell.py(2 hunks)tmt/steps/prepare/__init__.py(7 hunks)tmt/steps/prepare/ansible.py(4 hunks)tmt/steps/prepare/distgit.py(3 hunks)tmt/steps/prepare/feature/__init__.py(2 hunks)tmt/steps/prepare/install.py(2 hunks)tmt/steps/prepare/shell.py(2 hunks)tmt/steps/provision/__init__.py(2 hunks)
🧰 Additional context used
🧬 Code Graph Analysis (3)
tmt/steps/provision/__init__.py (1)
tmt/utils/__init__.py (2)
CommandOutput(1031-1033)output(2444-2456)
tmt/steps/finish/shell.py (3)
tmt/steps/__init__.py (7)
PluginOutcome(1430-1439)go(1268-1282)go(2003-2008)go(2016-2027)go(2106-2107)go(2176-2187)go(2298-2304)tmt/steps/finish/__init__.py (2)
go(73-82)go(140-279)tmt/steps/prepare/shell.py (1)
go(62-123)
tmt/steps/prepare/__init__.py (5)
tmt/result.py (2)
PhaseResult(297-300)ResultOutcome(24-64)tmt/base.py (1)
steps(2542-2553)tmt/steps/__init__.py (11)
Action(2030-2107)PhaseQueue(2661-2677)PluginOutcome(1430-1439)Plugin(2011-2027)PluginTask(2614-2658)run(2609-2610)name(2606-2607)name(2654-2655)name(2691-2692)name(2719-2720)_save_results(850-861)tmt/utils/__init__.py (8)
fail(2027-2032)run(962-976)run(995-996)run(1150-1410)run(2052-2104)name(1578-1579)name(1582-1588)PrepareError(2560-2563)tmt/log.py (1)
fail(871-878)
🔇 Additional comments (33)
tests/finish/ansible/test.sh (1)
56-60: LGTM! Well-structured test for the new results format.The test enhancement properly validates the new structured results format produced by the finish step. The use of
yqto parse and validate the YAML content structure is appropriate, and the expected output format aligns with thePluginOutcomerefactoring.tmt/steps/finish/shell.py (3)
73-73: LGTM! Type annotation updated correctly.The return type change from
list[PhaseResult]totmt.steps.PluginOutcomealigns with the broader refactoring to standardize plugin return types using thePluginOutcomecontainer class.
78-78: LGTM! Variable naming improved.The variable rename from
resultstooutcomeis consistent with the new return type and improves code readability.
111-111: LGTM! Return statement updated consistently.The return statement correctly returns the
outcomevariable, maintaining consistency with the type annotation and variable naming changes.tmt/steps/prepare/shell.py (3)
68-68: LGTM! Type annotation updated correctly.The return type change from
list[PhaseResult]totmt.steps.PluginOutcomealigns with the broader refactoring to standardize plugin return types using thePluginOutcomecontainer class.
73-73: LGTM! Variable naming improved.The variable rename from
resultstooutcomeis consistent with the new return type and improves code readability.
123-123: LGTM! Return statement updated consistently.The return statement correctly returns the
outcomevariable, maintaining consistency with the type annotation and variable naming changes.tmt/steps/provision/__init__.py (1)
1662-1662: Good change - method now returns the command output.This aligns perfectly with the PR objective of making the Ansible plugin save its output. The returned
CommandOutputobject contains both stdout and stderr from the playbook execution, which enables downstream processing and logging.tmt/steps/prepare/feature/__init__.py (3)
350-350: LGTM! Return type annotation updated to use PluginOutcome.This change aligns with the broader refactoring to standardize plugin return types across the codebase.
355-355: Good practice: Variable renamed to match the new return type.The renaming from
resultstooutcomeimproves code clarity and consistency with the newPluginOutcomereturn type.
359-359: Return statements correctly updated.All return statements have been properly updated to use the renamed
outcomevariable.Also applies to: 384-384
tmt/queue.py (2)
200-200: LGTM! Return type annotation updated to reflect actual return value.The method now correctly indicates it returns a
TaskResultTinstead ofNone, which aligns with the actual behavior where task results are returned.
232-232: Type annotation correctly updated for futures dictionary.The futures dictionary type has been properly updated to reflect that futures hold results of type
TaskResultTinstead ofNone.tmt/steps/prepare/install.py (3)
892-892: LGTM! Return type annotation updated to use PluginOutcome.This change is consistent with the broader refactoring to standardize plugin return types across all prepare plugins.
897-897: Good practice: Variable renamed to match the new return type.The renaming from
resultstooutcomeimproves code clarity and consistency with the newPluginOutcomereturn type.
901-901: Return statements correctly updated.All return statements have been properly updated to use the renamed
outcomevariable, maintaining the existing logic flow.Also applies to: 995-995
tmt/steps/prepare/distgit.py (4)
190-190: LGTM! Return type annotation updated to use PluginOutcome.This change is consistent with the broader refactoring to standardize plugin return types across all prepare plugins.
195-195: Good practice: Variable renamed to match the new return type.The renaming from
resultstooutcomeimproves code clarity and consistency with the newPluginOutcomereturn type.
281-282: Excellent practice: Variable renamed to avoid naming conflict.Renaming the guest command execution result from
outcometooutputprevents confusion with the outeroutcomevariable. This demonstrates good attention to detail in the refactoring effort.
347-347: Return statement correctly updated.The return statement has been properly updated to use the renamed
outcomevariable.tmt/steps/__init__.py (2)
1429-1441: Well-designed plugin outcome container!The
PluginOutcomeclass provides a clean way to bundle results and exceptions from plugin executions. Good use ofsimple_fieldwith default factories to avoid mutable default issues.
2657-2658: Return type correctly updated to support plugin outcomes.The change from returning
Noneto returning the plugin's result aligns perfectly with the newPluginOutcomepattern.tmt/steps/finish/__init__.py (2)
36-36: Return type correctly updated to PluginOutcome.The change aligns with the new unified plugin result handling pattern across all step plugins.
Also applies to: 79-82
189-197: Excellent exception aggregation pattern!The approach of collecting all exceptions and raising a single
GeneralErrorwith all exceptions as causes provides comprehensive error reporting while allowing all plugins to execute.Also applies to: 240-244
tmt/steps/prepare/ansible.py (3)
173-179: Smart approach to preserve playbook log directories!Using numbered directories and dynamically generating the preserved set based on playbook count ensures all logs are retained.
198-306: Excellent refactoring of playbook execution logic!The structured approach with dedicated directories per playbook, comprehensive error handling, and proper result accumulation significantly improves debuggability and error reporting.
268-291: Robust error handling with appropriate logging!The differentiation between
RunError(with output logging) and generic exceptions (without logs) is well thought out. Early returns on errors prevent cascading failures.tmt/steps/prepare/__init__.py (6)
2-2: LGTM!The import additions are necessary for the type annotations used in the refactored code.
17-21: LGTM!The imports are correctly added to support the new
PluginOutcomebased return values and error result creation.
48-48: LGTM!The base class correctly specifies
PluginOutcomeas the return type, aligning with the new plugin result handling architecture.
96-111: LGTM!The method signature and default implementation correctly use the new
PluginOutcomereturn type.
416-416: LGTM!The queue type parameters are correctly updated to handle
PluginOutcomeresults.
433-441: LGTM!The exception collection mechanism and helper function provide a clean way to aggregate and report multiple exceptions from different plugins.
Ok, makes sense, let's handle that separately. |
psss
left a comment
There was a problem hiding this comment.
Looks good to me. Nice improvement! Just one nitpick comment which can safely be ignored.
63ee870 to
47d6853
Compare
|
Unrelated error, merging. |
Pull Request Checklist