mirror of
https://gitea.com/gitea/runner.git
synced 2026-11-04 22:37:55 +00:00
silverwind
dcba546cb3
The intermittent Windows test crashes came from step errors formatting a nil `rc.Run`. `fmt` recovers the nil dereference, but on CPUs with AMX the recovered fault overflows into the heap (https://github.com/golang/go/issues/81238). The errors now name the job, and the Windows test VM hides AMX and runs on UTC, so cached boots no longer jump back 8 hours mid-test. Windows commands now start suspended and resume once they are in their job objects, so no child escapes them. That drops the process scan reading other processes' memory and the last `unsafe` code, which `depguard` now denies. Step processes outlive a crashed runner, and commands are no longer looked up in the runner's working directory, both as with GitHub's runner. Like GitHub's runner, host jobs on Linux and macOS now end the processes carrying the job's `RUNNER_TRACKING_ID`, and image pulls and Dockerfile action builds are retried. Reviewed-on: https://gitea.com/gitea/runner/pulls/1376 Reviewed-by: bircni <[email protected]> Co-authored-by: silverwind <[email protected]>
1.1 KiB
1.1 KiB
Host-mode background processes
Host jobs clean up background step processes at job completion. A step can opt out:
steps:
- name: Start shared helper
env:
RUNNER_TRACKING_ID: ""
run: Start-Process vendor-helper.exe
- Set the
RUNNER_TRACKING_IDoverride in the step'senvbefore it starts. Any value different from the job's ID opts out, including an empty string. On Linux and macOS a script can also set it before starting a process. - Opted-out processes and descendants that inherit the override survive normal job cleanup and expired output waits. Detach helper output because the runner closes leftover output pipes after a bounded wait.
- Cancelling or timing out an active step still terminates its process tree.
- The override does not preserve workspace or temporary files. Store persistent helper files outside those directories and arrange the helper's eventual shutdown.
This follows actions/runner's tracking ID and orphan cleanup. Container jobs follow their container's lifecycle.