-
Improvement
-
Resolution: Won't Fix
-
Major
-
None
-
Any
Improvment demanded: Have the possibility to monitor all branches from the same repository. This feature exists through GIT plugin.
On attachment you can see the difference between both plugins.
In fact to avoid any regression it's to add on Mercurial plugin in option this feature:
- Through a radio button
- Or on this field by '*'
This feature could be really helpfull in usage of unbreakable build process because we could launch a single job for all branches (especially when we are working in feature teams)
Thank you
Arnaud
[JENKINS-11102] Give the possibility to monitor all branches as Git plugin
Arnaud Gueremy
created issue -
| Assignee | Original: Kohsuke Kawaguchi [ kohsuke ] | New: Nicolas De Loof [ ndeloof ] |
| Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
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.
Mike Wilson
added a comment - 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?
Mike Wilson
added a comment - 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.
This feature would be very useful for our intended workflow