WIP: [JENKINS-63284] Add initial Pipeline job support for Groovy properties

[M-r-A]

I want to add support for Pipeline job for Groovy script properties.

Currently, the plugin does not fully work with the Pipeline job: it uses classes that are specific only for the Freestyle job for getting extra data to inject to Groovy binding.

I changed plugin code to deal with Job/Run classes and added a test that demonstrates the result.

With these changes, users will be able to use jenkinsProject Groovy property with the Pipeline job.

Related issues: JENKINS-63284, JENKINS-65235, JENKINS-53554.
Related guide: Writing Pipeline-Compatible Plugins

• Make sure you are opening from a topic/feature/bugfix branch (right side) and not your master branch!
• Ensure that the pull request title represents the desired changelog entry
• Please describe what you did
• Link to relevant issues in GitHub or Jira
• Link to relevant pull requests, esp. upstream and downstream changes
• Ensure you have provided tests - that demonstrates feature works or fixes the issue

[M-r-A]

@kinow Dear maintainers, please help me with this part of the plugin. I'm unsure how we use getBuildWrapperParameterDefinition and how we test that it works.
Do we still need it with all these introspections with BuildWrapper and all?

[kinow]

This isParameterDefinitionOf method is called as a fallback when we cannot find the project of the parameter.

We navigate all the projects in Jenkins, trying to find one that contains the parameter UUID. It is highly inefficient, but was the last resort after getting so many bugs from users with custom plug-ins that were modifying the structure of project <-> parameters (i.e. inserting extra nodes in-between these two).

It should work with pipeline jobs, no?

[M-r-A]

@kinow Same for this commentary: why do we use AbstractItem here but then filter with Project class in getHelperParameters()?

[kinow]

From memory, the name or full name may have the project name. Or one of them may contain a folder name. Or a special object name (e.g. another plug-in that provides an AbstractItem.).

In case where the projectName is the name of an AbstractItem that is not a Project, we ignore that as we don't want to put another object instance in the jenkinsProject bound variable.

[c4sh]

Is there a reason why this was never finished ?

[jan-stoltman-bolt]

Hey @M-r-A @kinow would it be possible to finalize this PR? 🙏 This feature would be amazing to have

[kinow]

Hey @M-r-A @kinow would it be possible to finalize this PR? pray This feature would be amazing to have

Sorry, a bit strapped for time (life, work, being sponsored to work on other OSS projects, etc.)

Maybe someone could test the current PR with pipelines, and report whether it's working or not? That could help myself or another dev when re-starting the work on this code.

Cheers
Bruno

[dimmel82]

Hi @kinow,
I merged the PR to the master branch in a local clone and built the plugin. After installing the plugin on Jenkins, I tried to define a ChoiceParameter (also tried with lower-case and camel-case) in a declarative pipeline's "parameters" block but got the following error which shows that only specific types of parameters are allowed:

org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
WorkflowScript: 286: Invalid parameter type "ChoiceParameter". Valid parameter types: [booleanParam, choice, credentials, extendedChoice, file, text, password, run, string] @ line 286, column 5.
       ChoiceParameter name: 'ENVIRONMENT'
       ^

Maybe additional development is required in other plugins to support this feature.
Please let me know if my approach with the "parameters" block was the indented one or if should test in a different way.

Thanks,
Dimitris

[kinow]

Thanks a lot for testing and reporting @dimmel82!

[JinPengGeng]

Is there an update? I have been looking for this feature for a long time

[asetty]

Pinging for updates

[mvanini]

Hi @kinow, I merged the PR to the master branch in a local clone and built the plugin. After installing the plugin on Jenkins, I tried to define a ChoiceParameter (also tried with lower-case and camel-case) in a declarative pipeline's "parameters" block but got the following error which shows that only specific types of parameters are allowed:

org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed:
WorkflowScript: 286: Invalid parameter type "ChoiceParameter". Valid parameter types: [booleanParam, choice, credentials, extendedChoice, file, text, password, run, string] @ line 286, column 5.
       ChoiceParameter name: 'ENVIRONMENT'
       ^

Maybe additional development is required in other plugins to support this feature. Please let me know if my approach with the "parameters" block was the indented one or if should test in a different way.

Thanks, Dimitris

This PR is only for having access to Jenkins API for pipeline job types from groovy code used in the parameter's script.
Definition of the active-choices parameters in declarative way are not implemented but sure it would be an amazing feature to have.
We used mixed scripted/declarative pipeline to define this type of parameters. Is not so cool but it works.