Closures in pipelines possible? CpsClosure2 ClassCastException

[Ullrich Hafner]

Is it possible to use closures in a Jenkinsfile? I’m writing a new Step for the warnings plugin and I want to add filtering of the warnings.

What I have in my step is a data-bound setter:

@DataBoundSetter
public void setFilter(final Predicate<? super Issue> criterion) {
this.criterion = criterion;
}

In my Jenkinsfile I set the filter using the following step:

...
publishIssues issues:[java], filter: {issue -> issue.getPackageName().startsWith('io.jenkins')}
…

Then I get the following exception:

java.lang.ClassCastException: class io.jenkins.plugins.analysis.core.steps.PublishIssuesStep.setFilter() expects java.util.function.Predicate<? super edu.hm.hafner.analysis.Issue> but received class org.jenkinsci.plugins.workflow.cps.CpsClosure2
at org.jenkinsci.plugins.structs.describable.DescribableModel.coerce(DescribableModel.java:394)


Is my syntax in the Jenkinsfile wrong? Or do I need another method signature in my Step?

[Jesse Glick]

On Wed, Nov 1, 2017 at 2:58 PM, Ullrich Hafner <ullrich...@gmail.com> wrote:
> @DataBoundSetter
> public void setFilter(final Predicate<? super Issue> criterion) {

No.

[Jesse Glick]

Let me expand on my answer a little bit. :-)

Describable parameters may only be of very limited types: primitives,
strings, enums, other describables, lists of other describables.
`DescribableModel` goes into details. These are the things that
standard `/lib/form` controls can render (for example in *Pipeline
Syntax*), and that in `workflow-cps` can be bound by `DSL` and
suggested by `Snippetizer`. Thus all `Step` parameters may be of these
types only. Return values are more freeform, but basically you should
only return primitives or structs, no real objects.

Thus the whole concept of your `filter` parameter is impossible. This
is too Groovy-ish anyway. Think about more basic options. Where are
these “issues” coming from? If a bunch of files, then offer an Ant
patternset to consider only some files.

Or simply drop the feature altogether and keep the step nice and dumb.
If people with exotic needs have to preprocess their input a bit using
some Ruby script to control what gets published on Jenkins, so be it.
They do not need your help.

Anyway `WarningsPublisher` is already a `SimpleBuildStep`; is there
something else to do? Looks like you are missing a few `@Symbol`s, but
other than that?

[Ullrich Hafner]

Am 02.11.2017 um 16:08 schrieb Jesse Glick <jgl...@cloudbees.com>:

Let me expand on my answer a little bit. :-)

Describable parameters may only be of very limited types: primitives,
strings, enums, other describables, lists of other describables.
`DescribableModel` goes into details. These are the things that
standard `/lib/form` controls can render (for example in *Pipeline
Syntax*), and that in `workflow-cps` can be bound by `DSL` and
suggested by `Snippetizer`. Thus all `Step` parameters may be of these
types only. Return values are more freeform, but basically you should
only return primitives or structs, no real objects.

Thus the whole concept of your `filter` parameter is impossible. This
is too Groovy-ish anyway. Think about more basic options. Where are
these “issues” coming from? If a bunch of files, then offer an Ant
patternset to consider only some files.

Actually this is already possible, the files to scan are already specified using ant syntax.

Several users are filtering the warnings afterwards by matching filenames, packages or categories. 

In Freestyle jobs you have fields for each of these properties. I can add them individually as several String parameters for the step, I just thought it might be simpler to use a lambda (one to rule them all).

Or simply drop the feature altogether and keep the step nice and dumb.
If people with exotic needs have to preprocess their input a bit using
some Ruby script to control what gets published on Jenkins, so be it.
They do not need your help.

Anyway `WarningsPublisher` is already a `SimpleBuildStep`; is there
something else to do? Looks like you are missing a few `@Symbol`s, but
other than that?

What kind of symbols am I missing? The publisher has a symbol ‚warnings‘, are there other ones useful? 

There are a lot of issues that could not be solved with the single step concept. I explained it in more detail in a wiki page: https://wiki.jenkins.io/display/JENKINS/Static+Analysis+in+Pipelines

The prototype I am currently working on basically spilt this step into two steps, making it possible to call each parser n times (the scan for issues step) and to group the results into m actions (the publish step). Then you can group the results of parallel scans or different parsers and so on.