why parameterized builds ?
This would be useful to CI any project that uses to create new branches (typically : feature or topic-branches) and don't want to create a dedicated job for each of them.

I guess you could use it that way. It would mean that the job could be unstable or failed even when trunk is fine, which could be confusing. Potentially worse, it means the job could be stable when trunk is broken. Parameterizing the build would clearly show individual statuses for each active branch.

This feature would be a very big win where I work too. We want to switch to topic/feature branches and being able to configure the repository once and then have it run dynamically for all branches would be a big win.

I understand jglick's argument though, about the job status. How does the Git plugin deal with this, and have they established an "acceptable" compromise?

I am not sure what the usual usage for the Git plugin is. It seems to use ** (rather than master) as the default branch spec, meaning it will go and build everything it finds in the remote repo, which is not normally what you want. The problem is that Jenkins has a linear build history which cannot easily express a branchy SCM repository.

Jesse,
The most common use case here is folks that don't store artifacts within Jenkins itself. Instead we deploy artifacts to a Maven repo (Artifactory, Nexus, Archiva). Since artifacts are versioned under maven, linearity is maintained by version in the repo rather than directly by branch with Jenkins. So having separate builds for separate branches is more a pain than an advantage. We don't need linearity (that comes for free on the repo side), we're looking free ourselves from the churn.

That all being said there is one additional and killer feature which would be nice to have. One the Git plugin doesn't support. Getting teams on large projects to properly maintain versioning can be... problematic. (Picture 8 dev teams spread across the globe supporting 35 webapps, all part of a larger enterprise system) At any given time one or more of those projects won't be maintaining version properly in their pom files. On projects like that I'd still like to have one job for all branches under each of those 35 projects. But, I'd like a way to maintain relationship between branch and version via a UI, and enforce that relationship at build time (preferably in a fail fast sort of way). Then I could guarantee that all builds like 2.4.X-SNAPSHOT and 2.4.X release came from the branch named sprintA. I'd associate 2.4.X and 2.4.X-SNAPSHOT with sprintA ahead of time. Then, if a build comes in on a branch named sprintB and the version is 2.4.X-SNAPSHOT, the plugin would know to fail it (That version doesn't match the branch I'd assigned it to.)

Anyhow... back to the feature requested in the ticket. It's needed.

@marc_swingler understood that you do not need e.g. lastStableBuild/artifact/x.jar to be meaningful since you would use the repo for that. But the lack of clear meaning for the job status (i.e. status of last build) remains; see http://stackoverflow.com/questions/13019222/is-there-a-branch-specific-badge-icon/13031723#13031723 for some discussion. Anyway, given the lack to date of a proper solution in Jenkins core the best that can be done in an SCM plugin is to offer this kind of feature and hope for the best.

@Jesse Nice post on stack. You hit the nail on the head there per build history mirroring the VCS tree. An API like you describe would be ideal. Hopefully it's an item we can bring to the attention of Kohsuke and the community. That being said, I don't think feature clash should prevent the Mercurial plugin from moving forward in the meantime. E.g. It's fairly intuitive to avoid use of 'discard all but latest stable' if you're building from multiple branches. In a similar vein I need to avoid certain features or other plugins when using the Maven Release Plugin-Plugin.

Have had various discussions with people including @sconnolly and the conclusion is that this is outside the scope of the SCM extension point as currently defined (and that it was a mistake for the Git plugin to try to implement it). Instead, there should be one job per branch, with either manual setup or other plugins being responsible for creating those jobs.

Yes, since my last round looking at this topic I have also switched to the one-job-per-branch camp. This is what is most natural considering job status - different branches may have very little to do with each other and their statuses shouldn't be mixed up.

But the topic in this ticket is still very relevant and might be appropriate to address in the generic Jenkins code. Either an offical new "super job" entity that can control automatic creation of other jobs, or some simple "clone this job for all branches" setting on ordinary jobs. Then SCM plugins would be required to report the active branches, which could be done at the same time as checking for new checkins.

@mikewse: yes @sconnolly is playing with something exactly like what you describe but I am not sure about the status. Stay tuned.