May be you are using declarative pipeline syntax instead of scripted pipeline.
Ah, that explains why it didn’t work. My pipeline has been written using declarative syntax, so it’s no wonder why parameters cannot be nested within options, especially inside ([...]). I didn’t realize until now that this syntax cannot be used in declarative pipeline.
@VladyslavKovalov thanks for brief explanation.
Running Jenkins version on this project is the latest one, 2.401.1
So basically it turns out that whole code needs to be refactored to the scripted one because of that minor detail with passwords, which sound like a really huge amount of work at this moment. Not sure if it’s worth it.
So far, code:
string(name: 'VAR1', defaultValue: params.VAR1 ?:'default value')
does exactly what I wanted to do: if there’s existing value already, don’t touch it. Othervise, provide default value.
Except the password parameter, ofc which I cannot figure out how to deal with it.
If I try something like this:
password(name: 'PW1', defaultValue: params.PW1 ?:'dummypassword')
It basically erase existing password value on first build if it finds it there. If I try a second build (when password is already erased during previous build), then it provides default value. And over and over…
Workaround for that could be to convert password to string, but then it would be visible to anyone who runs the pipeline, which is bad idea.
I’m sure that there must be a workaround for this issue.