The above methods are invoked at various state of a job execution in
Galaxy. These methods will act as a mediator between the Galaxy
framework and the external executor framework. To know, when and how
these methods are invoked, we will see about the implementation of
parent class and process lifecycle of the runner.

The input params are read from job_conf.xml and passed to the runner by
the Galaxy framework. Configuration of where to run jobs and external
runner configuration is performed in the job_conf.xml file. More
information about job_conf.xml is available
here.

galaxy.jobs.JobWrapper is a Wrapper around ‘model.Job’ with convenience
methods for running processes and state management.

Functioning of queue_job method.

A. prepare_job() method is invoked to do some sanity checks that all runners’ queue_job() methods are
likely to want to do and also to build runner command line for that
job. Initial state and configuration of the job are set and every
data is associated with job_wrapper.

B. Submit job to the external runner and return the jobid. Accessing
jobs data (tool submitted in Galaxy webframework) is purely from
job_wrapper. eg: job_wrapper.get_state() -> gives state of a job
(queued/running/failed/success/…)

Let us look at a means of accessing external runner’s configuration
present under destination tag of job_conf.xml in the above example.

A special case: User Story: A docker based external runner is present. A
default docker image for execution is set in job_conf.xml. A tool can
also specify the docker image for its execution. Specification in tool
is given more priority than the default specification. To achieve such a
functionality. We can use the following statement:

docker_image=self._find_container(job_wrapper).container_id

Note: This pre-written method is only for getting the external
image/container/os..

C. After successful submission of job in the external runner, submit the
job to Galaxy framework. To do that,make an object of
AsynchronousJobState and put it in monitor_queue.

Without going into much detail, assume there is a queue to track the status of every job. eg:

The galaxy framework updates the status of a job by iterating through the
queue. During the iteration, it calls check_watched_item method with the job.
Your responsibility will be to get the status of execution of the job from the
external runner and return the updated status of the job, and also to
copy the output files for the completed jobs.

Updated result after an iteration (after invocation of check_watched_item 6 times):

Note: Iterating through the queue is already taken care by the framework.

To inform galaxy about the status of the job:

Get the job status from external runner using the job_id.

Check if the job is queued/running/completed.. etc. A general structure is provided below.

Call self.mark_as_finished(job_state), if the job has been successfully executed.

Call self.mark_as_failed(job_state), if the job has failed during execution.

To change state of a job, change job_state.running and job_state.job_wrapper.change_state()