This allows the steps to interact without using return values (which is not possible in
declarative pipelines). On the other hand we have depencencies between the steps based
on the status of the commonPipelineEnvironment.
changeId is removed from the step parameters since the changeId
is specific to the build. Hence there is no reason for providing
it from the deeper configuration layers.
- In case a parameter is missing we do not thrown and AbortException
anmore, but an IllegalArgumentExcpetion, since that exception is
thrown by the configuration helper. The difference is: AbortExceptions
are contained in the log without stacktrace, other exceptions are
printed with stack trace.
- Exception messages are changed to the standard error message triggered
inside the configuration helper. In case the changeDocumentId is
retrieved also from the commit history we keep an exception message
pointing to that.
- Having references to the parameters is droped. Instead the parameters
are directly used from the configuration map.
- in case of long signatures line breaks are inserted in order to
simplify reading the code.
the official term in SAP-SolutionManager is 'change document'.
The term 'change' as reflected in 'changeId' is ambigous and could also be understand in the
sense of a change in a revision control system.
Choosing appropriate terms for parameters here deceases the amount of documentation
required for explaining what is really denoted by the parameter.
