DSL Changes, Part I

[Daniel Spilker]

Hi!

Some time ago all methods configuring Jenkins BuildWrappers[1] moved from the job level into a wrappers context. The nice part is that all wrappers like steps and published have their own context.

// DSL prior to the change
job {
    allocatePorts('FOO')
}

// DSL after the change
job {
    wrappers {
        allocatePorts('FOO')
    }
}

Now I'm thinking about moving at least some methods which configure Jenkins JobProperties[2] to a properties context. Currenty all methods configuring JobProperties reside in the job context. One reason for the move is to unify the DSL so that properties are similar to wrappers, steps, etc. The other reason is that the properties context is needed for the extension point.

Currently it's planned that an extension point can declare a method that should add a DSL method to a specific context. That method can then return an object that is serialized to XML and appended to the children of the XML node represented by the context. Currently that would work for wrappers, steps and publishers but not for properties since those have no dedicated context. And the first extension being built is for the Promoted Builds plugin, which adds a property to the config.

Properties currently supported by the DSL methods are environmentVariables, throttleConcurrentBuilds, lockableResources, blockOn, priority, notifications, batchTask, deliveryPipelineConfiguration, authorization and parameters. All these methods will move to the properties context. Of course there will be a deprecation peroid for the existing methods.

// current DSL
job {
    authorization { ... }
    parameters {
        stringParam('FOO')
    }
}

// proposed DSL
job {
    properties {
        authorization { ... }
        parameters {
            stringParam('FOO')
        }
    }
}

The only problem I have with a properties context is that there is no corresponding UI concept. Like with wrappers, it's not obvious which settings has to go into the properties context when looking at the UI only. You have to refer to the docs or IDE support. When looking at the UI it's unintuitive that environment variables, build parameters or authentication options are properties. But since no one complained about the wrappers context, it may only be me and not a common problem. Or everyone is looking at the XML anyway.

What do you think? Should I add the properties context? Should I move all properties DSL methods or only some or none? Must I redesign the extension point so that the properties context is not needed? Your input is welcome.

And stay tuned for part II of DSL changes.

Daniel

[1] http://javadoc.jenkins-ci.org/hudson/tasks/BuildWrapper.html
[2] http://javadoc.jenkins-ci.org/hudson/model/JobProperty.html

[Patrick van Dissel]

Sounds perfect, I'm only looking at the XML anyway (as I just hate the
UI :))

I'm all in for adding the properties context and move all properties DSL
methods.

/Patrick

> --
> You received this message because you are subscribed to the Google
> Groups "job-dsl-plugin" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to job-dsl-plugi...@googlegroups.com
> <mailto:job-dsl-plugi...@googlegroups.com>.
> To post to this group, send email to job-dsl...@googlegroups.com
> <mailto:job-dsl...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/job-dsl-plugin/CAKqW32BHonARnNVDRiW%2BstGjjA0N-pGh-ByEbWe%3DG1ViH_MuxQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/job-dsl-plugin/CAKqW32BHonARnNVDRiW%2BstGjjA0N-pGh-ByEbWe%3DG1ViH_MuxQ%40mail.gmail.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.