Parameters for `build` step are not handled properly

[famod]

Jenkins and plugins versions report

not relevant

What Operating System are you using (both controller, and any agents involved in the problem)?

not relevant

Reproduction steps

In some pipline under test:

build(job: 'foo', parameters: [
    string(name: 'BAR', value: 'test',
])

Expected Results

The call stack should have something like:

somePipeline.string({name=BAR, value=test})
somePipeline.build({job=foo, parameters=['test']})

(or whatever the matching toString representation of a string parameter within build would be)

Actual Results

The call stack actually only has a null parameter (second line):

somePipeline.string({name=BAR, value=test})
somePipeline.build({job=foo, parameters=[null]})

Anything else?

Looking at DeclarativePipelineTest:

helper.registerAllowedMethod('string', [Map], stringInterceptor)

and BasePipelineTest:

    def stringInterceptor = { Map desc->
        if (desc) {
            // we are in context of parameters { string(...)}
            if (desc.name) {
                addParam(desc.name, desc.defaultValue, false)
            }
            // we are in context of withCredentials([string()..]) { }
            if(desc.variable) {
                return desc.variable
            }
        }
    }

I'm under the impression that params for a build step are wrongly treated as params for the current pipeline under test.

PS: Same seems to apply to booleanParam.

My workaround:
helper.registerAllowedMethod("booleanParam", [Map], { map -> map['name'] + '=' + map['value'] })
helper.registerAllowedMethod("string", [Map], { map -> map['name'] + '=' + map['value'] })

Are you interested in contributing a fix?

No response

[nre-ableton]

I don't think the issue is with booleanParam and string so much as the implementation of the build mock step:

JenkinsPipelineUnit/src/main/groovy/com/lesfurets/jenkins/unit/BasePipelineTest.groovy

Lines 134 to 141 in e9d29ff

	helper.registerAllowedMethod("build", [Map.class], {
	[
	getNumber:{100500},
	getDescription:{"Dummy build description"},
	getFullProjectName:{"some_dir/some_job"},
	getProjectName:{"some_job"},
	]
	})

I have no idea where there is dummy data there; it predates my time working on this project. git blame traces the original implementation to 08653bb, which is ~6 years old. There isn't any additional information in the commit message or corresponding PR to indicate why mock data is used here but not any of the other mocks.

Anyways, the implementation should probably just be helper.registerAllowedMethod("build", [Map.class]). I'll make a PR. I have no idea if anyone has written tests that depend on the mock data, though, so we'll need to bump the minor version number when making a release.

[nre-ableton]

@famod Is there any way that you can try out nre/master/747-rm-mock-data-build-step and see if it fixes the failures you reported?

[famod]

@nre-ableton thanks for taking a stab at this, but it doesn't seem to fix my issue:

First off, I didn't try your branch but I simply added your suggested fix to my test method (which should have the same effect, no?):

helper.registerAllowedMethod("build", [Map.class])

and I removed my workaround:

helper.registerAllowedMethod("string", [Map], { map -> map['name'] + '=' + map['value'] })

Unfortunatly, with all this I'm back to parameters=[null] in the call stack.

[nre-ableton]

So the problem is that stringInterceptor is basically used to add the created parameter to the pipeline context's params. In this case, you are creating a parameter object that is being passed to the build step and not the pipeline itself, but the testing framework doesn't care about that.

Modifying the string mock will be a bit delicate, and I'll have a look at it, but it will take some time to do this correctly.