Restore timeout-warning trace parity with legacy in concrete mode
What does this MR do?
Brings concrete-mode runner trace output to parity with legacy for timeout and after-script-failure scenarios. Four commits:
Honor AFTER_SCRIPT_IGNORE_ERRORS in concrete mode— the concrete builder forcedAllowFailure: trueon the after-script step, causingfunctions/concrete/run/stages/step.go:41-44to swallow every after-script error before the runner-levelAFTER_SCRIPT_IGNORE_ERRORSgate atfunctions/concrete/run/runner.go:271-273could see it. The user-facing variable was a silent no-op in concrete mode. Removes the redundant override; matches legacycommon/build.go:905-919. Also updatesTestBuildConcreteKitchenSink's expected JSON to drop theallow_failurefield from the after-script step (no longer set, sojson:omitemptyomits it).Emit step_script timeout warning in concrete mode— restores the legacy warning emitted bycommon/build.go:632-639when the script context trips a deadline.Emit after_script timeout warning in concrete mode— restores the matching legacy warning for after-script.Emit job-level timeout warning in concrete dispatch path— concrete dispatches the entire job as one monolithic"concrete"build stage atcommon/build.go:782, bypassing bothexecuteStage's per-stage defer (line 632-639) and the legacy step-dispatch post-call check (line 612-616). Concrete's own per-phase warnings (commits 2 and 3) reach the trace for inner-context timeouts but are lost on a job-level deadline because the build orchestrator force-kills the step-runner container before stderr drains. Emits a phase-agnostic `Job could not run to completion …` from the build orchestrator afterexecuteStepStagereturns, gated onerrors.Is(ctx.Err(), context.DeadlineExceeded)— covers the job-level timeout case that commits 2 and 3 cannot reach.
Why was this MR needed?
The control flow in concrete mode (failure_reason, CI_JOB_STATUS,
exit codes) was already correct on timeout — only the user-visible
trace warnings that legacy emits were missing, and as a side effect
of the redundant AllowFailure: true override on after-script,
`AFTER_SCRIPT_IGNORE_ERRORS=false` was also silently ignored in
concrete mode, diverging from the documented user-facing contract.
What's the best way to test this MR?
- Locally:
go test ./functions/concrete/...andgo test ./common/... - End-to-end (pilot-runners): build a runner image from this branch
and point pilot-runners at it. After commits 1–3 the phase-level
timeout tests (
timeout/script_timeout,timeout/after_script_timeout_but_job_is_successful) pass under `runner-concrete-test`. After commit 4 the two job-level timeout cases (timeout/job_timeout_during_script,timeout/job_timeout_during_after_script_and_job_is_unsuccessful) produce the new phase-agnostic warning in `job.trace`; the matching runner-backbench assertion update for those two is tracked separately.
What are the relevant issue numbers?
N/A
Edited by Romuald Atchadé