due to wrong indentation in the md file the excpetions are not rendered as expected. The reasons
why an exception occures is on the same level like the exception, but should have only level more.
The config map prepared by ConfigHelper is a mix from several configuration levels. The lowest config level
(DefaultValueCache) is shared between several ConfigHelper invocations. In case a Map or Collection which is
inherited from the DefaultValueCache level gets modified, this is also visible for all subsequent steps. This
causes trouble and situation which are hard to debug.
With this change here each invocation of ConfigHelper.use() provides a deep defensive copy. With that we can
ensure that there is no configuration update from one step to another.
In case there is a @see tag provided for a parameter in the description,
the possible values are only fetched from the corresponding source in
case there is no explict value provided for the possible values.
In case the source does not contain a possible value tag nothing is
transfered.
The old name (Build & Deploy) is missleading since the documentation is not deployed in most of the cases.
Deployment happens only if we are one the master branch. The waste majority of the build happens on
pull request branches. In this case there is no deployment.
In the meantime we check earlier if the deployable exists. Up to now the test used that late check. Now, as that
check happens earlier in the code we have to tune here. Now we assume a failure inside neo deploy instead.
When dealing with stashes in dockerExecuteOnKubernetes the global
stash list was updated from the step. This resulted in stashes
transported between the steps, which in turn resulted in having
old stashes unstashed in a pod later down the build. E.g.: mtaBuild
followed by neoDeploy: mtaBuild created a stash, the stash was
rememebered in the default stash list and re-used later on by
neoDeploy. Since the stash was created before the mtaBuild the
deployable was missing in the step.
Up to now the presence of the deployable (source) was checked late
by the NeoCommandLineHelper. The code doing this is surrounded by
the try/catch which finally also puts the log written by the neo
toolset into the job log in case an exception occured.
The check for the deployable returns with the same type of
exception like a failed neo command. Hence we cannot distiguish (ok,
would be possible to parse the exception message, but that is ugly).
When the exception is triggered by the missing deployable we try to
cat the neo log into the job log. But at this point the neo log has
not been provided - neo has not been called at all in this case.
Hence `cat logs/neo/*` in turn fails.
In order to avoid such a failure we check now for the presence of the
deployable earlier before launching the neo toolset.
Since the deployable is used in any deploy mode case no further check
for the deploy mode is required prior to the check for the deployable.
We have the case that one piper step calls other piper steps.
In such cases we would like to get all the plugin calls. The direct
calls but also the calls performed by nested piper-lib step calls.
The plugin calls as we registed them during listing to the tests are
resolved with the script provided by this commit.
Before the test we remmber which test is currently running.
During the test we collect all the calls to steps.
Beside that we persist the names of all steps within this shared
lib itself.
After the test(s) we write a corresponding json file. In fact we
write the file after each test, which is too often. But since we
don't know which test is the last test we can't do better.
The resulting file can be used later on for resolving the plugins
contributing the particular steps.
With that we are able to create a list of required plugins for each
step.
from property dockerImage we cannot conclude that we are in fact running inside a docker environment.
Step dockerExecute has some checks if we are in a docker context. If not there is a fallback to the
local environment.
The docker image property is provided from resources/default_pipeline_environment (value: 's4sdk/docker-neo-cli').
Hence a value will be present all the time (exception: someone configured null/ empty string explicitly). So we
will enter the corresponding code block anyway.
It is IMO also desirable to have the neo log in the job log when running inside a non-docker setup since this
simplifies troubleshooting anyway.
Before the test we remmber which test is currently running.
During the test we collect all the calls to steps.
Beside that we persist the names of all steps within this shared
lib itself.
After the test(s) we write a corresponding json file. In fact we
write the file after each test, which is too often. But since we
don't know which test is the last test we can't do better.
The resulting file can be used later on for resolving the plugins
contributing the particular steps.
With that we are able to create a list of required plugins for each
step.
* Fix sanity checks for warPropertiesFile deploy mode.
* improve tests for the sanity checks
The sanity checks are performed per deploy mode.
All parameters are checked at once.
* Explict check for host, account not found by sanity checks for deploy mode war properties
was removed since parameter keys does not appear anymore in the table denoting the
level where a parameter can be configured.
Nevertheless we need to take that parameter into account. We need to add the description for
that parameter, even if it cannot be configured on general or stage level.
Marcus Holl
