- don't log a message and continue when it is clear that we cannot succeed
together with error raised later during attempt not parse a non-existing
file
- More log output in order to clarify what happens with mta.yaml
We can now registering files to JenkinsReadYamlRule by
providing the file name alongside with the expected content
(or e.g. an expception)
With that change it is possible to remove pwd statements
from mtaBuild. These statements was used in order to pass
a temporary directory inside the mtaBuild (code under test).
This is not needed anymore since we can register the files
directly.
Having pwd implies working with absolute pathes which is
also a no-go when working with docker, since the absolute
pathes inside and outside docker are normally not the same.
For pathes relative to a build root directory it is rather
easy to keep the pathes consistent the same.
Adjust sources according to registering yaml file to jenkins rule.
For mtaBuild this means also: get ride of absolute pathes for denoting the yaml file.
Having absolute pathes makes it difficult/impossible to work also with dockerized versions
of mtaBuild since the absolute pathes are most probably not the same inside and outside
the docker container, but the relatives pathes can be kept the same easily.
We know about two issues:
1.) groovy based file systems checks seems to be executed on Jenkins
master even if there is a node which is dispatched to a slave.
2.) Environment variable contained in the value of a provided
variable are not expanded. Example: In case we describe neoHome like
"$JENKINS_HOME/tools/neo" we do not expand $JENKINS_HOME. Hence the
file exists check for file '$JENKINS_HOME/tools/neo' fails.
The characteristics of a list are
o the order of the entries is significant
o duplicates are allowed
The characteristics of a set are
o the order is not significant
o duplicates are not allowed.
When describing keys for a step the characteristics of a
set applies here, whereas the characteristics of a list does
not apply.
