FYI an experimental branch tried to rethink the design of the Job-DSL integration (and more generally address the scalability of the promoted-builds-plugin DSL) https://github.com/jenkinsci/promoted-builds-plugin/pull/96#issuecomment-255899713 :
The driver for those changes is the scalability of the DSL extension when using the existing implementation:
- promoted-builds-plugin developers may not know how/when they also have to provide DSL integration to allow `job-dsl-plugin`. Eg: GroovyCondition is not covered by the DSL extension even though it is provided by the very same plugin.
- Third-party plugin developers wanting to extend promoted-builds-plugin (ie. wanting to provide custom PromotionCondition (which extends ExtensionPoint) for their own plugin) have to add binary dependency on promoted-builds-plugin to their own plugin because of the domain object to XML serialization approach (this creates a chicken-egg problem defeating the purpose of providing {{ExtensionPoint}}s).
- job-dsl-plugin users cannot manipulate the PromotionProcess XML to workaround lack of integration https://github.com/jenkinsci/job-dsl-plugin/wiki/The-Configure-Block
Those issues all have a common impact: they prevent job-dsl-plugin users from being able to generate fine-tuned promotions as soon as the components they need is not implemented into the DSL extension.
The proposed changes tries to adopt the https://github.com/jenkinsci/job-dsl-plugin/wiki/Automatically-Generated-DSL approach applied to this DSL extension to fix those issues.
As for the implementation, it indeed needs to be improved/fixed at least for the reported issues
The branch itself brings its share of issues (as reminded by plugin maintainer): binary compatibility and migration path. It could also use some advice from job-dsl-plugin maintainers for approval/endorsement purpose.
"Keep build forever" action, which is a step that is provided by promoted builds plugin is also not supported in the DSL at the moment. Adding a Configure block support would be great.