* Remove --backend-type
* Delete CTS in isChangeDevelopment and change Dockerimage of CM-Client
* fix groovy unit tests
* another fix of groovy unit tests
* try to fix import of fork for Jenkins-Testing
* add workflow to create Go Binary for Jenkins-Server
* Change RepoOwner to test in Fork
* remove previous changes
* adjust docker image for TransportRequestCreate and Release
* Remove CTS from Documentation
Co-authored-by: Thorsten Duda <thorsten.duda@sap.com>
* do not swallow exception triggered inside SWA handling
--> write it to the log
The real change is in src/com/sap/piper/Utils.groovy
All the changes in the tests are dealing with mocking the echo method
used in the Utils class mentioned above.
since now handlePipelineStepError does not return anything anymore we need to put the
corresponding return statement inside createTransportRequest outside the handlinePipelineStepError
closure.
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.
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.
- 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.
