Pass param value maps back

[Willem1987]

Given the build step:

stage("Call` some other build") {
                steps {
                    script {
                        build(job: "start", parameters: [string(name: 'application', value: 'All')], wait: true)
                    }
                }
            }

Shows up as:

build({job=start, parameters=[null], wait=true})

I don't see the use for the paramInterceptor outside the ParametersDeclaration. I would like to see the params a build is called with in the call stack.

UPD: Updated formatting.

[stchar]

nice catch!

[Willem1987]

@stchar What kind of help would be needed? This is an MR with changes to fix including a unit test.

[stchar]

@Willem1987 Sorry I just thought that it is an issue not a PR =))

[stchar]

@Willem1987 Looks like i'm reimplementing your work in my #311

[Willem1987]

@stchar I posted a comment on #311. I feel we should treat param calls inside parameters and outside the block differently. I don't want to accidentaly overwrite parameters block if i start a downstream build with the same param name.

I mostly want to temporarily log the params.

But we should decide what way to go i guess.

[Willem1987]

I updated this MR and i am still don't see what the paramInterceptor would be used for here. It should be captured by the ParametersDeclaration i feel.

[felipeloha]

+1

[reinholdfuereder]

Although I am in the context of a scripted pipeline I think I have a very similar desire/problem:

• I need to override the default com.lesfurets.jenkins.unit.BasePipelineTest.stringInterceptor etc
  • https://github.com/reinholdfuereder/JenkinsPipelineUnit/tree/parameters
    • string parameter: reinholdfuereder@0858999
    • string parameter AND credential: reinholdfuereder@d77d261

Questions (maybe also/especially to @nre-ableton):

• Is the current default com.lesfurets.jenkins.unit.BasePipelineTest.stringInterceptor even OK/useful/correct in some context, if so in which one? But shouldn't be the default maybe more generic?
  • (UPDATED) The current default com.lesfurets.jenkins.unit.BasePipelineTest.stringInterceptor seems to be OK for withCredentials context => but in case of using parameters AND withCredentials it must be more generic!?
• Is my desire/problem a different issue and should I therefore file a dedicated issue?
• (Is there anything useful and easy that I should add/change in my aforementioned fork+branch to prepare a helpful PR?)

[Willem1987]

@stchar i updated this mr to the new master.

[Willem1987]

@nre-ableton anything i can do to get progress pr or the propertymissing?

Both issues prevent me from building tests the way id like. Id be open to further work on the prs if needed.

[reinholdfuereder]

@nre-ableton and @sams-gleb This also links with #460 -- which I think is not the perfect way, because the logic in

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

Line 28 in e33365a

def stringInterceptor = { Map desc->

is wrong with respect to withCredentials([string(credentialsId: 'gitlab-api-token', variable: 'GITLAB_API_TOKEN')]) { ...