Forward job variables to concrete's nested run: dispatch
What does this MR do?
Forward job variables to concrete's nested run: dispatch
A run: job executed via the concrete executor failed at step loading with ": attribute not found" for any ${{ vars.* }} / ${{ job.* }} reference, including step/func references and predefined CI variables.
Concrete dispatches the run: keyword as a nested job over the loopback, but runUserSteps built the RunRequest with Env only. step-runner resolves vars./job. from RunRequest.Variables, a scope distinct from Env, so the nested job saw an empty vars/job scope and every reference failed. The native (docker) path does not hit this because it dispatches run: with the variables populated.
Retain the job variables on the env and forward them as RunRequest.Variables in the nested dispatch. Values are forwarded (file vars are already resolved to paths); masking is still applied by the outer concrete job's log pipeline, through which the nested output flows.
Why was this MR needed?
Job failure for run via concrete.
What's the best way to test this MR?
Test included, but running concrete against a job with run with variables that are used by the step-runners expression language would also test this.