[Jenkins CI] [Enhancement] Configure target job per branch

My company is an EE subscriber and the ability to drive different branches to jenkins projects has become really important to us.

Driving all branches to a single project worked out for a time, but became problematic for a couple of significant reasons...

• Value is diminished on trend reporting (build status, test results) because Data from less stable branches are mixed in with more stable branches.
• Auto-cleanup of old jobs based on number of builds becomes unpredictable. Latest builds from branchA can be destroyed due to activity in other branches. Raises the number of builds kept can mitigate this, but is an unreliable tactic since branch activity can't be predicted.

Auto-generating branches

The Jenkins Deprecated Service had an option for cloning a "master" project for each built branch. This would be awesome, but would (presumably) require work on both ends.

Edit: Auto-generation of branches has not shown any added value since this request was originally opened. Removed mention of it from this request.

Pattern Matching branches

The ability to specify the jenkins project based on a literal or pattern-matched branch name would also be valuable. It has the obvious disadvantage of needing to create/manage the Jenkins projects but could be valuable when using branch prefixes to identify development phases.

For example, the dev branch can go to one jenkins job, while the release-* branches can go to a release-candidate job, and the feature-* branches can go to yet another job. Some advantages:

• Smaller implementation effort (presumably)
• Visibility into trend data for development phases to identify problem areas. For example, frequent test failures in the release-candidate phase might indicate that the RC phase is being routinely started prematurely or is receiving too many high-risk changes (e.g. enhancements instead of critical bug fixes). Such a trend is more obvious if you are looking at the trend data across all release-* branches rather than each release-x.ybranch individually.
• Fewer jobs cluttering up jenkins (one job per feature branch can get noisy).
• Ability to fine-tune build process based on development phase.