You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
An abort wrapper is a dedicated optional wrapper that can be run if its associated execution run is to be aborted.
There are two known scenarios in which an abort wrapper is useful:
when killing an execution run's processes isn't enough to return the system to a neutral state in which the system can be idle or used for the next task run
for duration tests that are either aborted by the task timeout feature of the Control Center or are aborted by the user (for example when the test equipment is needed for other tests)
The abort wrapper currently logs to wrapper_log.txt, the same log as used for the execution run. This is confusing, since it's not easy to see which log entries originate from which wrapper. Now that we have flexible log tabs, it would be better to have a separate log for the abort wrapper. However, implementing this is not trivial, since the abort wrapper's thread skips a lot of the code that other wrapper types use. Among the skipped code is the code that creates log files and uploads artifacts.
It would be useful if, when an abort wrapper is run, to have the abort wrapper produce a results file instead of the execution wrapper. Or at least to have the option of doing that. Implementing this runs into the same issues as separating the log file, being that an abort wrapper skips several steps that are essential to make this work, such as uploading artifacts and making the TaskDone call to the CC.
There are also some questions related to how abort wrappers interact with other wrappers that don't have firm anwsers yet (and tentative answers might not agree with the implementation):
should an abort wrapper be run inside a process wrapper? if future process wrappers start containers or VMs, an abort wrapper that is isolated in that way cannot perform many types of cleanup
if the requirements for aborting duration tests and cleaning up are significantly different, should there be two separate types of wrappers for them? if so, it might be a good idea to run the cleanup wrapper after every execution, whether it was aborted or exited normally
The text was updated successfully, but these errors were encountered:
An abort wrapper is a dedicated optional wrapper that can be run if its associated execution run is to be aborted.
There are two known scenarios in which an abort wrapper is useful:
The abort wrapper currently logs to
wrapper_log.txt
, the same log as used for the execution run. This is confusing, since it's not easy to see which log entries originate from which wrapper. Now that we have flexible log tabs, it would be better to have a separate log for the abort wrapper. However, implementing this is not trivial, since the abort wrapper's thread skips a lot of the code that other wrapper types use. Among the skipped code is the code that creates log files and uploads artifacts.It would be useful if, when an abort wrapper is run, to have the abort wrapper produce a results file instead of the execution wrapper. Or at least to have the option of doing that. Implementing this runs into the same issues as separating the log file, being that an abort wrapper skips several steps that are essential to make this work, such as uploading artifacts and making the
TaskDone
call to the CC.There are also some questions related to how abort wrappers interact with other wrappers that don't have firm anwsers yet (and tentative answers might not agree with the implementation):
The text was updated successfully, but these errors were encountered: