Object file parameter

[kichristensen]

What does this change

This change adds support for loading object-type parameters from JSON files using the @ prefix syntax. When passing object parameters via CLI or parameter sets, users can now reference an external JSON file instead of providing inline JSON.

Example usage:

# Install with object parameter from file
porter install --param [email protected]

# Upgrade with object parameter from file
porter upgrade --param [email protected]

# Use with parameter sets
porter install --parameter-set myparam

Where a parameter set might contain:

parameters:
  - name: config
    source:
      value: "@/path/to/config.json"

Key features:

• Only works for parameters defined with type: object in the bundle
• Validates that the file contains valid JSON before processing
• Works with both --param CLI flags and parameter set value sources
• Security: Only applies to user-provided values, not default values in bundle definitions
• Provides clear error messages when files are not found or contain invalid JSON

What issue does it fix

Closes #3257

Notes for the reviewer

• The @ prefix logic is implemented in pkg/porter/parameters.go:getUnconvertedValueFromRaw()
• Security consideration: The @ prefix only works for user-provided parameter values (CLI/parameter sets), not for default values defined in bundle manifests, preventing potential security issues with malicious bundles
• The implementation validates JSON syntax immediately after reading the file to provide clear error messages
• Non-object parameters ignore the @ prefix, treating it as a literal string value for backward compatibility

Checklist

• Did you write tests?
• Did you write documentation?
• Did you change porter.yaml or a storage document record? Update the corresponding schema file.
• If this is your first pull request, please add your name to the bottom of our Contributors list. Thank you for making Porter better! 🙇‍♀️

[lbergnehr]

In parameter sets, there's source.path in the reference documentation. Would it make sense to use that in parameter sets, where we have that ability to make the distinction? I like the @ notation as it's commonly used elsewhere on the CLI (e.g. curl).

[dgannon991]

LGTM, and the comments for why it's safe were useful, cheers!

[kichristensen]

In parameter sets, there's source.path in the reference documentation. Would it make sense to use that in parameter sets, where we have that ability to make the distinction? I like the @ notation as it's commonly used elsewhere on the CLI (e.g. curl).

That is a really good point. It might already work I will check

[kichristensen]

@lbergnehr It already works, I will update the documentation to show that configuration

[kichristensen]

@dgannon991 @lbergnehr I have update the documentation to how to use path source when using parameter sets, instead of the @ way. The @ syntax will also work in parameter sets, but path is a much better way when using parameter sets