For now, this mainly handles normal exits, timeouts, and cancellations. Adding additional stop_condition checkers would extend this further.
I suspect we might also want to extend this in the future to gather more details about the error (if any) coming out of device connectors if they exited with some sort of error. Since those errors could come from commands or external factors, we won't know what all the possibilities are. This will require some mechanism to save that information during the device connector execution so that it can be picked up by the agent and will need to be covered later if needed.
For now, this is not used yet, but will be used by some upcoming PRs - one for exposing this data in testflinger UI and another for sending this information to test_observer.
Description
For now, this mainly handles normal exits, timeouts, and cancellations. Adding additional stop_condition checkers would extend this further.
I suspect we might also want to extend this in the future to gather more details about the error (if any) coming out of device connectors if they exited with some sort of error. Since those errors could come from commands or external factors, we won't know what all the possibilities are. This will require some mechanism to save that information during the device connector execution so that it can be picked up by the agent and will need to be covered later if needed.
For now, this is not used yet, but will be used by some upcoming PRs - one for exposing this data in testflinger UI and another for sending this information to test_observer.
Resolved issues
CERTTF-325
Documentation
N/A
Web service API changes
None
Tests
Unit tests extended to cover this
Testing
...see above