Feature Request: Treat interrupted builds as "pending" again instead of "failed"
I have a project that has a few dozen CI jobs, running on a group of Google Compute Engine VMs. To reduce our VM costs, we like to use preemptible instances; Google offers a big discount on the instance's per hour costs, but they reserve the right to yank them back with ~30 seconds notice at any time. So, while processing a CI job, the runner might get terminated (Google does provide a "shutdown script" configuration item that we can use to tell the runner to shut down cleanly).
This doesn't break anything in GitLab CI per se, but it would be nice if I could make it handle it a bit more cleanly. Specifically, if I gitlab-runner stop
my runner while it's in the middle of a job, I see this in the build log:
ERROR: Build failed: aborted: interrupt
GitLab clearly detected the interrupt and marked the build as "failed." For my application, though, it would be great if GitLab would instead re-mark the build as "pending," so it could automatically run again when another one of the runners becomes available.
Another approach might be to mark the build as "skipped" or "interrupted" and add a new build to the list that will run when available. I'm not married to the specific approach of handling it, but a clean way of handling interrupted builds without having to manually recreate new jobs or sift through a lot of "failed" reports that were really cases of runners being terminated would be excellent.
Does this make sense?