Release 1.35

azure-pipelines-gated.yml

@@ -21,17 +21,29 @@ jobs:
   strategy: 
     maxParallel: 5
     matrix:      
-      Helm_3_19_2_single: 
-        HelmVersion: "3.19.2"
+      Helm_3_19_5_single: 
+        HelmVersion: "3.19.5"
         TestType: single
-      Helm_3_19_2_multi: 
-        HelmVersion: "3.19.2"
+      Helm_3_19_5_multi: 
+        HelmVersion: "3.19.5"
         TestType: multi
-      Helm_4_0_1_single: 
-        HelmVersion: "4.0.1"
+      Helm_3_20_0_single: 
+        HelmVersion: "3.20.0"
         TestType: single
-      Helm_4_0_1_multi: 
-        HelmVersion: "4.0.1"
+      Helm_3_20_0_multi: 
+        HelmVersion: "3.20.0"
+        TestType: multi
+      Helm_4_0_5_single: 
+        HelmVersion: "4.0.5"
+        TestType: single
+      Helm_4_0_5_multi: 
+        HelmVersion: "4.0.5"
+        TestType: multi
+      Helm_4_1_0_single: 
+        HelmVersion: "4.1.0"
+        TestType: single
+      Helm_4_1_0_multi: 
+        HelmVersion: "4.1.0"
         TestType: multi
 
   steps:

azure-pipelines.yml

@@ -37,6 +37,30 @@ jobs:
       Helm_3_19_2_multi: 
         HelmVersion: "3.19.2"
         TestType: multi
+      Helm_3_19_3_single: 
+        HelmVersion: "3.19.3"
+        TestType: single
+      Helm_3_19_3_multi: 
+        HelmVersion: "3.19.3"
+        TestType: multi
+      Helm_3_19_4_single: 
+        HelmVersion: "3.19.4"
+        TestType: single
+      Helm_3_19_4_multi: 
+        HelmVersion: "3.19.4"
+        TestType: multi
+      Helm_3_19_5_single: 
+        HelmVersion: "3.19.5"
+        TestType: single
+      Helm_3_19_5_multi: 
+        HelmVersion: "3.19.5"
+        TestType: multi
+      Helm_3_20_0_single: 
+        HelmVersion: "3.20.0"
+        TestType: single
+      Helm_3_20_0_multi: 
+        HelmVersion: "3.20.0"
+        TestType: multi
       Helm_4_0_0_single: 
         HelmVersion: "4.0.0"
         TestType: single
@@ -49,6 +73,36 @@ jobs:
       Helm_4_0_1_multi: 
         HelmVersion: "4.0.1"
         TestType: multi
+      Helm_4_0_2_single: 
+        HelmVersion: "4.0.2"
+        TestType: single
+      Helm_4_0_2_multi: 
+        HelmVersion: "4.0.2"
+        TestType: multi
+      Helm_4_0_3_single:
+        HelmVersion: "4.0.3"
+        TestType: single
+      Helm_4_0_3_multi:
+        HelmVersion: "4.0.3"
+        TestType: multi
+      Helm_4_0_4_single:
+        HelmVersion: "4.0.4"
+        TestType: single
+      Helm_4_0_4_multi:
+        HelmVersion: "4.0.4"
+        TestType: multi
+      Helm_4_0_5_single:
+        HelmVersion: "4.0.5"
+        TestType: single
+      Helm_4_0_5_multi:
+        HelmVersion: "4.0.5"
+        TestType: multi
+      Helm_4_1_0_single:
+        HelmVersion: "4.1.0"
+        TestType: single
+      Helm_4_1_0_multi:
+        HelmVersion: "4.1.0"
+        TestType: multi
   steps:
   - template: azure-pipelines-test.yml  # Template reference
     parameters:

hull/CHANGELOG.md

@@ -1,8 +1,11 @@
 # Changelog
 
-## [1.35.0]
+## [1.35.1]
 
 CHANGES:
 
-- initial K8S 1.35 release
-- deprecating 1.32 release
+- support subchart usecases with HULL. First, the parsing of HULL relevant fields for transformations has been extended to all of `.Values` instead of `.Values.hull`. This means that HULL transformations in sections outside of `.Values.hull`, such as subchart configurations and `.Values.global`, are now also handled and the result is available for further processing. When adding the `hull.yaml` to a subcharts `templates/zzz` folder in a HULL based parent chart, it becomes possible to use transformations that involve shared data under `.Values.global` and make the result available to parent and sub charts.
+
+FIXES:
+
+- due to [changes made to Helm 3 versions](https://github.com/helm/helm/issues/30587), the behavior for accessing undefined values has changed for specific Helm 3 versions starting with 3.19.5+ and 3.20+. The named versions (and potentially all following Helm 3 patches) exhibit the Helm 4 behavior which leads to an error if an undefined field is accessed. Tests were adapted to differentiate concrete Helm 3 versions and set correct expectations.

hull/Chart.yaml

@@ -1,6 +1,6 @@
 apiVersion: v2
 name: hull
-version: "1.35.0"
+version: "1.35.1"
 description: HULL - Helm Uniform Layer Library
 type: library
 keywords:

hull/HISTORY.md

@@ -1,5 +1,15 @@
 # History
 
+## [1.35.1]
+
+CHANGES:
+
+- support subchart usecases with HULL. First, the parsing of HULL relevant fields for transformations has been extended to all of `.Values` instead of `.Values.hull`. This means that HULL transformations in sections outside of `.Values.hull`, such as subchart configurations and `.Values.global`, are now also handled and the result is available for further processing. When adding the `hull.yaml` to a subcharts `templates/zzz` folder in a HULL based parent chart, it becomes possible to use transformations that involve shared data under `.Values.global` and make the result available to parent and sub charts.
+
+FIXES:
+
+- due to [changes made to Helm 3 versions](https://github.com/helm/helm/issues/30587), the behavior for accessing undefined values has changed for specific Helm 3 versions starting with 3.19.5+ and 3.20+. The named versions (and potentially all following Helm 3 patches) exhibit the Helm 4 behavior which leads to an error if an undefined field is accessed. Tests were adapted to differentiate concrete Helm 3 versions and set correct expectations.
+
 ## [1.35.0]
 
 CHANGES:

hull/README.md

@@ -30,19 +30,18 @@ However, note that minor (however potentially chart-breaking) differences were i
   field_string: "some_text" # string text
   field_int: 123 # number
   field_bool: true # boolean
-  field_unset: 
-  field_dict: 
+  field_unset:
+  field_dict:
     key_1: value_1
   ```
 
-  The behavior of Helm 3, when accessing such a field's property value, was to treat it as an empty string value from observation. This means, the key value pair exists in the `.Values` object tree and it's value is empty and of string type. With Helm 4 on the other hand, the field is absent from the object tree and accessing it will lead to an error.
+    The behavior of Helm 3, when accessing such a field's property value, was to treat it as an empty string value from observation. This means, the key value pair exists in the `.Values` object tree and it's value is empty and of string type. With Helm 4 on the other hand, the field is absent from the object tree and accessing it will lead to an error.
 
 Both aspects should typically be less relevant for HULL based charts, however it shall be documented here to avoid confusion. More detailed information can be found in the [related Helm issue](https://github.com/helm/helm/issues/31344).
 
 **Your feedback on this project is valued, hence please comment or start a discussion in the `Issues` section or create feature wishes and bug reports. Thank you!**
 
-The HULL library chart idea is partly inspired by the [common](
-https://github.com/helm/charts/tree/master/incubator/common) Helm chart concept and for testing
+The HULL library chart idea is partly inspired by the [common](https://github.com/helm/charts/tree/master/incubator/common) Helm chart concept and for testing
 
 [![Gauge Badge](https://gauge.org/Gauge_Badge.svg)](https://gauge.org).
 
@@ -155,7 +154,7 @@ hull: # HULL is configured via subchart key 'hull'
 
 This is the example constituting as `hull-demo`'s `values.yaml`, if you download the latest `hull-demo` release and execute:
 
-```bash
+```yaml
 helm template hull-demo-<version>.tgz
 ```
 
@@ -195,7 +194,7 @@ Concentrate on what is needed to specify Kubernetes objects without having to ad
 
 For all Kubernetes object types supported by HULL, **full configurational access to the Kubernetes object types properties is directly available**. This relieves chart maintainers from having to add missing configuration options one by one and the Helm chart users from forking the Helm chart to add just the properties they need for their configuration. Only updating the HULL chart to a newer version with matching Kubernetes API version is required to enable configuration of properties added to Kubernetes objects meanwhile in newer API versions. The HULL charts are versioned to reflect the minimal Kubernetes API versions supported by them.
 
-   For more details refer to the documentation on [Architecture Overview](/hull/files/doc/architecture.md).
+  For more details refer to the documentation on [Architecture Overview](/hull/files/doc/architecture.md).
 
 ### Unified interface for defining and configuring Helm charts backed by JSON schema
 
@@ -207,14 +206,16 @@ The single interface of the HULL library is used to both create and configure ob
 
 **Uniform and rich metadata is automatically attached to all objects created by the HULL library.**
 
-- Kubernetes standard labels as defined for [Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/) and [Helm](https://helm.sh/docs/chart_best_practices/labels/#standard-labels) are added to all objects metadata automatically.
-- Additional custom labels and annotations metadata can be set hierarchically for:
-  - all created Kubernetes objects or
-  - all created Kubernetes objects of a given type or
-  - a group of objects of different object types or
-  - any individual Kubernetes object.
+Kubernetes standard labels as defined for [Kubernetes](https://kubernetes.io/docs/concepts/overview/working-with-objects/common-labels/) and [Helm](https://helm.sh/docs/chart_best_practices/labels/#standard-labels) are added to all objects metadata automatically.
+
+Additional custom labels and annotations metadata can be set hierarchically for:
+
+- all created Kubernetes objects or
+- all created Kubernetes objects of a given type or
+- a group of objects of different object types or
+- any individual Kubernetes object.
 
-  For more details on metadata overwriting refer to the advanced example below.
+For more details on metadata overwriting refer to the advanced example below.
 
 ### Flexible and comfortable integration of ConfigMaps and Secrets into your Helm chart
 
@@ -280,7 +281,7 @@ Installing or upgrading a chart using HULL follows the standard procedures for e
 
 ## First Examples
 
-Using the nginx deployment example from the [Kubernetes documentation](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#creating-a-deployment) as something we want to create with our HULL based Helm chart:
+Using the nginx deployment example from the Kubernetes documentation [for nginx](https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#creating-a-deployment) as something we want to create with our HULL based Helm chart:
 
 ```yaml
 apiVersion: apps/v1

hull/files/doc/setup.md

@@ -25,6 +25,8 @@ To manually add the HULL library chart to an existing Helm chart:
 
   - copy all the files from the folder `/files/templates` to your parent charts `/templates` folder.
 
+  ⚠️ **If you plan on combining HULL with generic Helm template files, it is advised to put the `hull.yaml` into a subfolder named `zzz`. Due to the order in which Helm reads and processes templates, the `hull.yaml` in a folder with the highest alphanumerical name will be processed first and the modifications to the `.Values` are active afterwards. This will allow external templates to use HULL processed `values.yaml` fields. See [Subcharts and generic Helm templates](subcharts_generic_templates.md) for details** ⚠️
+
   ⚠️ **Generally it is required to have the single `hull.yaml` or the individual files from `/files/templates` HULL library functions render the objects specified under the key `hull.objects` in the parent charts `/templates` folder! As of this moment Helm only considers files in the parent charts `/templates` folder for rendering. Consider adding this step to your build pipeline when creating releases of your Helm chart which include HULL.** ⚠️
 
   ⚠️ **There are indications that when a single file in the parent Helm charts `/templates` folder contains many objects to render this impacts performance negatively when run against a real Kubernetes cluster. The time it takes to `helm template`, `helm update` or `helm install` appears to be significantly longer when using one instead of several files. The reason for this is unclear and the behavior looks unneeded and fixable in Helm, it should not matter for processing if objects are read from many or a single template. But right now this would require a fix in Helm itself which is currently out of scope. To workaround this problem (or if you anyway like to have multiple files per object type for rendering) you can alternatively select to use the multiple files per object type from `/files/templates` instead of `hull.yaml` from the HULL charts root folder for rendering!** ⚠️