plainbox.impl.runner – job runner

Warning

THIS MODULE DOES NOT HAVE STABLE PUBLIC API

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

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_begin(args, kwargs)[source]

Internal method of extcmd.DelegateBase

Called when a command is being invoked

on_end(returncode)[source]

Internal method of extcmd.DelegateBase

Called when a command finishes running

on_line(stream_name, line)[source]

Internal method of extcmd.DelegateBase

Called for each line of output.

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

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_line(stream_name, line)[source]
class plainbox.impl.runner.IOLogRecordGenerator[source]

Delegate for extcmd that generates io_log entries.

on_begin(args, kwargs)[source]

Internal method of extcmd.DelegateBase

Called when a command is being invoked.

Begins tracking time (relative time entries)

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[source]

Internal signal method of IOLogRecordGenerator

Called when a new record is generated and needs to be processed.

class plainbox.impl.runner.JobRunner(session_dir, provider_list, jobs_io_log_dir, command_io_delegate=None, dry_run=False)[source]

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.

run_attachment_job(job, 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, config=None)[source]

Run the specified job an return the result

Parameters:
  • job – A JobDefinition to run
  • 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.
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, 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, 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_resource_job(job, 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, 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, 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, config)[source]

Method called to run a job with plugin field 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, 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.

plainbox.impl.runner.authenticate_warmup()[source]

Call the checkbox trusted launcher in warmup mode.

This will use the corresponding PolicyKit action and start the authentication agent (depending on the installed policy file)

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

Slugify - like Django does for URL - transform a random string to a valid slug that can be later used in filenames

Previous topic

plainbox.impl.result – job result

Next topic

plainbox.impl.secure – code for external (trusted) launchers

This Page