* Avoid CPS serialization issue in setupCPE
When handing over an instance of SCMInfo we got a
CPS serialization issue. Hence we don't hand over
that instance any more
o git commit id is resolved with exising git tooling
o git branch is handed over as parameter to setupCPE
* Move setting git info in cpe
Everything cpe related should be done in setupCommonPipelineEnvironment.
Thus a new parameter was introduced to accept the scmInfo object
returned by a checkout.
* Improve documentation
* 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.
* Add parameter "--ignoreCustomDefaults"
* Pass to piper customDefaults from config also via --defaultConfig
... and add "--ignoreCustomDefaults".
* Log output when ignoring customDefaults
Co-authored-by: Daniel Kurzynski <daniel.kurzynski@sap.com>
This change enables the setupCommonPipelineEnvironment step to handle
custom default configurations defined in customDefaults parameter of the
project configuration.
Previously, only the getConfig Go step was able to incorporate custom
default configurations.
Update documentation on custom defaults and sharing between projects.
Co-authored-by: Stephan Aßmus <stephan.assmus@sap.com>
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.
Starting point for that refactoring: it turned out that the tests
was not independent. The DefaultValueCache which is a singleton
keeps the status over various tests. Success of test execution depends
on the order test execution.
We have now
* a dedicated rule for resetting the default value cache
* JenkinsConfiguration rule (which already provided facilities for
dealing with the configuration) has been replaced by a readYaml rule.
From the PipelineUnit test framework we get already a handler for
libraryResource, which is also part of the setup of the default
values.
* An auxiliar class which combines the
* JenkinsSetupRule (registers the lib)
* JenkinsReadYamlRule (provides facilities for Yaml parsing)
* JenkinsResetDefaultValueCacheRule (cleans up the DefaultValueCache)
into a rule chain. By using this rule chain we ensure that our
setup OK (piper lib registered, and default config can be setup in
a clean way).
