How the test launcher runs Jobs

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

1. 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 need to find an instance UUID in the corresponding PodMessage that it expects to receive
2. 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)
3. 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
4. The decoded command is executed using subprocess.run() using tests/jobs as the execution directory while ehe launcher collects the subprocess command’s exit code
5. A PodMessage protocol buffer is constructed and populated. Its phase is set to Completed. instance_id is set to the UUID of the instance just created. task_id is set to a dummy Task UUID. has_exit_code is set to True, and the exit_code is set to the exit code of the subprocess that was just run
6. The constructed message is sent to the message queue using the message dispatcher. This message is eventually (almost immediately) passed on to the engine’s handle_message() method

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