2018-05-15 0:20 GMT+02:00 Liam Newman <bitwise...@gmail.com>: > 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 >
As I tried to explain, credentials-plugin support is already there, just the syntax used by the configurator has been debated and this is really an implementation detail. I would have a strong -1 to define the adopted syntax in JEP-201. JEP-201 is here to define how we ensure this is feasible (like for any other component) and for this purpose we don't need anything special to be said about credentials plugin. About "Credentials" in the sense of "secrets" we already have external secret source support. This is a topic we could add some informations about. > > 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? > Yes indeed. CasC doesn't have it's own model, everything is based on actual java code discovery at runtime. So upgrading core or any plugin is changing this model. CasC targets reproducibility and immutability use-cases. If you want to upgrade anything you need to test it before. > > 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. > Sure, but then you need to write and maintain 1500 glue-code adapters. This is something we don't want to. This always has been a key topic to drive this effort. I'm sorry to ear this drawback wasn't clearer to you, was pretty obvious to me. There's nothing like free lunch; and no model / glue code means there's nothing we can parse as "v1.0" while we try to configure "v2.0", so a version number wouldn't help here. > > 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. > Hard to tell, but probably on a regular basis. At least any time a major plugin did changed it's UI binding (DataBoundConstructor). > > -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> 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 > <https://groups.google.com/d/msgid/jenkinsci-dev/f10a6015-ddd6-476d-bddb-c9c4e7658329%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 jenkinsci-dev+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANMVJzmGeVxVOYspPfejQ%2BxgWUFuTFdbObeU%2BTMZGZU_KJUCrQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
