Let me try to convince you with a comparison : Pipeline is a central piece of Jenkins, and support for Git SCM in this context is a MUST HAVE. In early days "git" DSL step was actually implemented in pipeline plugin, but this later has been moved to git-plugin, where it perfectly make sense, so that design changes in git-plugin can be applied to "git" step in sync, and pipeline plugin just becomes a backbone for other steps (so the large amount of pipeline-*-steps plugins.
I'd like configuration-as-code to use the same approach : only provide the backbone for configuration support, then have everything specific to a plugin moved to target codebase, where it can be managed in sync. 2018-05-11 23:44 GMT+02:00 nicolas de loof <nicolas.del...@gmail.com>: > > > 2018-05-11 23:02 GMT+02:00 Jesse Glick <jgl...@cloudbees.com>: > >> On Fri, May 11, 2018 at 3:33 PM, nicolas de loof >> <nicolas.del...@gmail.com> wrote: >> > the exposed yaml model to >> > configure credentials should be defined as part of credential plugin, >> not by >> > me within configuration-as-code. >> >> Well. JCasC likely needs some special handling for `Secret`, which >> `credentials` uses for the actual secrets inside. Beyond that, I agree >> that it makes sense for the specialized binding to ultimately live in >> `credentials-plugin`. >> > > Secret is already supported based on jenkins-core registered stapler > converters. > > >> >> But I take issue with two ways this was framed. First of all, there is >> nothing wrong with the design of credentials storage; it is sensible >> given the expected usage model. JCasC makes it easy to autobind >> configuration that lives all in one configuration screen. In this >> case, the UI is divided into different screens with a specialized UI, >> so specialized binding would be needed. >> > > CasC is designed to manage data as a tree, which jenkins UI use to adopt. > But not credentials-plugin relying on Maps and singletons. > > >> >> Second, yes it needs to be defined “by you” (well, by whomever is >> striving to get JEP-201 accepted). Credentials are central to Jenkins >> setup and a critical use case for JEP-201. And JEP-201 is a new >> feature, so its developers are responsible for designing and >> implementing appropriate integrations with existing foundational >> components of Jenkins. >> > > I strongly disagree with this. From my perspective JEP-201 is about > generic mechanism to support configuration-as-code without glue code and > option for custom adapters where required. Credentials is for sure a > central piece of Jenkins, like pipeline is, or arguably many other plugins. > But it's not JEP-201 to define how those should be exposed as a > configurable data model. Maybe this should be discussed in a subsequent JEP > if you consider this _that_ important. From my point of view this could be > addressed within credentials plugin taking the decision on the model it > want to expose and provide the required glue-code. > > >> >> -- >> 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 jenkinsci-dev+unsubscr...@googlegroups.com. >> To view this discussion on the web visit https://groups.google.com/d/ms >> gid/jenkinsci-dev/CANfRfr0eorvLJovVf9Fbut-zt0F9zDSvF_ >> v0qa0ZsUrrz%2BoNAg%40mail.gmail.com. >> 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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJzm%3DYi3t%3DauTxD076fuqGJBzndf6ZCYnvz_bP-rkZFntgA%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
