Use the same stringInterceptor in declarative and scripted pipelines

[sams-gleb]

Basically just move the string method onto BasePipeline class as params could be used in the scripted pipeline, not only in declarative

[nre-ableton]

Nice, thanks for the fix.

[reinholdfuereder]

@nre-ableton I think the approach from #298 (comment) for "stringInterceptor" in combination with "parameters" and "withCredentials" steps (both having nested "string" steps) would be superior:

https://github.com/reinholdfuereder/JenkinsPipelineUnit/tree/parameters

• string parameter: reinholdfuereder@0858999
• string parameter AND credential: reinholdfuereder@d77d261

[nre-ableton]

@reinholdfeurerder I really have no idea what is going on in #298, which is why I didn't review it. In general, I'm not familiar with declarative pipelines, so I tend to stay away from that part of the codebase.

However, that PR doesn't make clear what the problem is nor why this is a good solution.

If you would like to submit a new PR with a similar solution that can better communicate the situation, I'd be happy to review it.

[reinholdfuereder]

After starting with a new branch for a new PR I must admit that I re-evaluated the situation and must admit that I have to revoke my claim:

• the advantage I had thought was superior is also a disadvantage, because the "parameters" element than contains duplicates of all the actual parameters (that are in the callstack right above)
  • in the following screenshot on the left my special overriding of "string" interceptor (and non-default "parameters" interceptor); and on the right after reverting them and using default "string" interceptor of Jenkins Pipeline Unit v1.14 (plus an additional default "parameters" interceptor => Support "parameters" in scripted pipeline job #495 with that and some new unit tests)