[JENKINS-64810] Add creation time boundaries to tags for discovery

[dodo920306]

[JENKINS-64810] Multibranch pipeline still showing Git tags older than configured threshold

This PR does not address JENKINS-64810 in the way originally expected, because the issue stems from a misunderstanding of the help messages in the basic-branch-build-strategies-plugin.

The plugin currently describes the time-based tag filtering as:

The number of days since the tag was created before it is eligible for automatic building.

and

The number of days since the tag was created after which it is no longer eligible for automatic building.

The original issue incorrectly assumed that these settings should remove tag jobs outside the configured time range. However, what the basic-branch-build-strategies-plugin actually implements is an extension of jenkins.branch.BranchBuildStrategy from the branch-api-plugin, which does not have the authority to remove jobs. It simply prevents automatic builds for tags outside the specified time window—which it already does correctly.

While it might seem that this issue could be closed based on this clarification, I believe otherwise. After reaching out to the original reporter, Dirk Heinrichs, I found that—despite the misunderstanding of the underlying mechanism—their actual user need remains valid. As the reporter put it:

I guess the logic, or expectations in the plugin are wrong. It removes branch jobs X days after branch removal according to the configured retention time. But it seems to treat tag jobs in the same way, which is wrong, since tags are usually never removed. So since it correctly ignores tags created more than X days ago when creating tag jobs, it does not have any mechanism to remove the jobs again.
So what this ticket really is about is to treat tag jobs (or better: their removal) differently than branch jobs. For example: Remove tag jobs X days after their last (successful) build.

While this problem shouldn't be addressed by modifying the basic-branch-build-strategies-plugin, the user still needs a way to visibly filter old or future tag jobs through the UI.

After tracing through the codebase, I found that this functionality could be effectively implemented in the git-plugin. In this PR, I introduce two new string parameters—atLeastDays and atMostDays—to the TagDiscoveryTrait class. These parameters mirror the ones from the basic-branch-build-strategies-plugin and define the lower and upper bounds for the tag creation time.

I then added corresponding logic to GitSCMSourceContext to accept and propagate these values (converted into long), and finally used them in AbstractGitSCMSource inside the discoverTags function to filter tags based on age:

...
if (atLeastMillis >= 0L || atMostMillis >= 0L) {
    if (atMostMillis >= 0L && atLeastMillis > atMostMillis) {
        /* Invalid. It's impossible for any tag to satisfy this. */
        continue;
    }
    long tagAge = System.currentTimeMillis() - lastModified;
    if (atMostMillis >= 0L && tagAge > atMostMillis) {
        continue;
    }
    if (atLeastMillis >= 0L && tagAge < atLeastMillis) {
        continue;
    }
}
...

This implementation and its corresponding UI (.jelly definitions) are heavily based on TagBuildStrategyImpl from the basic-branch-build-strategies-plugin.

If this PR is merged, users will be able to use TagDiscoveryTrait to filter tag jobs by creation time, thereby fulfilling the practical need described in JENKINS-64810—even though the original interpretation of the issue was flawed.

Please also let me know if there’s anything I should revise or improve. Thank you for your time and guidance!

Testing done

None yet.
I could use some help here, as I'm unsure how to add proper tests for this change in AbstractGitSCMSourceTest.
I've installed it on my local Jenkins instance, and it works well with my git tags.

Submitter checklist

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests that demonstrate the feature works or the issue is fixed

[dodo920306]

Hello?
@jenkinsci/git-plugin-developers

[MarkEWaite]

Hello? @jenkinsci/git-plugin-developers

Hi. I'm deeply involved in other topics currently. I don't expect to review this pull request for a month at least. You can use the incremental build of the pull request in your use so that you immediately get the benefit of your changes. When new changes merge to the master branch, update your branch with those changes and a new incremental build will be pushed to the Jenkins artifact repository.