Overview
Artifact ID: | e94703eae433d50c6c99afcd698658b03f3506b8 |
---|---|
Ticket: | 64562cb2cd61a9f8cb4c729ca9c3cc672c07881e
On-startup checks for viable setup. |
User & Date: | matt on 2021-02-23 16:49:55 |
Changes
- icomment:
I would like an enhancement to megatest: A) A setting under megatest.config that allows the definition of a pre-execution script/hook/whatever that will run early on under a minimal megatest environment (i.e. has MT_* vars defined). For example: [checks] before_start = <script & options to call before regression start> before_launch = <script & options to call before test launch> after_launch = <script & options to call after test launch> You get the idea. The script may be the same in all cases, just with options to identify the "phase/context" its being called under, for example: [checks] before_start = checkit.rb --start --pre before_launch = checkit.rb --launch --pre after_launch = checkit.rb --launch --post It doesn't really matter, just so long as the script is designed and allowed to return logpro-style exit codes (0, 2, 3, 4, 5), and print text to stdout that will be captured by megatest for display. The [checks] section should allow for easy extension of other additional check hooks over time if necessary. B) A method in megatest GUI to pop-up a dialog box with the text printed by the script, the error code reported (unless its PASS or WARN), that requires the user to click either "I'll fix it", or "Proceed". C) The results of any check script should appear under logs/ using the same name as the check, for example: logs/before_start.log. Since the checks are done on a per-execution basis, any new execution will overwrite existing logs, so users need to deal with the issue recorded before running again (and overwriting the logs). D) in non-GUI mode when running megatest from the command line, any result other than PASS/WARN should cause megatest to stop execution unless the user decides to rerun with the -proceed option (which is a fallback override in case the check scripts have problems). But even so, if they decide on this options it will be very clear to user and to us that they have done so despite the reported problems.
- login: "matt"
- mimetype: "text/plain"
- severity changed to: "Important"
- status changed to: "Open"
- title changed to: "On-startup checks for viable setup."
- type changed to: "Feature_Request"