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. |
||
---|---|---|
.. | ||
helper | ||
step-metadata.go |