Definition of JobRunner class.

plainbox.impl.runner – job runner

Warning

THIS MODULE DOES NOT HAVE STABLE PUBLIC API

class plainbox.impl.runner.CommandOutputWriter(stdout_path, stderr_path)[source]

Bases: plainbox.vendor.extcmd.DelegateBase

Delegate for extcmd that writes output to a file on disk.

The file itself is only opened once on_begin() gets called by extcmd. This makes it safe to instantiate this without worrying about dangling resources.

on_abnormal_end(signal_num)[source]

Internal method of extcmd.DelegateBase.

Called when a command abnormally finishes running

on_begin(args, kwargs)[source]

Internal method of extcmd.DelegateBase.

Called when a command is being invoked

on_chunk(stream_name, chunk)

Do nothing

on_end(returncode)[source]

Internal method of extcmd.DelegateBase.

Called when a command finishes running

on_interrupt()

Do nothing

on_line(stream_name, line)[source]

Internal method of extcmd.DelegateBase.

Called for each line of output.

class plainbox.impl.runner.FallbackCommandOutputPrinter(prompt)[source]

Bases: plainbox.vendor.extcmd.DelegateBase

Delegate for extcmd that prints all output to stdout.

This delegate is only used as a fallback when no delegate was explicitly provided to a JobRunner instance.

on_abnormal_end(signal_num)

Do nothing

on_begin(args, kwargs)

Do nothing

on_chunk(stream_name, chunk)

Do nothing

on_end(returncode)

Do nothing

on_interrupt()

Do nothing

on_line(stream_name, line)[source]

Internal method of extcmd.DelegateBase.

Called for each line of output. Normally each line is just printed (assuming UTF-8 encoding) If decoding fails for any reason that and all subsequent lines are ignored.

class plainbox.impl.runner.IOLogRecordGenerator[source]

Bases: plainbox.vendor.extcmd.DelegateBase

Delegate for extcmd that generates io_log entries.

on_abnormal_end(signal_num)

Do nothing

on_begin(args, kwargs)[source]

Internal method of extcmd.DelegateBase.

Called when a command is being invoked.

Begins tracking time (relative time entries)

on_chunk(stream_name, chunk)

Do nothing

on_end(returncode)

Do nothing

on_interrupt()

Do nothing

on_line(stream_name, line)[source]

Internal method of extcmd.DelegateBase.

Creates a new IOLogRecord and passes it to on_new_record(). Maintains a timestamp of the last message so that approximate delay between each piece of output can be recorded as well.

on_new_record

Basic signal that supports arbitrary listeners.

While this class can be used directly it is best used with the helper decorator Signal.define on a function or method. See the documentation for the plainbox.vendor.morris module for details.

Attr _name:Name of the signal, typically accessed via name().
Attr _listeners:
 List of signal listeners. Each item is a tuple (listener, pass_signal) that encodes how to call the listener.
class plainbox.impl.runner.JobRunner(session_dir, provider_list, jobs_io_log_dir, command_io_delegate=None, dry_run=False, execution_ctrl_list=None)[source]

Bases: plainbox.abc.IJobRunner

Runner for jobs - executes jobs and produces results.

The runner is somewhat de-coupled from jobs and session. It still carries all checkbox-specific logic about the various types of plugins.

The runner consumes jobs and configuration objects and produces job result objects. The runner can operate in dry-run mode, when enabled, most jobs are never started. Only jobs listed in DRY_RUN_PLUGINS are executed.

get_record_path_for_job(job)[source]
get_warm_up_sequence(job_list)[source]

Determine if authentication warm-up may be needed.

Parameters:job_lits – A list of jobs that may be executed
Returns:A list of methods to call to complete the warm-up step.

Authentication warm-up is related to the plainbox-secure-launcher-1 program that can be ‘warmed-up’ to perhaps cache the security credentials. This is usually done early in the testing process so that we can prompt for passwords before doing anything that takes an extended amount of time.

log_leftovers

flag controlling if leftover files should be logged.

If you wish to connect a custom handler to on_leftover_files() then it is advisable to set this property to False so that leftover files are not handled twice

By default, this property is True and a detailed warning is logged

on_leftover_files

Basic signal that supports arbitrary listeners.

While this class can be used directly it is best used with the helper decorator Signal.define on a function or method. See the documentation for the plainbox.vendor.morris module for details.

Attr _name:Name of the signal, typically accessed via name().
Attr _listeners:
 List of signal listeners. Each item is a tuple (listener, pass_signal) that encodes how to call the listener.
run_attachment_job(job, job_state, config)[source]

Method called to run a job with plugin field equal to ‘attachment’.

The ‘attachment’ job implements the following scenario:

  • Maybe display the description to the user
  • The API states that 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

Attachment jobs play an important role in CheckBox. They are used to convert stdout of the command into a file that is embedded inside the final representation of a testing session. Attachment jobs are used to gather all kinds of essential information (by catting log files, sysfs or procfs files)

run_job(job, job_state, config=None, ui=None)[source]

Run the specified job an return the result.

Parameters:
  • job – A JobDefinition to run
  • job_state – The JobState associated to the job to execute.
  • config – A PlainBoxConfig that may influence how this job is executed. This is only used for the environment variables (that should be specified in the environment but, for simplicity in certain setups, can be pulled from a special section of the configuration file.
  • ui – A IJobRunnerUI object (optional) which will be used do relay external process interaction events during the execution of this job.
Returns:

A IJobResult subclass that describes the result

Raises:

ValueError – In the future, this method will not run jobs that don’t themselves validate correctly. Right now this is not enforced.

This method is the entry point for running all kinds of jobs. Typically execution blocks while a command, embeded in many jobs, is running in another process. How a job is executed depends mostly on the value of the plainbox.abc.IJobDefinition.plugin field.

The result of a job may in some cases be OUTCOME_UNDECIDED, in which case the application should ask the user what the outcome is (and present sufficient information to make that choice, typically this is the job description and the output of the command)

run_local_job(job, job_state, config)[source]

Method called to run a job with plugin field equal to ‘local’.

The ‘local’ job implements the following scenario:

  • Maybe display the description to the user
  • The API states that 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

Local jobs are similar to resource jobs, in that the output matters more than the return code. Unlike resource jobs and attachment jobs, the output is expected to be a job definition in the canonical RFC822 format. Local jobs are discouraged (due to some complexities they introduce) but only supported way of generating additional jobs at runtime.

run_manual_job(job, job_state, config)[source]

Method called to run a job with plugin field equal to ‘manual’.

The ‘manual’ job implements the following scenario:

  • Display the description to the user
  • Ask the user to perform some operation
  • Ask the user to decide on the outcome

Note

Technically this method almost always returns a result with OUTCOME_UNDECIDED to indicate that it could not determine if the test passed or not. Manual jobs are basically fully human driven and could totally ignore the job runner. This method is provided for completeness.

Warning

Before the interaction callback is fully removed and deprecated it may also return other values through that callback.

run_qml_job(job, job_state, config)[source]

Method called to run a job with plugin field equal to ‘qml’.

The ‘qml’ job implements the following scenario:

  • Maybe display the description to the user
  • Run qmlscene with provided test and wait for it to finish
  • Decide on the outcome based on the result object returned by qml shell
  • The method ends here

Note

QML jobs are fully manual jobs with graphical user interface implemented in QML. They implement proposal described in CEP-5.

run_resource_job(job, job_state, config)[source]

Method called to run a job with plugin field equal to ‘resource’.

The ‘resource’ job implements the following scenario:

  • Maybe display the description to the user
  • The API states that 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

Resource jobs are similar to attachment, in that their goal is to produce some text on standard output. Unlike attachment jobs they are typically not added to the final representation of a testing session. Instead the output is parsed and added to the internal state of a testing session. This state can be queried from special resource programs which are embedded in many job definitions.

run_shell_job(job, job_state, config)[source]

Method called to run a job with plugin field equal to ‘shell’.

The ‘shell’ job implements the following scenario:

  • Maybe display the description to the user
  • The API states that 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

Shell jobs are an example of perfectly automated tests. Everything about them is encapsulated inside the test command and the return code from that command is enough to let plainbox know if the test passed or not.

run_user_interact_job(job, job_state, config)[source]

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

run_user_interact_verify_job(job, job_state, config)[source]

Method for running jobs with plugin equal to ‘user-interact-verify’.

The ‘user-interact-verify’ job implements the following scenario:

  • Ask the user to perform some operation
  • Wait for the user to confirm this is done
  • The API states that JobRunner.run_job() should only be called at this time.
  • Run the command and wait for it to finish
  • Display the description to the user
  • Display the output of the command to the user
  • Ask the user to decide on the outcome

Note

User interact-verify jobs are a hybrid between shell jobs and manual jobs. They are both triggered explicitly by the user and require the user to decide on the outcome. The only function of the command they embed is to give some feedback to the user and perhaps partially automate certain instructions (instead of asking the user to run some command we can run that for them).

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

Note

Technically this method almost always returns a result with OUTCOME_UNDECIDED to indicate that it could not determine if the test passed or not.

Warning

Before the interaction callback is fully removed and deprecated it may also return other values through that callback.

run_user_verify_job(job, job_state, config)[source]

Method called to run a job with plugin field equal to ‘user-verify’.

The ‘user-verify’ job implements the following scenario:

  • Maybe display the description to the user
  • The API states that JobRunner.run_job() should only be called at this time.
  • Run the command and wait for it to finish
  • Display the description to the user
  • Display the output of the command to the user
  • Ask the user to decide on the outcome

Note

User verify jobs are a hybrid between shell jobs and manual jobs. They start automatically but require a human to inspect the output and decide on the outcome. This may include looking if the screen looks okay after a number of resolution changes, if the picture quality is good, if the printed IP address matches some expectations or if the sound played from the speakers was distorted.

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

Note

Technically this method almost always returns a result with OUTCOME_UNDECIDED to indicate that it could not determine if the test passed or not.

Warning

Before the interaction callback is fully removed and deprecated it may also return other values through that callback.

class plainbox.impl.runner.JobRunnerUIDelegate(ui=None)[source]

Bases: plainbox.vendor.extcmd.DelegateBase

Delegate for extcmd that delegates extcmd events to IJobRunnerUI.

The file itself is only opened once on_begin() gets called by extcmd. This makes it safe to instantiate this without worrying about dangling resources.

The instance attribute ‘ui’ can be changed at any time. It can also be set to None to silence all notifications from execution progress of external programs.

on_abnormal_end(signal_num)[source]

Internal method of extcmd.DelegateBase.

Called when a command abnormally finishes running

The negated signal number is used as the exit code of the program and fed into the UI (if any)

on_begin(args, kwargs)[source]

Internal method of extcmd.DelegateBase.

Called when a command is being invoked

on_chunk(stream_name, chunk)[source]

Internal method of extcmd.DelegateBase.

Called for each chunk of output.

on_end(returncode)[source]

Internal method of extcmd.DelegateBase.

Called when a command finishes running

on_interrupt()

Do nothing

on_line(stream_name, line)[source]

Internal method of extcmd.DelegateBase.

Called for each line of output.

plainbox.impl.runner.slugify(_string)[source]

Transform any string to one that can be used in filenames.

comments powered by Disqus