From 319e0a0bc310696d491c710cdad427b2f57972a7 Mon Sep 17 00:00:00 2001 From: Benoit Tigeot Date: Wed, 8 Oct 2025 21:21:58 +0200 Subject: [PATCH 1/9] Add proposal for schema validation with external dependencies Related: - https://github.com/helm/helm/pull/31240 - https://github.com/helm/helm/pull/31240#issuecomment-3254589775 Signed-off-by: Benoit Tigeot --- hips/hip-9999.md | 75 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 75 insertions(+) create mode 100644 hips/hip-9999.md diff --git a/hips/hip-9999.md b/hips/hip-9999.md new file mode 100644 index 00000000..22a066a5 --- /dev/null +++ b/hips/hip-9999.md @@ -0,0 +1,75 @@ +--- +hip: 9999 +title: "Schema Validation with External Dependencies" +authors: [ "Benoit Tigeot " ] +created: "2025-10-08" +type: "feature" +status: "draft" +--- + +## Abstract + +A recent change in Helm's JSON schema validation library (see issue helm/helm#31170) has made schema validation stricter, causing failures when schemas contain unresolvable URN or URL references. While the immediate issue can be addressed by making the compiler less strict, it highlights a need for a formal mechanism to resolve schema references within a chart. As discussed during Dev meeting Helm V4 should be stricter on this part. This proposal introduces a method for `values.schema.json` to reference external JSON schema files located within the chart. It suggests the creation of a new file, `schema-dependencies.json`, in the chart's root directory. This file will define mappings from URL prefixes to local chart paths, enabling schema reuse and better organization. This provides a robust, long-term solution for managing schema dependencies. + +## Motivation + +Currently, `values.schema.json` is self-contained, which limits the ability to reuse common schema definitions across multiple charts. For instance, an organization may have a standard definition for a "CPU" or "memory" resource that they want to use in all of their charts. Without the ability to reference external schemas, chart authors are forced to duplicate these definitions in every chart, leading to inconsistencies and maintenance overhead. + +This proposal solves this problem by providing a mechanism to reference external schemas, making it easier to create and maintain complex charts with shared schema definitions. + +## Rationale + +The primary design goal is to keep schema validation logic, which is optional, separate from the core chart metadata in `Chart.yaml`. A file-based approach provides a clean separation of concerns. + +Several approaches were considered: + +1. **Convention-based `schemas` directory**: This approach, while simple, was deemed too implicit and less flexible than an explicit mapping file. + +2. **`schema-dependencies.json` file**: This approach was chosen as it provides an explicit, flexible, and decoupled way to manage schema dependencies. It is easy to understand and does not clutter `Chart.yaml`. + +## Specification + +A new file named `schema-dependencies.json` will be recognized in the root of a chart. This file will contain a JSON object that maps URL prefixes to local paths within the chart. + +**Example `schema-dependencies.json`:** +```json +{ + "my-org-schemas": "schema_definitions/", + "common-definitions": "common/definitions.json" +} +``` + +When this file is present, Helm will parse it before performing schema validation. The mappings will be used to configure the `jsonschema` compiler, allowing it to resolve `$ref` values that use the defined prefixes. + +For example, with the mappings above: +- A `$ref` of `"my-org-schemas/common.json#/definitions/cpu"` would resolve to the file `schema_definitions/common.json`. +- A `$ref` of `"common-definitions#/definitions/memory"` would resolve to the file `common/definitions.json`. + +## Backwards compatibility + +This is a breaking change in v4. Charts with `values.schema.json` with external requirements but without a `schema-dependencies.json` file will return an error. + +## Security implications + +To prevent security risks, such as accessing arbitrary files on the filesystem, the paths in `schema-dependencies.json` must be relative and will be constrained to the chart's directory. Any path attempting to traverse outside the chart (e.g., `../...`) will be rejected. + +## How to teach this + +The Helm documentation will be updated to describe the `schema-dependencies.json` file, its format, and how to use it to reference external schemas in `values.schema.json`. Examples will be provided to illustrate its usage. + +## Reference implementation + +No reference implementation exists yet. On should be proposed before the draft is accepted. + +## Rejected ideas + +- **Convention-based `schemas` directory**: This idea was rejected in favor of a more explicit and flexible mapping file. + +## Open issues + +- https://github.com/helm/helm/issues/31170 + +## References + +- [santhosh-tekuri/jsonschema](https://github.com/santhosh-tekuri/jsonschema) +- [silencing schema loading error](https://github.com/helm/helm/pull/31240) From 84b8aab678189df1bfad690b26e2afc00bceb2d5 Mon Sep 17 00:00:00 2001 From: Benoit Tigeot Date: Wed, 8 Oct 2025 21:35:38 +0200 Subject: [PATCH 2/9] Add implementation detail proposal Signed-off-by: Benoit Tigeot --- hips/hip-9999.md | 16 +++++++++++++--- 1 file changed, 13 insertions(+), 3 deletions(-) diff --git a/hips/hip-9999.md b/hips/hip-9999.md index 22a066a5..24b16994 100644 --- a/hips/hip-9999.md +++ b/hips/hip-9999.md @@ -25,7 +25,7 @@ Several approaches were considered: 1. **Convention-based `schemas` directory**: This approach, while simple, was deemed too implicit and less flexible than an explicit mapping file. -2. **`schema-dependencies.json` file**: This approach was chosen as it provides an explicit, flexible, and decoupled way to manage schema dependencies. It is easy to understand and does not clutter `Chart.yaml`. +2. **`schema-dependencies.json` file**: This approach was chosen as it provides an explicit, flexible, and decoupled way to manage schema dependencies. It permit referencing remote additional definition too. ## Specification @@ -34,7 +34,6 @@ A new file named `schema-dependencies.json` will be recognized in the root of a **Example `schema-dependencies.json`:** ```json { - "my-org-schemas": "schema_definitions/", "common-definitions": "common/definitions.json" } ``` @@ -42,7 +41,6 @@ A new file named `schema-dependencies.json` will be recognized in the root of a When this file is present, Helm will parse it before performing schema validation. The mappings will be used to configure the `jsonschema` compiler, allowing it to resolve `$ref` values that use the defined prefixes. For example, with the mappings above: -- A `$ref` of `"my-org-schemas/common.json#/definitions/cpu"` would resolve to the file `schema_definitions/common.json`. - A `$ref` of `"common-definitions#/definitions/memory"` would resolve to the file `common/definitions.json`. ## Backwards compatibility @@ -61,6 +59,18 @@ The Helm documentation will be updated to describe the `schema-dependencies.json No reference implementation exists yet. On should be proposed before the draft is accepted. +## Implementation Strategy + +The implementation can be localized within the Helm codebase by leveraging the intended extension points of the `jsonschema` library. + +1. **The `jsonschema` Library Supports It**: The `jsonschema` library is designed to be extensible with custom loaders. The library's own command-line tool uses a custom loader to implement its `--map` functionality, which is conceptually identical to what the `schema-dependencies.json` file proposes. We would be using the library as intended. + +2. **Minimal Changes to Helm**: The implementation would be localized almost entirely within Helm's `pkg/chart/common/util/jsonschema.go` file. The logic would be: + * Before compiling the schema, check for `schema-dependencies.json`. + * If it exists, parse the mappings. + * Create a new custom loader that checks for mapped prefixes and, if a match is found, loads the corresponding local file. If not, it falls back to the default behavior. + * Pass this new loader to the `jsonschema.Compiler`. + ## Rejected ideas - **Convention-based `schemas` directory**: This idea was rejected in favor of a more explicit and flexible mapping file. From 0f18acac02411e0b2fdb8bc125a84be99601f761 Mon Sep 17 00:00:00 2001 From: Benoit Tigeot Date: Wed, 8 Oct 2025 21:37:55 +0200 Subject: [PATCH 3/9] Do not support authentication yet Signed-off-by: Benoit Tigeot --- hips/hip-9999.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/hips/hip-9999.md b/hips/hip-9999.md index 24b16994..f6f2765f 100644 --- a/hips/hip-9999.md +++ b/hips/hip-9999.md @@ -51,6 +51,8 @@ This is a breaking change in v4. Charts with `values.schema.json` with external To prevent security risks, such as accessing arbitrary files on the filesystem, the paths in `schema-dependencies.json` must be relative and will be constrained to the chart's directory. Any path attempting to traverse outside the chart (e.g., `../...`) will be rejected. +Additionally, while schemas can still be fetched from accessible remote URLs via HTTP/S, the initial implementation of this feature will not support authentication for these remote endpoints. Fetching from private or authenticated sources is out of scope for this proposal and could be considered in the future. + ## How to teach this The Helm documentation will be updated to describe the `schema-dependencies.json` file, its format, and how to use it to reference external schemas in `values.schema.json`. Examples will be provided to illustrate its usage. From fee2e8eee7e11fd76b6f4a43b70471e94fb5bf75 Mon Sep 17 00:00:00 2001 From: Benoit Tigeot Date: Wed, 8 Oct 2025 21:58:08 +0200 Subject: [PATCH 4/9] Rephrasing and add example for a potential remote capability Signed-off-by: Benoit Tigeot --- hips/hip-9999.md | 55 ++++++++++++++++++++++++++++++++++++------------ 1 file changed, 41 insertions(+), 14 deletions(-) diff --git a/hips/hip-9999.md b/hips/hip-9999.md index f6f2765f..99458f5c 100644 --- a/hips/hip-9999.md +++ b/hips/hip-9999.md @@ -9,7 +9,7 @@ status: "draft" ## Abstract -A recent change in Helm's JSON schema validation library (see issue helm/helm#31170) has made schema validation stricter, causing failures when schemas contain unresolvable URN or URL references. While the immediate issue can be addressed by making the compiler less strict, it highlights a need for a formal mechanism to resolve schema references within a chart. As discussed during Dev meeting Helm V4 should be stricter on this part. This proposal introduces a method for `values.schema.json` to reference external JSON schema files located within the chart. It suggests the creation of a new file, `schema-dependencies.json`, in the chart's root directory. This file will define mappings from URL prefixes to local chart paths, enabling schema reuse and better organization. This provides a robust, long-term solution for managing schema dependencies. +A recent change in Helm's JSON schema validation library (see issue helm/helm#31170) has made schema validation stricter, causing failures when schemas contain unresolvable URN or URL references. While the immediate issue can be addressed by making the compiler less strict, it highlights a need for a formal mechanism that allows `values.schema.json` to reference other schemas. In line with discussions for Helm v4, the goal is to enforce stricter schema validation. This proposal introduces a method for `values.schema.json` to reference other JSON schema files. It suggests the creation of a new file, `schema-dependencies.json`, in the chart's root directory. This file will define mappings from URL prefixes to local chart paths, enabling schema reuse. ## Motivation @@ -19,33 +19,60 @@ This proposal solves this problem by providing a mechanism to reference external ## Rationale -The primary design goal is to keep schema validation logic, which is optional, separate from the core chart metadata in `Chart.yaml`. A file-based approach provides a clean separation of concerns. - Several approaches were considered: 1. **Convention-based `schemas` directory**: This approach, while simple, was deemed too implicit and less flexible than an explicit mapping file. -2. **`schema-dependencies.json` file**: This approach was chosen as it provides an explicit, flexible, and decoupled way to manage schema dependencies. It permit referencing remote additional definition too. +2. **`schema-dependencies.json` file**: This approach was chosen as it provides an explicit, flexible, and decoupled way to manage schema dependencies. It also permits referencing remote definitions. ## Specification -A new file named `schema-dependencies.json` will be recognized in the root of a chart. This file will contain a JSON object that maps URL prefixes to local paths within the chart. +A new file named `schema-dependencies.json` will be recognized in the root of a chart. This file will contain a JSON object that maps a URI prefix to a resolution target. This target can be either a relative path to a local file within the chart, or a full URL for a remote schema. + +This allows for aliasing both local and remote schemas. + +### Example + +**1. Define local and remote mappings:** + +The `schema-dependencies.json` file can define prefixes for both local paths and remote URLs. + +```json +// schema-dependencies.json +{ + "local-defs": "schemas/", + "k8s-api": "https://kubernetesjsonschema.dev/v1.28.2/_definitions.json" +} +``` + +**2. Use the prefixes in `values.schema.json`:** -**Example `schema-dependencies.json`:** ```json +// values.schema.json { - "common-definitions": "common/definitions.json" + "title": "My Chart Values", + "type": "object", + "properties": { + "resources": { + "$ref": "local-defs/resources.json#/definitions/resourceRequirements" + }, + "livenessProbe": { + "$ref": "k8s-api#/definitions/io.k8s.api.core.v1.Probe" + } + } } ``` -When this file is present, Helm will parse it before performing schema validation. The mappings will be used to configure the `jsonschema` compiler, allowing it to resolve `$ref` values that use the defined prefixes. +### Resolution -For example, with the mappings above: -- A `$ref` of `"common-definitions#/definitions/memory"` would resolve to the file `common/definitions.json`. +When Helm validates the schema, the custom loader will: +1. Check if a `$ref` value starts with a prefix defined in `schema-dependencies.json`. +2. If a match is found (e.g., `k8s-api`): It replaces the prefix with the mapped target. For a remote target, the result is a full URL (`https://...`) that is then fetched. For a local target, it resolves to a file within the chart. +3. If no prefix matches, Helm's default loader will attempt to resolve the `$ref` as-is (e.g., as a full URL). ## Backwards compatibility -This is a breaking change in v4. Charts with `values.schema.json` with external requirements but without a `schema-dependencies.json` file will return an error. +This is a breaking change in v4. In v4, charts that use `values.schema.json` to reference other schemas (e.g., via a `$ref` to a non-standard URI) without a corresponding `schema-dependencies.json` file will fail validation. ## Security implications @@ -59,18 +86,18 @@ The Helm documentation will be updated to describe the `schema-dependencies.json ## Reference implementation -No reference implementation exists yet. On should be proposed before the draft is accepted. +No reference implementation exists yet. One should be proposed before the draft is accepted. ## Implementation Strategy The implementation can be localized within the Helm codebase by leveraging the intended extension points of the `jsonschema` library. -1. **The `jsonschema` Library Supports It**: The `jsonschema` library is designed to be extensible with custom loaders. The library's own command-line tool uses a custom loader to implement its `--map` functionality, which is conceptually identical to what the `schema-dependencies.json` file proposes. We would be using the library as intended. +1. **The `jsonschema` Library Supports It**: The `jsonschema` library is designed to be extensible with custom loaders. The library's own command-line tool uses a custom loader to implement its `--map` functionality, which is conceptually identical to what the `schema-dependencies.json` file proposes. We would be using the library as intended. 2. **Minimal Changes to Helm**: The implementation would be localized almost entirely within Helm's `pkg/chart/common/util/jsonschema.go` file. The logic would be: * Before compiling the schema, check for `schema-dependencies.json`. * If it exists, parse the mappings. - * Create a new custom loader that checks for mapped prefixes and, if a match is found, loads the corresponding local file. If not, it falls back to the default behavior. + * Create a new custom loader that checks for mapped prefixes and, if a match is found, loads the corresponding local file. If no mapped prefix matches, Helm's default loader will then attempt to handle the URL (e.g., for standard `http(s)://` or `file://` references). * Pass this new loader to the `jsonschema.Compiler`. ## Rejected ideas From f45a4f8033d36aed565df1edbbff80d6098288ad Mon Sep 17 00:00:00 2001 From: Benoit Tigeot Date: Wed, 8 Oct 2025 21:58:35 +0200 Subject: [PATCH 5/9] Try to make clearer fall back mechanism Signed-off-by: Benoit Tigeot --- hips/hip-9999.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hips/hip-9999.md b/hips/hip-9999.md index 99458f5c..b65cc2b8 100644 --- a/hips/hip-9999.md +++ b/hips/hip-9999.md @@ -68,7 +68,7 @@ The `schema-dependencies.json` file can define prefixes for both local paths and When Helm validates the schema, the custom loader will: 1. Check if a `$ref` value starts with a prefix defined in `schema-dependencies.json`. 2. If a match is found (e.g., `k8s-api`): It replaces the prefix with the mapped target. For a remote target, the result is a full URL (`https://...`) that is then fetched. For a local target, it resolves to a file within the chart. -3. If no prefix matches, Helm's default loader will attempt to resolve the `$ref` as-is (e.g., as a full URL). +3. If no prefix matches, the `$ref` is passed to Helm's default loader. This allows you to use both your custom aliases and direct URLs (like `https://...`) in the same `values.schema.json` file without needing to create an alias for every remote schema. ## Backwards compatibility From 4cef423af51740bd695017824322f9b321874dbd Mon Sep 17 00:00:00 2001 From: Benoit Tigeot Date: Wed, 8 Oct 2025 23:53:55 +0200 Subject: [PATCH 6/9] Make implementation proposal a little bit clearer Signed-off-by: Benoit Tigeot --- hips/hip-9999.md | 18 ++++++++++++------ 1 file changed, 12 insertions(+), 6 deletions(-) diff --git a/hips/hip-9999.md b/hips/hip-9999.md index b65cc2b8..754067c7 100644 --- a/hips/hip-9999.md +++ b/hips/hip-9999.md @@ -90,14 +90,20 @@ No reference implementation exists yet. One should be proposed before the draft ## Implementation Strategy -The implementation can be localized within the Helm codebase by leveraging the intended extension points of the `jsonschema` library. -1. **The `jsonschema` Library Supports It**: The `jsonschema` library is designed to be extensible with custom loaders. The library's own command-line tool uses a custom loader to implement its `--map` functionality, which is conceptually identical to what the `schema-dependencies.json` file proposes. We would be using the library as intended. -2. **Minimal Changes to Helm**: The implementation would be localized almost entirely within Helm's `pkg/chart/common/util/jsonschema.go` file. The logic would be: - * Before compiling the schema, check for `schema-dependencies.json`. - * If it exists, parse the mappings. - * Create a new custom loader that checks for mapped prefixes and, if a match is found, loads the corresponding local file. If no mapped prefix matches, Helm's default loader will then attempt to handle the URL (e.g., for standard `http(s)://` or `file://` references). +The implementation can be localized within the Helm codebase by leveraging the intended extension points of the `jsonschema` library. The approach is inspired by the `--map` [functionality](https://github.com/santhosh-tekuri/jsonschema/commit/ed65924244c7fad4784aebfafcad7aa1ece6d2c2) in the library's own CLI, but would be more powerful. + +1. **Extending the Library's Loader Pattern**: The `jsonschema` library is designed to be extensible with custom loaders. Its CLI uses a custom loader to map URL prefixes to local directories. We will adopt and extend this pattern in Helm to create a loader that can map prefixes to **both local paths and remote URLs**. + +2. **Minimal Changes to Helm**: The implementation would be localized almost entirely within Helm's `pkg/chart/common/util/jsonschema.go` file. The logic for the new custom loader would be: + + * Before compiling the schema, check for `schema-dependencies.json` and parse the mappings. + * For each `$ref`, check if it starts with a mapped prefix. + * If it matches, inspect the corresponding target value from the mapping: + * If the target is a local path, resolve the file from within the chart. + * If the target is a remote URL (`https://...`), construct a new full URL for the schema and fetch it. + * If no prefix matches, Helm's default loader will then attempt to handle the URL. * Pass this new loader to the `jsonschema.Compiler`. ## Rejected ideas From caf94e641786c28da13b9e1242dcf0d316f64b73 Mon Sep 17 00:00:00 2001 From: Benoit Tigeot Date: Thu, 9 Oct 2025 12:05:03 +0200 Subject: [PATCH 7/9] Small tweaks to properly define that we are using schema and not chart Signed-off-by: Benoit Tigeot --- hips/hip-9999.md | 8 +++----- 1 file changed, 3 insertions(+), 5 deletions(-) diff --git a/hips/hip-9999.md b/hips/hip-9999.md index 754067c7..bff6e9c4 100644 --- a/hips/hip-9999.md +++ b/hips/hip-9999.md @@ -9,7 +9,7 @@ status: "draft" ## Abstract -A recent change in Helm's JSON schema validation library (see issue helm/helm#31170) has made schema validation stricter, causing failures when schemas contain unresolvable URN or URL references. While the immediate issue can be addressed by making the compiler less strict, it highlights a need for a formal mechanism that allows `values.schema.json` to reference other schemas. In line with discussions for Helm v4, the goal is to enforce stricter schema validation. This proposal introduces a method for `values.schema.json` to reference other JSON schema files. It suggests the creation of a new file, `schema-dependencies.json`, in the chart's root directory. This file will define mappings from URL prefixes to local chart paths, enabling schema reuse. +A recent change in Helm's JSON schema validation library (see issue helm/helm#31170) has made schema validation stricter, causing failures when schemas contain unresolvable URN or URL references. While the immediate issue can be addressed by making the compiler less strict, it highlights a need for a formal mechanism that allows `values.schema.json` to reference other schemas. In line with discussions for Helm v4, the goal is to enforce stricter schema validation. This proposal introduces a method for `values.schema.json` to reference other JSON schema files. It suggests the creation of a new file, `schema-dependencies.json`, in the chart's root directory to define the additional requirements. ## Motivation @@ -21,7 +21,7 @@ This proposal solves this problem by providing a mechanism to reference external Several approaches were considered: -1. **Convention-based `schemas` directory**: This approach, while simple, was deemed too implicit and less flexible than an explicit mapping file. +1. **Convention-based `schemas` directory**: This approach, while simple, was deemed too implicit and less flexible than an explicit mapping file. Also a folder only for validations doesn't the right approach. 2. **`schema-dependencies.json` file**: This approach was chosen as it provides an explicit, flexible, and decoupled way to manage schema dependencies. It also permits referencing remote definitions. @@ -76,7 +76,7 @@ This is a breaking change in v4. In v4, charts that use `values.schema.json` to ## Security implications -To prevent security risks, such as accessing arbitrary files on the filesystem, the paths in `schema-dependencies.json` must be relative and will be constrained to the chart's directory. Any path attempting to traverse outside the chart (e.g., `../...`) will be rejected. +To prevent security risks, such as accessing arbitrary files on the filesystem, the paths in `schema-dependencies.json` must be relative and will be constrained to the chart's directory. Any path attempting to traverse outside the chart will be rejected. Additionally, while schemas can still be fetched from accessible remote URLs via HTTP/S, the initial implementation of this feature will not support authentication for these remote endpoints. Fetching from private or authenticated sources is out of scope for this proposal and could be considered in the future. @@ -90,8 +90,6 @@ No reference implementation exists yet. One should be proposed before the draft ## Implementation Strategy - - The implementation can be localized within the Helm codebase by leveraging the intended extension points of the `jsonschema` library. The approach is inspired by the `--map` [functionality](https://github.com/santhosh-tekuri/jsonschema/commit/ed65924244c7fad4784aebfafcad7aa1ece6d2c2) in the library's own CLI, but would be more powerful. 1. **Extending the Library's Loader Pattern**: The `jsonschema` library is designed to be extensible with custom loaders. Its CLI uses a custom loader to map URL prefixes to local directories. We will adopt and extend this pattern in Helm to create a loader that can map prefixes to **both local paths and remote URLs**. From 2a729149b8b4d6dcb78b5f4fc26e5658679e7ee4 Mon Sep 17 00:00:00 2001 From: Benoit Tigeot Date: Thu, 9 Oct 2025 13:13:38 +0200 Subject: [PATCH 8/9] Add "Less strict" PR link Signed-off-by: Benoit Tigeot --- hips/hip-9999.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/hips/hip-9999.md b/hips/hip-9999.md index bff6e9c4..5c52c491 100644 --- a/hips/hip-9999.md +++ b/hips/hip-9999.md @@ -9,7 +9,7 @@ status: "draft" ## Abstract -A recent change in Helm's JSON schema validation library (see issue helm/helm#31170) has made schema validation stricter, causing failures when schemas contain unresolvable URN or URL references. While the immediate issue can be addressed by making the compiler less strict, it highlights a need for a formal mechanism that allows `values.schema.json` to reference other schemas. In line with discussions for Helm v4, the goal is to enforce stricter schema validation. This proposal introduces a method for `values.schema.json` to reference other JSON schema files. It suggests the creation of a new file, `schema-dependencies.json`, in the chart's root directory to define the additional requirements. +A recent change in Helm's JSON schema validation library (see issue helm/helm#31170) has made schema validation stricter, causing failures when schemas contain unresolvable URN or URL references. While the immediate issue can be addressed by [making the compiler less strict](https://github.com/helm/helm/issues/31170), it highlights a need for a formal mechanism that allows `values.schema.json` to reference other schemas. In line with discussions for Helm v4, the goal is to enforce stricter schema validation. This proposal introduces a method for `values.schema.json` to reference other JSON schema files. It suggests the creation of a new file, `schema-dependencies.json`, in the chart's root directory to define the additional requirements. ## Motivation From f7a57f98eee3b752352b930c81d5f2373eb5ae0f Mon Sep 17 00:00:00 2001 From: Benoit Tigeot Date: Sat, 11 Oct 2025 13:58:55 +0200 Subject: [PATCH 9/9] Minor correction on usage example Signed-off-by: Benoit Tigeot --- hips/hip-9999.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/hips/hip-9999.md b/hips/hip-9999.md index 5c52c491..48dbf4bc 100644 --- a/hips/hip-9999.md +++ b/hips/hip-9999.md @@ -13,7 +13,7 @@ A recent change in Helm's JSON schema validation library (see issue helm/helm#31 ## Motivation -Currently, `values.schema.json` is self-contained, which limits the ability to reuse common schema definitions across multiple charts. For instance, an organization may have a standard definition for a "CPU" or "memory" resource that they want to use in all of their charts. Without the ability to reference external schemas, chart authors are forced to duplicate these definitions in every chart, leading to inconsistencies and maintenance overhead. +Currently, `values.schema.json` is self-contained, which limits the ability to reuse common schema definitions across multiple charts. For instance, an organization may have a standard definition for a "CPU" or "Liveness Probes" resource that they want to use in all of their charts. Without the ability to reference external schemas, chart authors are forced to duplicate these definitions in every chart, leading to inconsistencies and maintenance overhead. This proposal solves this problem by providing a mechanism to reference external schemas, making it easier to create and maintain complex charts with shared schema definitions. @@ -21,7 +21,7 @@ This proposal solves this problem by providing a mechanism to reference external Several approaches were considered: -1. **Convention-based `schemas` directory**: This approach, while simple, was deemed too implicit and less flexible than an explicit mapping file. Also a folder only for validations doesn't the right approach. +1. **Convention-based `schemas` directory**: This approach, while simple, was deemed too implicit and less flexible than an explicit mapping file. Also a folder only for validations doesn't seem the right approach. 2. **`schema-dependencies.json` file**: This approach was chosen as it provides an explicit, flexible, and decoupled way to manage schema dependencies. It also permits referencing remote definitions.