Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Parameter sets value only supports string type #3331

Open
lbergnehr opened this issue Feb 6, 2025 · 0 comments
Open

Parameter sets value only supports string type #3331

lbergnehr opened this issue Feb 6, 2025 · 0 comments
Labels
suggestion Idea for maintainers to consider. Do not take this issue until triaged.

Comments

@lbergnehr
Copy link
Contributor

Is your feature request related to a problem? Please describe.
If a bundle takes a parameter that is not a string type, e.g. object or integer, that is the type that should be possible to enter in the parameter set definition. Currently, the value gets blanked out if the type is anything else than a string.

That being said, if the value is "converted" to a string, e.g. creating a string json representation, then it still works as a parameter since Porter will convert it when setting the parameter on the bundle. This is not very intuitive though, especially when dealing with numbers, which are likely to get entered verbatim (without quotes) and thus will get blanked out.

Describe the solution you'd like
Support any type supported by Porter parameters in the value property of a parameter in parameter sets, for example:

...
schemaType: ParameterSet
schemaVersion: 1.0.1
namespace: ""
name: omni-overlord-hive-ohive
parameters:
  - name: some-object
    source:
      value:
          some-prop: 1
status:
  created: "0001-01-01T00:00:00Z"
  modified: "2025-02-05T15:20:52.633252075+01:00"

In the example above, the object set to value is an object with a property some-prop.

Currently, the workaround to this is setting the value like this:

...
  - name: some-object
    source:
      value: |
          { "some-prop": 1 }
...

Describe alternatives you've considered
I think the implementation could be as simple as converting the value objects to strings in the code, which would not require a lot of refactoring since the string type would be type same in the rest of the code.

A better, but more involved way, might be to actually treat the value as any type in all related parts of the code.

@lbergnehr lbergnehr added the suggestion Idea for maintainers to consider. Do not take this issue until triaged. label Feb 6, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
suggestion Idea for maintainers to consider. Do not take this issue until triaged.
Projects
None yet
Development

No branches or pull requests

1 participant