Megatest

Artifacts Associated With Ticket 64562cb2cd61a9f8cb4c729ca9c3cc672c07881e

1. Ticket change [e94703eae4] (rid 21858) by matt on 2021-02-23 16:49:55:

   1. 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.
      

   2. login: "matt"
   3. mimetype: "text/plain"
   4. severity initialized to: "Important"
   5. status initialized to: "Open"
   6. title initialized to: "On-startup checks for viable setup."
   7. type initialized to: "Feature_Request"