|
||||||||
|
This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators. For more information on JIRA, see: http://www.atlassian.com/software/jira |
||||||||
You received this message because you are subscribed to the Google Groups "Jenkins Issues" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-issues+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
I think Git brings in some different rules here, especially when You consider working with a Git branching model like (or inspired by) the one that is suggested by Vincent Driessen (see http://nvie.com/posts/a-successful-git-branching-model). With Git branching philosophies/methodologies and the Jenkins' Git plugin one of the advantages is that we don't need to create separate jobs for each branch we're actually working on. Would be a pity to loose this advantage.
OK, in the end I cannot judge if more users would prefer one over the other rule reflect the job status. A (global) configuration parameter for this could be a good idea.
And yes, I have to admit that implementing my suggestion wouldn't be trivial. Loading all builds and trying to find the failed or unstable branches is a little unconfident, because relevant builds might have been cleaned up. I'd rather record the branches with failed or unstable builds (e.g. using a file in the job directory), but this also might have some pitfalls.
Anyway, I'd try to implement such a feature if I know that it would be accepted. Otherwise it would not be worth it wasting the time.
p.s.: I see (at least) one more challenge/problem that might also need attention when having a job building several branches: The scores of the Continuous Integration Game plugin might not be reliable ...