Here it's never ever going to run the command. It wasn't noticed because the gui was using undocumented methods to directly bypass the job runner and run the command manually. This broke when we dropped that code.
For reference, this is how the user-interact plugin is documented to work:
def run_user_interact_job(self, job, config):
"""
Method called to run a job with plugin field equal to 'user-interact'
The 'user-interact' job implements the following scenario:
* Display the description to the user
* Ask the user to perform some operation
* Wait for the user to confirm this is done
* The API states that :meth:`JobRunner.run_job()` should only be
called at this time.
* Run the command and wait for it to finish
* Decide on the outcome based on the return code
* The method ends here
.. note::
User interaction jobs are candidates for further automation as the
outcome can be already determined automatically but some interaction, yet, cannot.
.. note::
User interaction jobs are a hybrid between shell jobs and manual
jobs. They finish automatically, once triggered but still require a
human to understand and follow test instructions and prepare the process. Instructions may range to getting a particular hardware
setup, physical manipulation (pressing a key, closing the lid, plugging in a removable device) or talking to a microphone to get
some sound recorded.
.. note::
The user may want to re-run the test a number of times, perhaps
because there is some infrequent glitch or simply because he or she
was distracted the first time it ran. Users should be given that
option but it must always produce a separate result (simply re-run
the same API again).
"""
if job.plugin != "user-interact":
raise ValueError("bad job plugin value")
return MemoryJobResult({'outcome': IJobResult.OUTCOME_UNDECIDED})
It seems that we've accidentally changed the semantics of the user-interact job type:
- return self._just_ run_command( job, config) ({'outcome' : IJobResult. OUTCOME_ UNDECIDED} )
+ return MemoryJobResult
Here it's never ever going to run the command. It wasn't noticed because the gui was using undocumented methods to directly bypass the job runner and run the command manually. This broke when we dropped that code.
For reference, this is how the user-interact plugin is documented to work:
def run_user_ interact_ job(self, job, config):
"""
Method called to run a job with plugin field equal to 'user-interact'
The 'user-interact' job implements the following scenario:
* Display the description to the user JobRunner. run_job( )` should only be
* Ask the user to perform some operation
* Wait for the user to confirm this is done
* The API states that :meth:`
called at this time.
* Run the command and wait for it to finish
* Decide on the outcome based on the return code
* The method ends here
.. note::
interactio n, yet, cannot.
User interaction jobs are candidates for further automation as the
outcome can be already determined automatically but some
.. note::
process. Instructions may range to getting a particular hardware
plugging in a removable device) or talking to a microphone to get
User interaction jobs are a hybrid between shell jobs and manual
jobs. They finish automatically, once triggered but still require a
human to understand and follow test instructions and prepare the
setup, physical manipulation (pressing a key, closing the lid,
some sound recorded.
.. note:: ({'outcome' : IJobResult. OUTCOME_ UNDECIDED} )
The user may want to re-run the test a number of times, perhaps
because there is some infrequent glitch or simply because he or she
was distracted the first time it ran. Users should be given that
option but it must always produce a separate result (simply re-run
the same API again).
"""
if job.plugin != "user-interact":
raise ValueError("bad job plugin value")
return MemoryJobResult