You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm wondering if a porter parameters generate command would be useful? Similar in functionality to porter credentials generate, it would interactively iterate through all of the parameter definitions in bundle, receiving input from the user to populate each parameter's value (supplying the default if it exists, so user can enter through if one is already set) and then create a params file as can currently be consumed via a porter install|uninstall|upgrade|invoke command.
At the minimum, it could support only receiving each param value directly (or using the bundle default, as mentioned.) We could also explore offering options to look up the value from another source, say a filepath or env var, on the user's local system. It would then look each up and enter the corresponding value into the params file.
We might also consider, most likely in a follow-up if this issue gains traction, creating a parameters sub-directory under Porter's home to store the resulting parameters file for a bundle (another correlate to the credentials files currently stored under the credentials sub-directory). Then, if only the name of an existing parameters file is supplied on the action (i.e., porter install --param-file mybuns), Porter would know where to look first for said file.
The text was updated successfully, but these errors were encountered:
I'm wondering if a
porter parameters generate
command would be useful? Similar in functionality toporter credentials generate
, it would interactively iterate through all of the parameter definitions in bundle, receiving input from the user to populate each parameter's value (supplying the default if it exists, so user can enter through if one is already set) and then create a params file as can currently be consumed via aporter install|uninstall|upgrade|invoke
command.At the minimum, it could support only receiving each param value directly (or using the bundle default, as mentioned.) We could also explore offering options to look up the value from another source, say a filepath or env var, on the user's local system. It would then look each up and enter the corresponding value into the params file.
We might also consider, most likely in a follow-up if this issue gains traction, creating a
parameters
sub-directory under Porter's home to store the resulting parameters file for a bundle (another correlate to the credentials files currently stored under thecredentials
sub-directory). Then, if only the name of an existing parameters file is supplied on the action (i.e.,porter install --param-file mybuns
), Porter would know where to look first for said file.The text was updated successfully, but these errors were encountered: