`piperExecuteBin` is called with a credentials list. Each list entry is a map consisting of
* the type of the credential (e.g. usernamePassword, token)
* the identifier which is used for resolving the credential.
* a list of environment variables which holds the resolved credentials.
Inside `piperExecuteBin` the id was resolved against the config and the result was used for resolving the credentials against the jenkins-credentials-plugin.
With this change here we introduce another key for the map mentioned above:
* resolveCredentialsId
When this key is provided with value `false` we do not resolve the credentials-id from the config. In that case the id is directly used for resolving the credential again the jenkins-credentials-plugin.
* Upload in Chunks
* fix unit tests for file upload in chunks
* upload in chunks review round 1
* Upload in Chunks - review round 2 - comments
Co-authored-by: Daniel Mieg <56156797+DanielMieg@users.noreply.github.com>
* Add message parameter to pipelineRestart to make error messages user friendly
* Update the parameter to the correct name
Co-authored-by: Oliver Nocon <33484802+OliverNocon@users.noreply.github.com>
Test verifies that correct pom.xml is used as provided in the parameters
Also removed the --file pom.xml in the tests as maven should take pom.xml as default
Up to now the code generator is not able to handle the type
map[string]interface{} which is important for nested
configurations.
With that change we support such nested configuration.
Fo now parameters with a map type are not supported via
command line parameters. Those parameters are simply
ommitted. But with this change is it possible to read
such nested structures from the pipeline configuration
(.pipeline/config.yml).
As a next step we can discuss if we would like to support
such values also via command line parameters. One possible
approach could be
```
./piper <command> -myParam key1=val1 --myParam key2=val2
```
which gets finally collected inside our map:
```
map["key1"] = "val1"
map["key2"] = "val2"
```
This is of course hard to do for deeper nestings. In that case
providing a pointer to a file might be more suitable.
In that context we need to consider how to
- declare the default values for map like parameters in our
metadata files.
- deal with the different types we have for the parameter
itself wrt the yaml like config on the one hand and on the
level of the command line parameters on the other hand. Maybe for
that we have to extend the metadata format (e.g. describe an
alternate type receiving the values from the command line, like
[]string. With that approach values for simple nested (... not deep
nested) params can be provided like described above, it would be
possible to represent these parameters for the command line parser
as string slice entries like "[]string{key1=val1, key2=val2". These
parameters needs in this case transformed "by us" into the map we
use further down the road.
In case we agree in principle on an approach as outlined here we should
adjust the golden files reflecting this use case.
* wrap all in docker.withRegistry()
* Renamed parameter
No backwards alias, since it never worked before.
* Fix code and tests
* Rename parameter as per review
* Rename parameter as per review
Co-authored-by: Daniel Kurzynski <daniel.kurzynski@sap.com>
