[workflow-plugin] Compatibility with hetero-list and DescribableList?

[Nicolas Reibel]

Hello,

I am working on a quite complex post-action build, where the user can select which info to display through a hetero-list.
For this purpose, I overwrote the function newInstance from the plugin descriptor to call function DescribableList.rebuildHetero(...)

Now I am studying the possible integration with the Workflow plugin, and so far, the only way I know to set up this describable list is to instantiate all items by hand, and create a DataBoundSetter, e.g. :

node {
  def item1 = new ItemType1( 'SomeParameter' )
  def item2 = new ItemType2( 'SomeParameter' )
  def item3 = new ItemType3( 'SomeParameter' )
  [...]

  step([$class: 'MyPlugin', input: 'out.xml', items: [item1, item2, item3]])
}

Now as I understand, there is no way to configure a step via GUI (using the existing config.jelly from the post-build action).
I also don't know how to generate a snippet to define the items, the snippet generator only generated the code :
step([$class: 'MyPlugin', input: 'out.xml'])
which is based on the DataBoundConstructor

There are several drawbacks to this :
- First, the writing is complex as the user has to know exactly the classes and parameters available
- Second : in FreeStyleProjects, a new plugin instance is generated for the project each time the configuration is changed, and builds can easily find a reference to it. Here, a new plugin is configured for each run, is that right? If yes, that means any change I do to a job (change the items to be displayed) won't affect other builds, as they don't share the same plugin instance, thus have a different DescribableList

Any idea here on how tos olve these issues? Surely I'm not the only one

Thanks

[Jesse Glick]

On Friday, March 13, 2015 at 10:41:43 AM UTC-4, Nicolas Reibel wrote:

I am working on a quite complex post-action build, where the user can select which info to display through a hetero-list.

First of all, this might better be sent to jenkinsci-dev.

 

For this purpose, I overwrote the function newInstance from the plugin descriptor to call function DescribableList.rebuildHetero(...)

This is a red flag. You should not need to override newInstance, even for complex hetero lists. You just need a getter + @DataBoundSetter taking a collection of your Describable subclass. (You may use a @DataBoundConstructor parameter instead of a setter if the attribute should be considered mandatory.)

https://github.com/jenkinsci/ui-samples-plugin/blob/2ab631671f90abf496e319b8334ce32c414d9dc7/src/main/java/jenkins/plugins/ui_samples/HeteroList.java#L89-97

Now I am studying the possible integration with the Workflow plugin, and so far, the only way I know to set up this describable list is to instantiate all items by hand, and create a DataBoundSetter

If you use normal databinding, the Snippet Generator will offer a syntax that does not use the `new` keyword or otherwise refer directly to Java types (which would be undesirable anyway since such scripts could not run in the sandbox for a secured Jenkins installation). It should be offering something like

step($class: 'YourPublisher', input: 'out.xml', items: [[$class: 'ItemType1', param: 'SomeParameter'], [$class: 'ItemType2', param: 'SomeParameter']])

Not an ideal syntax but at least the UI can assist you in writing it (and a future version of Workflow may offer a streamlined syntax automatically).

in FreeStyleProjects, a new plugin instance is generated for the project each time the configuration is changed, and builds can easily find a reference to it. Here, a new plugin is configured for each run, is that right?

If by “new plugin instance” you mean “new Publisher instance”, then yes that is correct.

that means any change I do to a job (change the items to be displayed) won't affect other builds

You mean historical builds? Sure, they will use whatever configuration the script specified when the build was run. If you think you want it otherwise, you are designing something the wrong way.

[Nicolas Reibel]

Thanks for the answer! Indeed this seems to be the wrong channel, sorry for that...

Your advice on the DataBoundSetter is duly noted (and implemented), now the API handles the work

As for the last comment (yes, I'd like to reflect changes in the plugin on previous/historical builds), here are some insights :

The plugin reads data from an XML file, and displays it in various styles (tables and graphs)
While the data itself will not change (nor the format of the input file), the owner of the project might want to display it in the form of a graph that would be visible in all previous builds also.
If you know of a better way to handle that use case, please let me know.
At this time, I have this method of MyAction that gives me access to the last instance of my plugin :

    public MyPlugin getPlugin() {
        Job project = build.getParent();
        if (project instanceof Project) {
            DescribableList publishers = Project.class.cast(project).getPublishersList();
            for ( Object o : publishers ) {
                if (o instanceof MyPlugin) {
                    return MyPlugin.class.cast(o);
                }
            }
        }

        return plugin; // Private attribute, stores the instance of MyPlugin at the time of the action's creation
    }

Thanks for your help!