Nicolas, Moving things to a separate JEP makes sense is some cases but it doesn't sound like the works here. The design choices that need to be made in relation to credentials CasC will effect the design of the JEP-201. Many plugins could be done in later JEPs, but for concepts as key as Credentials they would at least need to be concurrent JEPs and would need to be owned
Putting all that aside (as that is not the original point of this thread), the original suggestion was to include a version field in the CasC YAML. You said it would not work because the version would have to take into account the core version and versions of all plugins, otherwise it might break. Does that mean the CasC YAML could break _any time_ I upgrade any component? Doesn't that rather defeats the purpose of CasC? If anything all this strengthens the argument for having at least a top-level version field that guarantees some level of compatibility (perhaps at Jenkins Core API level). It further suggests that the CasC needs to include some guidance/structure for talking about CasC YAML changes. "No glue code" sounds great from a code/plugin-developer perspective, but it is sounding more and more like a anti-feature from user perspective. For v1.0, I suppose one could argue that this is a needed design choice to ship in non-infinite time, but that doesn't mean it can be completely ignored. Some thought will still need to be given to how to ease this pain or at least measure and clearly communicate how often breaks would have occurred in the last year if CasC had been around. -L. On Monday, May 14, 2018 at 8:22:53 AM UTC-7, Jesse Glick wrote: > > On Fri, May 11, 2018 at 5:44 PM, nicolas de loof > <nicolas...@gmail.com <javascript:>> wrote: > > Secret is already supported based on jenkins-core registered stapler > > converters. > > Yes; my point was only that due to the nature of secrets, JCasC needs > to support keeping the actual values separate from the main YAML file > somehow—whether via a generic variable interpolation system, or > symmetric encryption, etc. This is already part of the reference > implementation, which is good. > > >> 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. > > Yes, that is fine. > > > Maybe this should be discussed in a subsequent JEP if you consider this > > _that_ important. > > Perhaps, but my perspective is that a JEP should be reasonably > self-contained and define enough detail to implement an MVP, which > would certainly include support for credentials. If you defer this > aspect to an unspecified future JEP then there is a risk that this > planning either gets dropped, or that the integration turns out to > require fundamental design changes which are difficult to retrofit. In > other words, a JEP should describe a complete user story. > > Obviously there are plenty of plugins which should just have routine > integration with JCasC—fully automatic or with minor changes. But we > can reasonably expect that the endpoint configuration for the Aqua > Security Scanner plugin (whatever that is) could be managed without > “interesting” issues arising, and anyway most users of JCasC would not > be using this plugin. > > The Pipeline comparison is a little tough, since the core design there > long preceded the JEP process and was not formalized well, but the > analogy works so far as we are discussing modularity of code. For > example, the `withCredentials` step is indeed implemented in a > distinct credentials-related plugin, but there were some subtle > aspects that mandated special treatment elsewhere: the environment > variables in a block in `program.dat` needed to be kept encrypted, > which required API changes; and Blue Ocean needs to know to hide > secrets from step summaries, which also required special consideration > in other components. > -- 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/f10a6015-ddd6-476d-bddb-c9c4e7658329%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
