That seems like a very good compromise to me. Reduce footprint for those that do not need it, and retain capabilities thru an extra plugin for those that need it
On Wed, Dec 11, 2019, 1:09 PM Oleg Nenashev <[email protected]> wrote: > Hi all, > > I am an active user of Pipeline Shared Libraries which are currently > defined in the Pipeline: Shared Groovy Libraries > <https://github.com/jenkinsci/workflow-cps-global-lib-plugin> plugin. > Historically the plugin was exposing a Git Server, and the code is still > there and enabled by default (WorkflowLibRepository > <https://github.com/jenkinsci/workflow-cps-global-lib-plugin/blob/master/src/main/java/org/jenkinsci/plugins/workflow/cps/global/WorkflowLibRepository.java>, > WorkflowLibSshRepository > <https://github.com/jenkinsci/workflow-cps-global-lib-plugin/blob/master/src/main/java/org/jenkinsci/plugins/workflow/cps/global/WorkflowLibSshRepository.java>, > etc.). This mode makes the Git Server Plugin a hard requirement for Jenkins > Pipeline, and it also causes startup overhead on Jenkins and Jenkinsfile > Runner instances. > > I doubt that the Git Server mode is popular at the moment, because now > there is embedded SCM Source support and a LibraryResolver > <https://github.com/jenkinsci/workflow-cps-global-lib-plugin/blob/master/src/main/java/org/jenkinsci/plugins/workflow/libs/LibraryResolver.java> > extension > point which allows defining library sources as extensions. I would suggest > to detach the Git Server mode to a separate plugin so that the majority of > users do not depend on it. > > What do I propose to do? > > - Git Server functionality is detached into a separate "Pipeline: > Shared Library Git Server" plugin. It includes all the current codebase and > retains the package names to retain the configuration/binary compatibility > - New major version of "Pipeline: Shared Groovy Libraries" is > released, the version is marked as incompatible > > There are potential ways to do the change without formally breaking > changes, e.g. via detaching the API side into uostream plugin instead of > creating a separate plugin. But it causes a lot more overhead for plugin > maintainers and instance maintainers who would have to cleanup the plugin > sets on their own. IMHO in this case such effort is not justified. > > Would appreciate any feedback. > > Thanks in advance, > Oleg > > -- > 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/CAPfivLC6purejJc7s_Cv5-1XNjEqbYboJr0QrSMriMhuZ6DUOw%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CAPfivLC6purejJc7s_Cv5-1XNjEqbYboJr0QrSMriMhuZ6DUOw%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- 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/CAO49JtG%2Bu_VN1ZZr7JuTvx_sYT87iSPXPSaPKpcsKWu9qAo3kg%40mail.gmail.com.
