mirror of
https://github.com/SAP/jenkins-library.git
synced 2024-12-14 11:03:09 +02:00
f3f221ee80
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.
|
||
|---|---|---|
| .. | ||
| testdata/TestProcessMetaFiles | ||
| goUtils.go | ||
| helper_test.go | ||
| helper.go | ||
| piper-context-defaults.yaml | ||
| resources_test.go | ||
| resources.go | ||