Problem Statement

We have had problems with anything that reacts to multiple branches or tags for quite some time now. Any form of multibranch plugin or plugins that check for tags, Pull Requests or anything like it. They all cause issues as soon as there is either an upgrade in which there are no logs from previous builds, after a disaster with data-loss or when re-running certain seed-jobs that modify (e.g. multibranch-) configurations. The issue presents itself in the form of complications due to rebuilds of every single branch, PR and tag for every single repository, at the same time. 

This might not be a problem for small and very short builds, but it becomes a huge issue for anything that runs longer than 5 minutes.

Firstly, this blocks the ability to build current and urgent jobs (since all slaves are busy building old branches/tags/PRs). Secondly, it requires immense amounts of resources (often times all of them, even if that means 120+ x 16 GB with 4 cores slaves) that wouldn't have to be used necessarily. Thirdly, the Jenkins Master almost always suffers from further crashes or erratic behaviour, since a lot of jobs are queueing up, all slaves are engaged and there is in general a lot of load on the system (unnecessarily so).

This kind of behaviour can not only be experienced on older environments with static slaves and everything running on VMs, but more specifically on more modern setups in which the Jenkins is created and runs stateless in a Kubernetes cluster. 

If there was a way to restrict or ignore old/stale branches/tags/PRs, basically all of the above mentioned problems could be solved.

Feature Proposal

The inline-pipeline-plugin can be used with all of these plugins and comes after all of the above mentioned plugins. It is the perfect location to add a restriction that would ignore branches/tags/PRs with a HEAD commit older than X days. Any branch/tag/PR with a HEAD commit older than that would not be listed and not built. In the case of a disaster, re-run of a seed-job, re-configuration of multibranch-jobs and even in the case of data-loss, only those branches/tags/PRs would be built that are relevant for current work. Anything old and stale could be ignored.

To make it configurable, there should be a field right beside the Markerfile field to define how old a HEAD commit in one of these branches/tags/PRs has to be, to be ignored.

Current State

Attached to this ticket is a Pull Request with a ready and working feature implementation for the proposed solution. It has been tested with our setup and works flawlessly with the full potential to solve our problems organisation-wide in case it gets merged and supported.