Picking the runner
Right now, there is no mechanism to pick on which runner the workflow should execute. The assumption is that most places where the runner is will contain required tooling and ability to execute the job.
This may change if there is a need for it. There is no reason for implementing complicated logic before the actual problem is completely understood.
A life of a job
Each job is either scheduled by the cron job, by manual trigger (on dispatch), or by an event emitted by the job result. Read more on Workflow Syntax
Job creation
There are 3 main mechanisms uses to create a job:
- Cron
- Expr
- Dispatch
Regardless of the trigger (cron, expr or dispatch), if the job is created for the relevant scan, and the job is in state scheduled, assigned, or running, the job will be skipped and scheduled on the next event. The reason is that sequential execution of tools will most likely provide the same result, so scheduling the same job multiple times only increases storage without added benefits.
The workflow cannot spawn itself. Once done, the scheduler walks through other scans, ignoring the current one. Recursive invocation of scan will only result in scheduler pressure, and is most likely an error on the workflow definition.
Also, recursive invocation of the job can cause you to abuse rate limits on the service you are targeting. If you feel like recursive calls are important, you can always have two scans doing the same thing, spawning each other.
Job resolution
Once the job is created, we are not creating a plan for it. The reason is that until the runner picks it up, we don't know what will be the last successful execution of the dependent scans.
When the runner asks for the job, and there are scheduled jobs, at that moment, the platform resolves dependencies, evaluates template variables and sends that job to the runner.