How the test launcher runs Jobs

The test InstanceLauncher is responsible for a number of actions when the engine under test calls launch(). The launch() method…

1. Gets the named RunningWorkflowStep using the workflow API
2. Creates a simulated Instance database record and sets its running_workflow_id to the given RunningWorkflowStep UUID. This is done because it is important for the engine, which will expect to find an instance UUID in the corresponding PodMessage that it expects to receive.
3. The step’s Job definition is retrieved via the workflow API using the LaunchParameter’s specification. This gives the instance launcher the Job’s command (which may depend on some provided variables)
4. The variables provided in the LaunchParameter’s specification_variables are applied to the Job’s command. This ensures any variables expected in the command are expanded using the values the engine had provided
5. The decoded command is executed using subprocess.run() using tests/jobs as the execution directory. The launcher does not pay any attention to the command exit code
6. A PodMessage protocol buffer is constructed. The UUID of the instance just created is added and then it is sent to the message queue using the message dispatcher. This message is eventually (almost immediately) sent to the engine’s handle_message() method.

Finally the UUID of the instance record, a dummy (meaningless) task UUID, and the decoded command are returned to the caller.