|
||||||||
|
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/groups/opt_out.
Sorry for letting you wait so long.
Here is an example what the problem actually is like. We are producing DVD images which are mostly an assembly of hundreds of unrelated Maven projects (some of them are deeply nested multi-module, some of them are simple but unrelated) – think of something similar to a Linux Distro DVD, but for business software instead of an OS. Once the DVD image master is released (which should be a single mouse click or REST API call against Jenkins server), we provide support contracts to maintain these in a many-years term stability-only way. The contracts force us to be able to provide bug fixes for all the contained projects even after years, but not any new features. This leads to thousands of projects over time, so manual job management is impossible. Hence, at time of DVD release, there must be a MVN release:perform get issued for all of the contained projects of that DVD, labelled as the version of the DVD, as this will become single SVN branches in lots of SVN repos for maintenance of that contained products. At the same time, all of that projects must be cloned and updated regarding SVN URL and job name in Jenkins, as we certainly want to have CI for that new branches. And certainly, we now want to have a new view created that lists only the projects contained in that release to not being forced to filter manually each time we look at Jenkins. I do not see how this can be done easily and in a stable way using any of the existing plugins. Maybe the CloudBees Free Enterprise Plugin solves this, but if that is the case, it would be good if someone of CloudBees would simply confirm that the above workflow will be solved.
I hope that makes clearer why we think that nested projects is a needed core feature: It would provide the core structure and the core API so all tools and plugins would now how to handle the nesting structure, and would be inter-operable instead of reinventing that hierarchic thinking on their own in an incompatible way.