I reassigned this to the basic branch build strategies plugin because it provides this capability and describes it in the user documentation.

I just experienced this issue with child scans of multibranch pipelines in a GitHub organization folder. I had child scans set to run weekly, if not run otherwise, and when run, the scans picked up all tags, regardless of date, causing Jenkins to be flooded with hundreds of builds. Later today, I am going to try an organization scan to see if the issue occurs when scanning at that level, as well as tweaking the number of days of tags to keep.

I've attached a screenshot with my current settings, so hopefully this helpful for whoever decides to take this on. I will also take a look at the code this afternoon, but it's been a while since I've worked with Java, so I don't know how much I'll be able to help. Thanks in advance!

cc: rsandell, bitwiseman

BTW: There's also no log retention setting in the generated sub jobs, which results in long living branches, like master, keeping their history forever.

As far as I understand, this works as expected. A Build Strategy is responsible for the decision whether to build a newly discovered Tag Pipeline or not. The default strategy is not to build. The "Tags" build strategy changes the default to build but can be configured to ignore old or new tags.

For the tags not to be discovered or to be skipped in the first place the "Discover Tags" behavior of the Github Branch Source plugin needs to be extended or an extra plugin developed that adds a tag filter behavior.

OK, maybe I need to clarify further. I'm referring to tags that have actually been built. As opposed to branches, tags will most likely not go away again, so a multibranch pipeline collects subjobs for all the tags it has ever built. My request is that jobs for those tags that would now be ignored because of their age be removed again.

Another two months have passed and we're still collecting endless numbers of tag subjobs per multibranch pipeline. Any news here?

Hello! Can I ask you if there is any news about this ticket? Or if anyone that commented here has found an alternative solution? I have a repo with many many tags and the scan of it is causing a lot of pain at the moment. Thank you in advance!

Maybe I should raise the prio...

Bitbucket Aged References SCM Filter or GitHub Aged References SCM Filter may be suitable. I have not tried them.

FIrst, thank you for the answer! Second, unfortunately I'm trying it now and it doesn't look to do anything useful. I just setup a threshold of 30 days and did a couple of scans. It always fetches all the tags querying with a high rate the Bitbucket APIs. 

It seems this ticket got left out again..