you get it wrong : what I'm saying is that the exposed yaml model to configure credentials should be defined as part of credential plugin, not by me within configuration-as-code. The existing code is there to demonstrate we _can_ support credentials despite it's weird design (!) with some reasonable code, but actual credentials support is under credentials-plugin responsibility (also to consider this should follow credentials-plugin version, not configuration-as-code release cycles)
2018-05-11 21:23 GMT+02:00 Stephen Connolly <[email protected] >: > > On Fri 11 May 2018 at 17:32, Jesse Glick <[email protected]> wrote: > >> On Fri, May 11, 2018 at 11:14 AM, nicolas de loof >> <[email protected]> wrote: >> > we discover "jenkins" has a "securityRealm" attribute and some >> > implementation can be used to set this attribute. This directly defines >> the >> > yaml tree. But the codebase has no reference to this structure. >> >> Right. So, again, the version would not be referring to the existence >> or semantics of a `securityRealm` attribute. It would be referring to >> the logic that governs how the `Jenkins.getSecurityRealm()` method is >> mapped to a YAML attribute of that name, and how a particular >> `SecurityRealm` subtype is identified in its value. Now the case of >> the attribute name is pretty simple, of course—JavaBeans naming >> convention—but there can be more subtle cases: handling of symbol >> annotations or lack of them (which already comes up in the handling of >> `ldap` in this example!), collection types, getter/setter/constructor >> type mismatches, handling of secrets¹, convenience aliases, deprecated >> members, and so on. >> >> Experience with the `structs` plugin and its binding to Pipeline >> Script in `workflow-cps` indicates that there are plenty of hard >> problems to solve and it is not uncommon for the surface syntax to >> need to be changed in response. For Pipeline (talking about Scripted >> now) we never had a formal “language version” or anything like that, >> which has caused plenty of headaches trying to maintain compatibility >> with old scripts. I think JCasC will hit analogous issues. >> >> >> ¹Whenever that is actually formalized. As it needs to be, IMO, for >> 1.0—you cannot just say that the Credentials plugin maintainer is >> going to solve this for you. > > > Yeah, I advise against relying on me to fix schema version problems for > you :-P > >> >> >> -- >> 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/CANfRfr23zwVvy3RQxD7F_POsgDZxMtSt2vgM%3DGugGF913RTS% >> 2Bw%40mail.gmail.com. >> 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%2BnPnMwB%2BBCH2M5GiyfLiudpx% > 2Biaxchq7ZzbFi5hCeGccKuPBA%40mail.gmail.com > <https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwB%2BBCH2M5GiyfLiudpx%2Biaxchq7ZzbFi5hCeGccKuPBA%40mail.gmail.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/CANMVJz%3DfvStFRYJVGJYF19J56BYF2GQhDVfmXbtxz26qi40H1A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
