gitness
gitness copied to clipboard
Run pipeline on cancel/timeout
Creating a feature request as suggested here.
The background to the feature request is as follows.
We have a build with a few pipelines that create AWS resources and in the end, after success or failure, those resources are destroyed.
However, if the build is canceled, there's no chance to run any cleanup code which means AWS resources are left running ad-eternum because, on our scenario, not all devs which can cancel builds have access to AWS to terminate said resources by hand. Doing it by hand also defeats the CI automation process :)
The request is to add support for running a pipeline on cancel
the same way there's support for success
and failure
.
Forgot to mention that when a build times out, we're also left with resources running, but in this case drone cancels(or kills) the builds, not us. Either way, this timeout scenario would also need to be covered by this feature request.
I have a need to run some cleanup code in a drone plugin.
However I would be happy with just changing this line to use ContainerStop
rather than ContainerKill
.
ContainerStop
will send SIGTERM before sending SIGKILL thus giving plugins a chance to trap the signal and clean up resources.
The stopping of containers should probably be parallelized and I'm not sure what the default timeout ought to be - but I'd be more than happy to submit a PR if these changes sound acceptable.
I was surprised to find that Drone immediately signals with SIGKILL
. There is no reasonable way for users to avoid remote resource leaks.
The drone-runtime was ostensibly displaced by discrete drone runners, perhaps in the time since the last update on this bug. This code now lives in engine/engine.go
.
I think we should provide identical behaviour -- graceful container termination -- when executing builds locally with the Drone command-line runner. (Which, incidentally, is where I first noticed this problem.) The drone-cli still appears to link with the old drone-runtime, and the drone-runtime repository has been marked archived. This bug cannot be fixed without first porting the drone-cli over to drone-runner-docker. Is that already on the horizon?
I had the same problem, when I canceled the deployment step I was doing, it caused a resource leak that took the server down and I had to restart the server.