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 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.
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.