|
||||||||||||
|
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.
It is definitely intentional that there is one configuration page for the overall project. Otherwise there is no point to having a multibranch project at all! You may as well just create a folder and dump some plain freestyle projects in it. So the RFE as originally stated makes no sense. Moving on to the particular use cases (any others should be filed as separate tickets):
This could I suppose be made into a BranchProperty, so that you could have some generic triggers (@daily etc.), combined with optional per-branch triggers (rebuild after any build of upstream lib-newly-used-in-this-branch).
Some kinds of triggers can work automatically without configuration, which is best. For example, a trigger can watch a Maven repository for new snapshot artifacts observed to be consumed by prior builds.
The “workaround” is exactly what you need to be doing. The more configuration is kept in SCM rather than Jenkins, the better. The project configuration should just ask to run some generic build script, whose exact content varies in response to ordinary commits.
(Literate projects, which also use the multibranch system, keep the list of all build steps in a file in SCM. This has the advantage of integration with Jenkins tool installers, which is less convenient in a freestyle multibranch project—though you could for example use the Tool Environment plugin to get a similar effect.)