read yaml rule is a very frequently used rule. But having the rule in the common rules
means we cannot register text or files to that rule, which makes it less handy to work
with yaml files in the tests.
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.
Instead of configuring the credentials setup
o withCredentials
o usename
in each of our tests (for the moment change-management related)
we collect the common coding in a JUnitRule.
registerAllowedMethod for sh call not used anymore since we mock the ChangeManagement utils class.
The sh calls was triggered from the utils class. Since we mock that class, there is no sh call
anymore.
- 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.
