Some things that might otherwise have gotten lost in IRC.
About the automatic inference of symbols like `ldap` from
`hudson.security.LDAPSecurityRealm`: this seems like a nice trick to
use when prototyping the JEP, so you can see realistic stuff working
before plugins are updated to use `@Symbol`. But I do not think this
should be retained in a 1.0 version—all supported plugins should be
given the annotation. Reasoning:
· Adding an annotation poses no risk to plugin stability, so there is
no reason for a maintainer to object to it.
· Symbols must be unique within their extension point (for example
there may be only one `SecurityRealm` named `ldap`), so they must be
chosen carefully and deliberately.
· People might begin relying on the inferred names and then it would
be a compatibility issue to fix this later.
The credentials domain syntax, IIRC something like
system:
? # global
: -credentials
# …
baffles everyone who sees it. Just because internally `credentials`
uses a `Map` from (I guess) domains to lists of credentials does not
mean you must reflect that in YAML syntax. You should rather model a
list of credentials, each of which may have an optional attribute for
the domain (ID?).
It is no excuse that you are trying to keep things mapped tightly to
the databinding model in the plugin, because Jenkins databinding does
not have any standard support for `Map`s at all—this is all bound to
custom UI screens in `credentials`. Therefore it is reasonable for
JCasC to also have a custom converter. Plugins which use simple
databinding, which would consist of `List`s of `Describable`s only,
would not need any custom code.
Using Job DSL Groovy to create jobs is fine as a short-term workaround
but should not be how `TopLevelItem`s are defined in 1.0 I think.
There should be native YAML syntax for this, based on the same
databinding model as any other settings. As `@Symbol` is adopted,
these should look structurally similar anyway.
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr3e56PQf4vrDLPjPU11MxzKX3L%3DR%2BQVROgyAyuKRYB97A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
On Tue, Apr 17, 2018 at 2:03 PM, nicolas de loof
<nicolas...@gmail.com> wrote:
> the yaml schema is for a specific version of jenkins-core + plugin.
> Any change to a plugin will change this model, this will happen any time a
> DataBoundConstructor is modified
Well, typically we would expect parameters to be compatible after a
plugin update, so that if for example a `@DataBoundSetter` method
needs to be `@Deprecated`, it is removed from databinding but still
accessible as a Java setter. The compatibility policy for such
refactorings does need to be defined. Currently we only expect plugins
to be compatible in their XStream settings form, plus Pipeline `Step`s
and any `Describable`s used by them need to continue to accept
parameters that worked before.
> I would anyway expect Credentials plugin to own this code, so such decision
> is made from maintainer
JEP-201 is introducing a new overall Jenkins feature, and the
Credentials plugin is a longstanding piece of plumbing, so I would
expect JEP-201 developers to address this particular integration.
> I don't understand why this plugin adopted this
> odd design - most probably for compatibility reasons
I do not think compatibility had anything to do with it. The
configuration model of Credentials is that you have various providers,
inside of each of which you can create various domains, each of which
then contains a set of credentials. The Java-level structure is more
or less arbitrary and was not intended to map directly to Jenkins
databinding, because its UI manifestation is not a single
configuration screen.
> sounds to me job-dsl could support a yaml syntax (just by switching
> parser)
Why would you need `job-dsl` at all? You already have a general system
for binding YAML to `Describable`s. You would need a bit of extra code
to bind some syntax to `TopLevelItem` and
`DirectlyModifiableTopLevelItemGroup`, and a call to JENKINS-50173 if
and when written.
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr00%2BpNy%2BSfbY%2BLeye-GYd0v7Q%2BxttRZCJddyv_Y8fgOyA%40mail.gmail.com.
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CANfRfr03rVj6r1tWfwYeO1QKeDMtDYjuc8fF0Se%2B4Rh9qbZFvg%40mail.gmail.com.
2018-04-18 0:42 GMT+02:00 Jesse Glick <jgl...@cloudbees.com>:On Tue, Apr 17, 2018 at 4:45 PM, nicolas de loof
<nicolas...@gmail.com> wrote:
> Job class hierarchy is full of hand written JSON parsing
I suspect such cases are fixable, which would take some work, but on
the other hand we would get a clearer code base as a result anyway.Sure, but this will be for future version thenWe want JCasC to support current releases of Jenkins by Praqma customers (and others), not require bleeding edge Jenkins core.
--
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-de...@googlegroups.com.
@bitwiseman Discussion on plugin management was probably introduced in this JEP too early as we don't have a prototype for it (update center doesn't even have the required metadata)
Would it make sense to revert this commit so we can follow-up with JCasC as an approved JEP, and prepare another JEP about plugin management (which would apply to docker images and probably few other use-cases) ?
Just FYI: Nicolas asked a question of me in a GH comment:@bitwiseman Discussion on plugin management was probably introduced in this JEP too early as we don't have a prototype for it (update center doesn't even have the required metadata)
Would it make sense to revert this commit so we can follow-up with JCasC as an approved JEP, and prepare another JEP about plugin management (which would apply to docker images and probably few other use-cases) ?I figured I'd respond here rather than buried in GH comments.Nicolas,To be clear: I'm not Reviewer for this JEP. I set it back to this "Draft" with the agreement of the sponsor as part of a clarification of the JEP process.
It sounds like Ewelina is working on further updates (including incorporating the JOM feedback - yay!) and hasn't requested Review for Acceptance yet. As sponsor, when she believes the JEP meets the requirements for Accepted status, I'm sure she'll request that it be reviewed again.
Ewelina,Thanks for taking the time to incorporate feedback and to make sure everyone is clear about the on-going status of the project. I don't know that I need to be involved in the maintainers meeting, but feel free to send me an invite.-Liam
On Tuesday, May 8, 2018 at 3:34:28 AM UTC-7, Ewelina Wilkosz wrote:just a short update - JEP update in progress, next week we're planning a short maintainers status meeting where I hope to clarify stuff and PR will be sent
On Thursday, May 3, 2018 at 12:24:07 AM UTC+2, Jesse Glick wrote:On Wed, May 2, 2018 at 3:58 PM, Ewelina Wilkosz <ewel...@gmail.com> wrote:
> Any of you interested in contributing to that one? Please let me know, so we
> don't duplicate
I will leave the reasoning to you! Just bringing up things that seemed
to merit discussion.
--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/56c5a171-f7ed-4f53-bd67-c79bb182bb91%40googlegroups.com.
credentials:
system:
domainCredentials:
- credentials:
- usernamePassword:
scope: SYSTEM
id: sudo_password
username: root
password: ${SUDO_PASSWORD}