Closed ruromero closed 6 years ago
In the end, it is just YAML. If you can use anchors and aliases to construct valid YAML, then it shouldn't be a problem. I'm not sure what we could do to improve on this.
@djzager Indeed I don't see how this could be possible with the current model and without any pre-processing. Anchors and aliases don't allow adding elements to lists.
Maybe defining all the possible parameters as aliases and then just overriding things like required
or display_group
would reduce the errors and the duplicated code. What do you think?
# External Maven Repository
_apb_maven_repo_url: &_apb_maven_repo_url
name: apb_maven_repo_url
title: Maven Repository URL
description: External Maven Repository URL. Leave empty to use the repository provided by Business Central
required: false
type: string
display_group: External Maven Repository
_apb_maven_repo_user: &_apb_maven_repo_user
name: apb_maven_repo_user
title: Maven Repository Username
description: Username to use to interact with the external Maven repository.
required: false
type: string
display_group: External Maven Repository
_apb_maven_repo_pwd: &_apb_maven_repo_pwd
name: apb_maven_repo_pwd
title: Maven Repository Password
description: Password to use to interact with the external Maven repository.
required: false
type: string
display_type: password
display_group: External Maven Repository
...
parameters:
# External Maven Repository
- <<: *_apb_maven_repo_url
required: true
- *_apb_maven_repo_user
- *_apb_maven_repo_pwd
After working on some APBs I found quite error prone and difficult to maintain the fact that is not possible to aggregate different sets of parameters in multiple plans.
Given the following plans with parameters:
This setup forces the developer to duplicate all the parameter definitions. In some of my cases this can get up to 4 different plans and over 30 parameters.
It would be great to have something of this sort: