On Sat 9 Dec 2017 at 23:14, Mark Waite <[email protected]> wrote:
> Stephen added tag discovery as a response to user requests. Building from > a tag is likely to require different specialized behaviors for different > users. > > Some users won't mind if a tag is built more than once. Others will want > ways to reduce the risk that a tag is built more than once, even if the > Jenkins server is completely reset. Some users will only want the most > recent tag. Other users will want to consider all tags, but only within a > certain date range. Other users may want tags only accessible from a > specific branch or set of branches. Other users may want to consider only > tags which have a specific message, or a specific tag name format. > > Considering the many varied use cases for building tags, I believe his > intent is that plugins are the right way to allow users to select which > special cases they want, without adding all those special cases to a single > plugin. > Mostly correct. We worked very hard to tame the explosion of checkboxes for everyone’s pet scenario. I don’t want to block people’s pet scenarios because they are important to them, but the 90% of users will not share those specific use-cases. With extension plugins we let each Jenkins instance only install the extension plugins they actually need and consequently tame the UI configuration options presented to users. It cannot be a perfect taming as some instances may need different strategies for different groups of users... but it will be better than presenting a wall of checkboxes. In addition, we can make the testing easier as the core plugin will test the extension point api against its contract which reduces the untested surface for the extension plugin. For example with the branch build strategy, branch-api has tests for all the functionality that a bbs could do (no bbs, a bbs that says build, a bbs that says don’t build) so when writing a bbs you just need to verify that it returns true/false for the appropriate conditions. Finally, by defining a contract we reduce the plugin upgrade risk, as we can maintain the original well defined contract as we evolve. The down-side is discovery of potential traits that could be installed... but I may have a solution for that... namely if we add a link to a wiki page that uses confluence tags/labels to list all the extension plugins that could be installed. With small extension plugins, they should have very few dependencies, and hence can be installed without restart in the vast majority of cases... which lowers the barrier for the Admin-User, who is typically tasked with forging the path as to how to map Jenkins features to business requirements. -Stephen > Mark Waite > > On Sat, Dec 9, 2017 at 4:46 PM Ryan Campbell <[email protected]> > wrote: > >> I see that in JENKINS-34395 >> <https://issues.jenkins-ci.org/browse/JENKINS-34395> that we added >> support for discovering tags. However, I don't see a way to build >> automatically when a tag is made. >> >> According to the release notes >> <https://wiki.jenkins.io/display/JENKINS/GitHub+Branch+Source+Plugin>, >> we see: >> >> >>> If you want tags to build automatically, you will need an extension >>> plugin for Branch API that implements at least one BranchBuildStrategy, >>> see AngryBytes/jenkins-build-everything-strategy-plugin >>> <https://github.com/AngryBytes/jenkins-build-everything-strategy-plugin> for >>> a prototype example of such an extension plugin. >> >> >> Is this the intention going forward? It seems rather awkward to install a >> plugin for something that should be a checkbox. Do we have plans to come >> back to this topic? >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Developers" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-dev/f1f83e88-7b95-4f68-b7c1-c20288199750%40googlegroups.com >> <https://groups.google.com/d/msgid/jenkinsci-dev/f1f83e88-7b95-4f68-b7c1-c20288199750%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google Groups > "Jenkins Developers" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtEQ2iLbvZNQtSUWsu-5V-AuFtjE2-9D_Z3JYF4GUVsB7g%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CAO49JtEQ2iLbvZNQtSUWsu-5V-AuFtjE2-9D_Z3JYF4GUVsB7g%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Sent from my phone -- You received this message because you are subscribed to the Google Groups "Jenkins Developers" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMy%3DRD1z8bEGGWWenabh12Tfmccbf%3DjZuZr%3DoB4fMntNsQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
