hull-demo-1.31.4

Changelog

---

[1.31.4]

FIXES:

• added schema validation of Gateway API objects created in tests so they are validated properly
• corrected version of created ReferenceGrant objects from v1 to v1alpha2
• fixed Gateway API incorrect schema in field hostnames by changing it to an array
• fixed usage of HULL transformations in all fields of Gateway API schema objects in values.schema.json. Additional JSON schema properties targeting regular, non-HULL transformation inputs (pattern, default, enum, ``minLengthandmaxLength` for strings, `format`, `minimum` and `maximum` for integers) were also applied to the `_HT` inputs which broke usage of them. Solved by strictly seperating inputs between `_HT` HULL transformation strings and regular inputs using the `anyOf` property. Thanks to ievgenii-shepeliuk for raising the issue here

hull-1.31.4

Changelog

---

[1.31.4]

FIXES:

• added schema validation of Gateway API objects created in tests so they are validated properly
• corrected version of created ReferenceGrant objects from v1 to v1alpha2
• fixed Gateway API incorrect schema in field hostnames by changing it to an array
• fixed usage of HULL transformations in all fields of Gateway API schema objects in values.schema.json. Additional JSON schema properties targeting regular, non-HULL transformation inputs (pattern, default, enum, ``minLengthandmaxLength` for strings, `format`, `minimum` and `maximum` for integers) were also applied to the `_HT` inputs which broke usage of them. Solved by strictly seperating inputs between `_HT` HULL transformation strings and regular inputs using the `anyOf` property. Thanks to ievgenii-shepeliuk for raising the issue here

hull-demo-1.32.2

Changelog

---

[1.32.2]

FIXES:

• added schema validation of Gateway API objects created in tests so they are validated properly
• corrected version of created ReferenceGrant objects from v1 to v1alpha2
• fixed Gateway API incorrect schema in field hostnames by changing it to an array
• fixed usage of HULL transformations in all fields of Gateway API schema objects in values.schema.json. Additional JSON schema properties targeting regular, non-HULL transformation inputs (pattern, default, enum, ``minLengthandmaxLength` for strings, `format`, `minimum` and `maximum` for integers) were also applied to the `_HT` inputs which broke usage of them. Solved by strictly seperating inputs between `_HT` HULL transformation strings and regular inputs using the `anyOf` property. Thanks to ievgenii-shepeliuk for raising the issue here

hull-demo-1.31.3

Changelog

---

[1.31.3]

CHANGES:

• added Gateway API objects in version 1.2.0-experimental as main object types to HULL: backendlbpolicy, backendtlspolicy, gatewayclass, gateway, grpcroute, httproute, referencegrant, tcproute, tlsroute and udproute. This should make it more comfortable to use them opposed to specifying them using the generic customresource object type. Thanks to suggestion from ievgenii-shepeliuk made here
• introducing sources feature for pods (pod level in the workload specifications) and containers (initContainers and containers levels in the workload specifications). Using souces enables global defaulting of pod and container properties and flexible sharing plus stacking of sets of properties for both pods and containers. Potential usages range from globally enforcing workload security settings, specifying shared minimum or special resource requirements or harmonization of all pods and containers in a chart. See the chart design guide for details. This also closes issues Add sharedContainers feature and Default security settings.
• added configurable multi-pass rendering of HULL transformations. This enables forward referencing of values in the YAML tree which was previously not possible. For example, using only a single HULL transformation rendering pass, a field .Values.hull.config.specific.field_a: _HT*hull.config.specific.field_b, where _HT*hull.config.specific.field_b: _HT*hull.config.specific.field_c, will resolve field_a to literal string _HT*hull.config.specific.field_c. This is the case because at the time when field_a is resolved the value of field_b is not yet resolved due to the alphanumeric order of HULL transformation processing. With the new multi-pass default of hull.config.general.render: 3, the field_a: _HT*hull.config.specific.field_c value is fully resolved to the referenced value of _HT*hull.config.specific.field_c in the second pass.

hull-demo-1.30.9

Changelog

---

[1.30.9]

FIXES:

• added schema validation of Gateway API objects created in tests so they are validated properly
• corrected version of created ReferenceGrant objects from v1 to v1alpha2
• fixed Gateway API incorrect schema in field hostnames by changing it to an array
• fixed usage of HULL transformations in all fields of Gateway API schema objects in values.schema.json. Additional JSON schema properties targeting regular, non-HULL transformation inputs (pattern, default, enum, ``minLengthandmaxLength` for strings, `format`, `minimum` and `maximum` for integers) were also applied to the `_HT` inputs which broke usage of them. Solved by strictly seperating inputs between `_HT` HULL transformation strings and regular inputs using the `anyOf` property. Thanks to ievgenii-shepeliuk for raising the issue here

hull-demo-1.30.8

Changelog

---

[1.30.8]

CHANGES:

• added Gateway API objects in version 1.2.0-experimental as main object types to HULL: backendlbpolicy, backendtlspolicy, gatewayclass, gateway, grpcroute, httproute, referencegrant, tcproute, tlsroute and udproute. This should make it more comfortable to use them opposed to specifying them using the generic customresource object type. Thanks to suggestion from ievgenii-shepeliuk made here
• introducing sources feature for pods (pod level in the workload specifications) and containers (initContainers and containers levels in the workload specifications). Using souces enables global defaulting of pod and container properties and flexible sharing plus stacking of sets of properties for both pods and containers. Potential usages range from globally enforcing workload security settings, specifying shared minimum or special resource requirements or harmonization of all pods and containers in a chart. See the chart design guide for details. This also closes issues Add sharedContainers feature and Default security settings.
• added configurable multi-pass rendering of HULL transformations. This enables forward referencing of values in the YAML tree which was previously not possible. For example, using only a single HULL transformation rendering pass, a field .Values.hull.config.specific.field_a: _HT*hull.config.specific.field_b, where _HT*hull.config.specific.field_b: _HT*hull.config.specific.field_c, will resolve field_a to literal string _HT*hull.config.specific.field_c. This is the case because at the time when field_a is resolved the value of field_b is not yet resolved due to the alphanumeric order of HULL transformation processing. With the new multi-pass default of hull.config.general.render: 3, the field_a: _HT*hull.config.specific.field_c value is fully resolved to the referenced value of _HT*hull.config.specific.field_c in the second pass.

hull-1.32.2

Changelog

---

[1.32.2]

FIXES:

• added schema validation of Gateway API objects created in tests so they are validated properly
• corrected version of created ReferenceGrant objects from v1 to v1alpha2
• fixed Gateway API incorrect schema in field hostnames by changing it to an array
• fixed usage of HULL transformations in all fields of Gateway API schema objects in values.schema.json. Additional JSON schema properties targeting regular, non-HULL transformation inputs (pattern, default, enum, ``minLengthandmaxLength` for strings, `format`, `minimum` and `maximum` for integers) were also applied to the `_HT` inputs which broke usage of them. Solved by strictly seperating inputs between `_HT` HULL transformation strings and regular inputs using the `anyOf` property. Thanks to ievgenii-shepeliuk for raising the issue here

hull-1.31.3

Changelog

---

[1.31.3]

CHANGES:

• added Gateway API objects in version 1.2.0-experimental as main object types to HULL: backendlbpolicy, backendtlspolicy, gatewayclass, gateway, grpcroute, httproute, referencegrant, tcproute, tlsroute and udproute. This should make it more comfortable to use them opposed to specifying them using the generic customresource object type. Thanks to suggestion from ievgenii-shepeliuk made here
• introducing sources feature for pods (pod level in the workload specifications) and containers (initContainers and containers levels in the workload specifications). Using souces enables global defaulting of pod and container properties and flexible sharing plus stacking of sets of properties for both pods and containers. Potential usages range from globally enforcing workload security settings, specifying shared minimum or special resource requirements or harmonization of all pods and containers in a chart. See the chart design guide for details. This also closes issues Add sharedContainers feature and Default security settings.
• added configurable multi-pass rendering of HULL transformations. This enables forward referencing of values in the YAML tree which was previously not possible. For example, using only a single HULL transformation rendering pass, a field .Values.hull.config.specific.field_a: _HT*hull.config.specific.field_b, where _HT*hull.config.specific.field_b: _HT*hull.config.specific.field_c, will resolve field_a to literal string _HT*hull.config.specific.field_c. This is the case because at the time when field_a is resolved the value of field_b is not yet resolved due to the alphanumeric order of HULL transformation processing. With the new multi-pass default of hull.config.general.render: 3, the field_a: _HT*hull.config.specific.field_c value is fully resolved to the referenced value of _HT*hull.config.specific.field_c in the second pass.

hull-1.30.9

Changelog

---

[1.30.9]

FIXES:

• added schema validation of Gateway API objects created in tests so they are validated properly
• corrected version of created ReferenceGrant objects from v1 to v1alpha2
• fixed Gateway API incorrect schema in field hostnames by changing it to an array
• fixed usage of HULL transformations in all fields of Gateway API schema objects in values.schema.json. Additional JSON schema properties targeting regular, non-HULL transformation inputs (pattern, default, enum, ``minLengthandmaxLength` for strings, `format`, `minimum` and `maximum` for integers) were also applied to the `_HT` inputs which broke usage of them. Solved by strictly seperating inputs between `_HT` HULL transformation strings and regular inputs using the `anyOf` property. Thanks to ievgenii-shepeliuk for raising the issue here

hull-1.30.8

Changelog

---

[1.30.8]

CHANGES:

• added Gateway API objects in version 1.2.0-experimental as main object types to HULL: backendlbpolicy, backendtlspolicy, gatewayclass, gateway, grpcroute, httproute, referencegrant, tcproute, tlsroute and udproute. This should make it more comfortable to use them opposed to specifying them using the generic customresource object type. Thanks to suggestion from ievgenii-shepeliuk made here
• introducing sources feature for pods (pod level in the workload specifications) and containers (initContainers and containers levels in the workload specifications). Using souces enables global defaulting of pod and container properties and flexible sharing plus stacking of sets of properties for both pods and containers. Potential usages range from globally enforcing workload security settings, specifying shared minimum or special resource requirements or harmonization of all pods and containers in a chart. See the chart design guide for details. This also closes issues Add sharedContainers feature and Default security settings.
• added configurable multi-pass rendering of HULL transformations. This enables forward referencing of values in the YAML tree which was previously not possible. For example, using only a single HULL transformation rendering pass, a field .Values.hull.config.specific.field_a: _HT*hull.config.specific.field_b, where _HT*hull.config.specific.field_b: _HT*hull.config.specific.field_c, will resolve field_a to literal string _HT*hull.config.specific.field_c. This is the case because at the time when field_a is resolved the value of field_b is not yet resolved due to the alphanumeric order of HULL transformation processing. With the new multi-pass default of hull.config.general.render: 3, the field_a: _HT*hull.config.specific.field_c value is fully resolved to the referenced value of _HT*hull.config.specific.field_c in the second pass.