JEP Submission: Jenkins Configuration as Code

[ndeloof]

No description provided.

[oleg-nenashev]

It would be great to have mentions of particular representatives on GitHub. There is no way to mention an org in the PR discussion

[bitwiseman]

@ndeloof
You are welcome to mention the github org that the sponsor is a member of but that org can't be the sponsor.
See the definition and duties of a sponsor. The sponsor(s) must be a person able to be the point of contact.

[oleg-nenashev]

As it was discussed before, "Configuration as Code" is a bit ambiguous. When I was talking about use-cases of this plugin, @rtyler was proposing to rather use a more classic Infrastructure-as-Code term

[ndeloof]

I tend to disagree. "infrastructure" would make me thing we manage machines and OS, which isn't the case : we manage jenkins configuration.

[abayer]

I don't love either term, but "Configuration as Code" is better than "Infrastructure as Code", IMO. The latter feels like Puppet more than "Managing Jenkins global config and the like".

[bitwiseman]

@ndeloof
The title may need to change later but does not block approval as draft.

[oleg-nenashev]

We probably need to fix them independently of this JEP. The problem is that there are complex structures and custom forms sometimes. Would be great to know a list of plugins and core changes required for MVP.

[daniel-beck]

will need to fix them

This seems to be a massive change -- I wouldn't be surprised if this affected hundreds of plugins, not to mention any plugins that would be newly incompatible since newInstance isn't final (and probably never will be).

I would strongly suggest looking into a way to get this implemented without requiring all @DataboundWhatever for better compatibility.

[oleg-nenashev]

If the plugin offers extension points for such custom cases, it would be already helpful.

[ndeloof]

if an extension point is introduce and plugins have to adopt them, we are back in the issue to require hundreds plugins to be fixed. @DataboundSetter should be enough. Main issue AFAICT is one can't reset to null a Databound attribute.

[daniel-beck]

we are back in the issue to require hundreds plugins to be fixed

I recommend you look into how many plugins use non-databound form submission data. I don't see how requiring moving to @DataboundX is different.

[ndeloof]

@DataboundSetter is obvious way to document attributes and types for form submission. With custom databinding we can't guess this model, and generate a configuration-as-code schema/doc.

I've started reviewing existing Descriptors and indeed there's various patterns. optional blocks typically introduce a boolean pseudo-attribute and nested JSON document, while Descriptor use nullable attributes. This hardly can be translated into a @DataBoundSetter (won't be invoked on null value)

[oleg-nenashev]

Why not both? Supporting pure DataBound plugins by a generic solution is perfectly fine. Regarding else, there should extension points which allow doing it without reworking to DataBounds. I think that the latter thing is inevitable, migration to databound forms may be even impossible in some cases

[ndeloof]

prototype already defines a Configurator extension point plugins can implement. But then they'll depend on this plugin. Issue I can see doing this is plugins will need to implement configuration twice : one for c-as-c and the other for web UI binding. Using DataBound mechanism ensure we are un sync.
I wonder what would prevent use of databound. After all it's just a replacement from foo = json.getXX() to @DataBoundSetter setFoo(xx). If the raw form data is then computed to something else, same code can move into such a setter.

[bitwiseman]

@oleg-nenashev @daniel-beck
This is a JEP SUBMISSION.
Please refrain from commenting on details beyond document structure and sufficient prototype.

If you feel the prototype is not sufficient to begin discussion and consensus building. If you disagree with the design of the prototype, that should be discussed after the draft is accepted.

See the submission conformance check section of JEP-1. And if that section is not sufficiently clear, please PR.

[oleg-nenashev]

JEP-1 is accepted, so now I am going to request changes. JEP Sponsor should be a human being with GitHub account

[bitwiseman]

@ndeloof Not to be picky, but would you mind not including the logo at this time?
Unless an image is required for the clarity of the JEP, I would prefer it not be include. This is not a policy choice, just a request that we limit extra resources for the moment.

@bitwiseman asked me to dismiss the review

[bitwiseman]

As noted, there needs to be one or more people as sponsor, not an organization.

[bitwiseman]

@ndeloof
Is there an email on the dev list or a comment in that JIRA naming this person as BDFL delegate (and getting agreement from other contributors)? If not, would you mind if I return this to BDFL until we have that?

[ndeloof]

sure, no worries

[bitwiseman]

Approved as Draft JEP: 201.
Updating and merging to master.