|
||||||||
|
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 [email protected].
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 ...