Allow different values for the same parameters

[freaker2k7]

I was having a trouble of running jobs with different values for the same parameters.

While debugging, I noticed itemParams && executingUnitParams sometimes are both equal to and empty list ([]).

So if there're no params recognized then just start the job.

[yeluolei]

according to my debug, these value are always false for pipeline jobs.

[freaker2k7]

I have parametrized job and those variables contain lists, but somewhy they get empty lists after a while.

[freaker2k7]

Do a simple test:
Create a job that all it does is "sleep 60"
Then add 2 string parameters: X and Y
Restrict for throttling the following parameters: X,Y

Now run the following build (debugging /Users/evgy/MINE/html/throttle-concurrent-builds-plugin/src/main/java/hudson/plugins/throttleconcurrents/ThrottleQueueTaskDispatcher.java:346):

X=1,Y=
X=2,Y=
X=1,Y=
X=,Y=1
X=1,Y=1
X=1,Y=
X=1,Y=

Somewhere there you'll see itemParams && executingUnitParams will become empty lists.

In my real case I have a job that calls itself with a random uuid TOKEN environment var (parameter) and they don't get started because that job is already running with TOKEN="".
The restriction for this job (for the parameter throttling) is: TYPE,TOKEN
(the TYPE is the same...)
So the main job gets stuck.

[yeluolei]

no, for pipeline, it always empty, see https://issues.jenkins-ci.org/browse/JENKINS-37809

[basil]

Do a simple test: […] So the main job gets stuck.

Hey Evgeny, thanks for your contribution! For bug fixes, I suggest writing an automated test based on the scenario you have just described. You should be able to model such a test after the existing code in ThrottleIntegrationTest, ThrottleJobPropertyTest, and/or ThrottleStepTest. Please ensure there is an issue filed in Jira and mark the new test with @Issue("JENKINS-XYZ"). The test should fail without the changes in src/main and should pass with the changes in src/main. Once we have automated test coverage, I will be able to step through the failing scenario in a debugger and verify our understanding of the problem and its root cause, after which it will be much easier for me to review and integrate the fix.

[freaker2k7]

Thanks for the suggestion, will do.

BTW, I wasn't running pipelines, but a simple build bash script with one line: sleep 60

[basil]

@freaker2k7 @yeluolei Is this PR still valid now that #117 has been merged and released? I must admit I'm still not fully understanding the problem this PR is trying to solve. Writing an automated test would help me understand what is going wrong here. The two automated tests I wrote in #117 should serve as a good example of how to write such tests.

[freaker2k7]

You can close this one.