Arbitrary script as a filter

[dominykas]

The regexp based filter is very powerful and can be used to accomplish almost anything, but as soon as you have any kind of complexity in terms of events you want to handle, it can very quickly become unmaintainable.

For example we have a use case to trigger the same job from the following:

• PR opened against repo A
• PR merged in repo A
• main branch updated in repo B
• A comment on a PR in repo A or repo B
• PR title updated in repo A

All of a sudden you find yourself with a regexp like ^(case 1)|(case 2)|(case 3)...$ where each case has to list out all the contributing variables (with a .* at times).

It would be handy to be able to pass in a simple script as a filter instead.

[tomasbjerre]

Do you mean a Groovy-script?

Perhaps it helps if you change the regexp to just $ which will resolve the entire payload into the variable. And you can analyze the the payload in an initial stage within you pipeline code with Groovy.

Labeling this as enhancement.

[mkrauser]

Passing in a groovy-function somehow would be really handy in some cases, where a RegEx does not work. I have a pipeline which checks an external service after the build has been triggered. In certain cases, the build is then aborted. This works, but I always have the unnecessary build in the history.

[dominykas]

Do you mean a Groovy-script?

Yes, for starters 😅

j/k, Groovy is fine, yes.

And you can analyze the the payload in an initial stage within you pipeline code with Groovy.

That's what we're doing now, but that results in a bunch of jobs triggered - with all the costs associated (disk space, workers, cloning shared libraries, etc), incl. the mental overhead for the users to ignore those jobs.

[gongsu832]

On a related issue, is it possible for GWT to produce some diag info when a trigger fails the filter and therefore does not trigger the build? We have intermittent failures of GWT not triggering on some regex but works fine most of the time. It would be very helpful for debugging if GWT can tell why a filter has failed.

[tomasbjerre]

It would be possible to add debug logging that would log why a job is not triggered.

[gongsu832]

@tomasbjerre That would be very helpful. Thank you!

[tomasbjerre]

I looked at adding logging and actually there is already logging here: https://github.com/jenkinsci/generic-webhook-trigger-plugin/blob/832267e5ef5c98d79adc95333f097ae2d6322969/src/main/java/org/jenkinsci/plugins/gwt/Renderer.java#L33

[gongsu832]

@tomasbjerre Thank you for the info. The log message should come out in Jenkins log? I think Jenkins at some point switched to systemd log so I looked there and didn't find anything there. Is there any other reason besides not matching a filter that GWT would refuse to trigger a build?

I also see a massive number of the following in the Jenkins systemd log:

Aug 25 19:18:13 onnx-mlir.sl.res.ibm.com jenkins[3038434]: 2023-08-26 00:18:13.427+0000 [id=1116628]        WARNING        hudson.model.ParametersAction#filter: Skipped parameter `jenkins-generic-webhook-trigger-plugin_uuid` as it is undefined on `ONNX-MLIR-Pipeline-Docker-Build` (#12,470). Set `-Dhudson.model.ParametersAction.keepUndefinedParameters=true` to allow undefined parameters to be injected as environment variables or `-Dhudson.model.ParametersAction.safeParameters=[comma-separated list]` to whitelist specific parameter names, even though it represents a security breach or `-Dhudson.model.ParametersAction.keepUndefinedParameters=false` to no longer show this message.

Do you have any idea what might be causing this? Thanks!

[tomasbjerre]

Yes in the log. You have to enable fine logging, I do it like this: https://github.com/jenkinsci/generic-webhook-trigger-plugin/blob/master/logging.properties

That other logging is discussed here https://github.com/jenkinsci/generic-webhook-trigger-plugin/issues/261

[gongsu832]

Yes I just find https://github.com/jenkinsci/generic-webhook-trigger-plugin/issues/261. Let me try fine logging. Thank you @tomasbjerre