SAP
Make gerrit auto abort configurable
Is your feature request related to a problem? Please describe. A clear and concise description of what the problem is. Ex. I'm always frustrated when [...] Sometime aborting running build will cause issues. For push-validation, if build is aborted, the cleaner job will be aborted, too. This may cause resource leak. Describe the solution you'd like A clear and concise description of what you want to happen.
Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.
Additional context Add any other context or screenshots about the feature request here.
I'm not sure if this would be good or bad. An abort can happen all the time for various reasons. Maybe a user aborted a job, the cleanup script failed and did not actually do the cleanup, infrastructure issues and the cleanup job runs into a timeout, etc...
The automatic abort on a new patchset / change in PR is only one issue if you have cleanup jobs, which are supposed to be executed every time. A much better approach would be to handle external resources with InfraBox services: https://github.com/SAP/InfraBox/blob/master/docs/services/custom_services.md
An alternative would be to use a Cron Job to periodically cleanup up all you resources. You could run it every few minutes and if it's aborted once or failed for some other reasons it could cleanup things in the next run.
In our case, one of the things that we test using infrabox is indeed whether the code is successfully provisioning/deprovisioning external resources. In that sense, we expect a lot of failures during pull request phase of a change, hence need a cleanup script that talks with the external resource provider directly and cleans up all resources. Aborting cleanup job breaks this.
An alternative would be to use a Cron Job to periodically cleanup up all you resources.
This would require to store metadata of what's provisioned on an external storage such as S3 for cron job to see and delete. However, it's not easy to decide whether cronjob should delete all resource metadata it sees in the given bucket, because we have to store it in the beginning of the test. One could set something like if creation time is older than 6 hours, delete it but this will require all the tests to be shorter than that hard-coded time and also pay for the leaked resources at least for 6 hours.
In my case, I think I'll go with having above mentioned storing metadata externally and cleaning it in cleanup job instead of cronjob. Basically it will delete the current resource leak, then iterate over the externally stored ones. But to be honest, if a job can be defined as can never be aborted unless UI action is taken, it'd be great.
It would be possible to add this as a feature, but my point is that even if this feature would exist, it would not help you in all situations. So in any case one needs some kind of periodic job to cleanup things, because the cleanup job my fail for various different reasons and an abort is just one of them.
You could also use the REST API of InfraBox to find out if a Build has finished and only cleanup things for finished jobs. So you don't have to wait for 6 hours. If you put the resource names as environment vars / build args in the job definition then you probably don't even need any external metadata store.
Ability to check whether a build is finished looks promising. I still have to store the metadata because it's not known during build time.
I can store the infrabox build info together with resource metadata and let cronjob to check infrabox & delete resources. Is there a documentation about that REST interface of infrabox?