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 usejenkinsProject 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 atopic/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 added4 commits

April 12, 2021 13:45

[JENKINS-63284] Bump plugin-pom to version 4.17

1c73c50

[JENKINS-63284] Bump antisamy-markup-formatter to version 2.1 to get …

ebc77cb

…rid of annoying log messages

[JENKINS-63284] Add test for jenkinsProject Groovy property

2027890

[JENKINS-63284] Add support for Pipeline job

2025859

M-r-A commented

Apr 12, 2021

View reviewed changes

src/main/java/org/biouno/unochoice/util/Utils.java

		privatestaticbooleanisParameterDefinitionOf(@NonnullStringparameterUUID,@NonnullJob<?, ?>project) {
		List<ParameterDefinition>parameterDefinitions =newArrayList<>(getProjectParameterDefinitions(project));
		for (List<ParameterDefinition>params :getBuildWrapperParameterDefinitions(project).values()) {
		// TODO: Update or get rid of getBuildWrapperParameterDefinitions

Copy link

Author

M-r-AApr 12, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

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

Copy link

Member

kinowApr 13, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

ThisisParameterDefinitionOf 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 commented

Apr 12, 2021

View reviewed changes

src/main/java/org/biouno/unochoice/AbstractScriptableParameter.java

		StringprojectName =null;
		StringprojectFullName =null;
		if (currentRequest !=null) {
		// TODO: Check if we really need AbstractItem instead of Job class

Copy link

Author

M-r-AApr 12, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

@kinow Same for this commentary: why do we useAbstractItem here but then filter withProject class ingetHelperParameters()?

Copy link

Member

kinowApr 13, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others.Learn more.

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 anAbstractItem.).

In case where the projectName is the name of anAbstractItem that is not aProject, we ignore that as we don't want to put another object instance in thejenkinsProject bound variable.

Copy link

c4sh commentedFeb 1, 2022

Is there a reason why this was never finished ?

Copy link

jan-stoltman-bolt commentedMar 25, 2022

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

Copy link

Member

kinow commentedMar 25, 2022

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

Copy link

dimmel82 commentedAug 17, 2022

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

Copy link

Member

kinow commentedAug 17, 2022

Thanks a lot for testing and reporting@dimmel82!

Copy link

JinPengGeng commentedJun 1, 2023

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

Copy link

asetty commentedJul 27, 2023

Pinging for updates

Copy link

mvanini commentedDec 17, 2023

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.

Copy link

wrbst commentedApr 14, 2025

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

3 years later.
What is going on with this PR ?

Copy link

Member

kinow commentedApr 14, 2025

Hi@wrbst

I merged changes contributed via PRs to adjust the code to changes in Jenkins upstream. The tests passed, and quick manual tests were OK too, and the code changes looked fine.

The plug-in releases got blocked due to regressions in the last release. It's been going for a few months already (you can check the commits & JIRA). Regressions and security bugs normally take most of myvolunteer time to work on the plug-in.

You can see in the comments (above) that there were some errors with this PR on user's environments, so I planned to work on this when I had more time as I expect some hiccups and need to do more tests.

If OP can rebase and fix conflicts, and others can test & send PRs to update it fixing the code, it would be easier to review. Otherwise, I'll work on this when I have time tovolunteer on this PR.

I'm highlighting this as you can see in thisrecent example that some users expect open source volunteers to prioritize the bugs/PRs regardless of their lives/jobs/family/personal issues/etc..