This approach works also in case we are in a subdirectory of the git repo,
e.g. in the closure of a dir statement.
The decission is delegate to git rather than using internal knowledge
about git file names. Well, the directory will be always named '.git',
but nevertheless ...
May endup in a false positive in case we did not clone a repo AND there
is another git repo somewhere upwards in the file system. Maybe some
other git repo is located upstairs containing e.g. the jenkins setup.
The advantage of working also for subdirectories outweights the disadvantage
for the false positive. It is not likely that we have to deal with another
git repo upstairs, since the pipeline script is expected to be located in
the payload git repo. A phantom repo upstairs looks like a pure academical
discussion.
* Make commit of new version optional in `artifactSetVersion` step
You might not want to add a new commit for each version, when versions
are automatically created. This commit makes this feature optional, but
enabled by default to maintain API compatibility.
* Set `gitCommitId` if null
* Improve documentation of `commitVersion` parameter
* Allow to operate in a code checkout without `.git` directory
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.
The folder com.sap.piper was created and the corresponding test classes
were not moved. Furthermore, a new UtilsTest class was created when this
test class did already exist, and the same tests were already
implemented, also this new test class uses the lesfurets testing
framework when it is not needed, so this new test class is removed and
the test class that there was before is kept.
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).
