Unify script/steps approach

[michaelsauter]

MRO used an interface, IPipelineSteps, the ODS lib used duck-typing. Both works, but we should use just one approach. Previously I thought that the interface approach would not work for e.g. withCredentials as that writes variables to the "script", but, one can also read those variables via env, which is anyway cleaner.

FYI @renedupont

[metmajer]

@michaelsauter @clemensutschig note that @martsec is an architect in my team who needs to be included in concerting these refactorings. Otherwise, our team needs to play catch up with you. If I remember our strategy correctly, we wanted to keep shared library merging simple for the time being to not disrupt teams. This is a shared code-base with shared responsibilities. Let's tackle this together. Cheers!

[clemensutschig]

That one i leave anyway... the Base Services are enough work.

[metmajer]

@clemensutschig I was hoping that I would not need to apply the above demand to all other refactoring tasks. It was. of course, meant to cover all refactoring aspects that touch code my teams are directly depending on in their daily work.

[michaelsauter]

@metmajer I need to work on this ticket this week. Otherwise I cannot really unify the OpenShiftService, and not doing that does not make any sense when I need to implement deployment of OpenShift Templates for the component pipeline (a feature I wanted to do for a long time and promised for v3).

We did agree to make the initial merge as-is, which is what I did. Of course, over time it makes sense to unify the services. I did ask your team if / what they wanted to help but did not see any claims on GitHub issues. I would suggest to make any work that is ongoing visible here. Right now it looks to me like no work on the orchestration part is in progress.

But back to the issue here: I think the good news is that my plan for this ticket is to just adopt the PipelineSteps approach of the orchestration pipeline across the whole shared lib. So the only thing that affects the orchestration part is a move from PipelineSteps to another package.

I'm fine with someone else doing that - but I'd pretty much need a responsible with a delivery date to make that work realistically?