[bitnami/kubeapps] Add nullable annotation in a param

[antgamdia]

Description of the change

Once bitnami/readme-generator-for-helm#31 was solved, this PR adds this new nullable annotation for letting the readme-generator know that null is a valid value for a specific param.

Benefits

Generating a schema or running the readme-generator tool will work again for this chart.

Possible drawbacks

N/A

Applicable issues

N/A

Additional information

Thanks for the effort and time in solving this edge case, @miguelaeh. Really appreciate it!

Checklist

• Chart version bumped in Chart.yaml according to semver.
• Variables are documented in the values.yaml and added to the README.md using readme-generator-for-helm
• Title of the PR starts with chart name (e.g. [bitnami/<name_of_the_chart>])
• All commits signed off and in agreement of Developer Certificate of Origin (DCO)

[miguelaeh]

If this field is a string, you would need to add:

Suggested change

	## @param kubeappsapis.pluginConfig.kappController.packages.v1alpha1.defaultPrereleasesVersionSelection [nullable] Default policy for allowing prereleases containing one of the identifiers
	## @param kubeappsapis.pluginConfig.kappController.packages.v1alpha1.defaultPrereleasesVersionSelection [string,nullable] Default policy for allowing prereleases containing one of the identifiers

in order to show type string into the schema

[antgamdia]

This param can be:

defaultPrereleasesVersionSelection: null
defaultPrereleasesVersionSelection: []
defaultPrereleasesVersionSelection: ["foo", "bar"]

So, I'm not sure we would want to show type: string in the schema, perhaps

Suggested change

	## @param kubeappsapis.pluginConfig.kappController.packages.v1alpha1.defaultPrereleasesVersionSelection [nullable] Default policy for allowing prereleases containing one of the identifiers
	## @param kubeappsapis.pluginConfig.kappController.packages.v1alpha1.defaultPrereleasesVersionSelection [array, nullable] Default policy for allowing prereleases containing one of the identifiers

[miguelaeh]

sure, then you should add array where I put string. You assumption is correct, just do not add spaces (I am not sure right now if there is a trim into the code for that

[antgamdia]

I've added it, but it results in an invalid openapi schema: the required items property for arrays is not being generated.

With @param .... [nullable], valid schema, but not representing the reality

"defaultPrereleasesVersionSelection": {
    "type": "object", 
    "description": "Default policy for allowing prereleases containing one of the identifiers",
    "default": "null",
    "nullable": true
},

With @param .... [array, nullable], invalid schema

"defaultPrereleasesVersionSelection": {
    "type": "array", 
     // missing 'items' property
    "description": "Default policy for allowing prereleases containing one of the identifiers",
    "default": "null",
    "nullable": true
},

Expected valid OpenAPI 3.0.X schema:

Note that we are explicitly not targeting openapi 3.1, otherwise, the nullable prop would be removed, and the type object would become an array. Useful SO post clarifying the differences.

"defaultPrereleasesVersionSelection": {
    "type": "string",
    "items": {
      "type": "string" // how can we infer this value? 
    },
    "description": "Default policy for allowing prereleases containing one of the identifiers",
    "default": null,
    "nullable": true
  }

[antgamdia]

So, rather than generating an invalid schema, I'd go with leaving it as is, until the items can be added/inferred in this edge case. WDYT?

[miguelaeh]

Looks like another corner case for arrays. Thank you for sharing it.

So, rather than generating an invalid schema, I'd go with leaving it as is,

Currently, if you don't specify any modifier for setting the type, it will be object by default. I think if you add just [nullable] the type will be set to object into the schema. Is that what you mean?

[antgamdia]

Yes, as we are not using the schema currently, semantic correctness is not a priority, so having type: object is something bearable until this edge case gets sorted out.
I mean, sacrificing semantic over syntactic correctness is preferred in this case.

Do you want me to file an issue in the readme's repo? Can we merge this PR then?

[antgamdia]

As discussed offline, this corner case is going to be resolved soon in the readme-generator tool, therefore, let me update the PR to also include the [array] modifier.
Thanks!

[miguelaeh]

I agree, let's proceed with this PR, I will try to fix t

[miguelaeh]

LGTM

[bitnami-bot]

I have just updated the bitnami images with the latest known immutable tags:

• "docker.io/bitnami/kubeapps-dashboard:2.4.3-debian-10-r7"
• "docker.io/bitnami/kubeapps-apprepository-controller:2.4.3-scratch-r1"
• "docker.io/bitnami/kubeapps-assetsvc:2.4.3-scratch-r2"
• "docker.io/bitnami/oauth2-proxy:7.2.1-debian-10-r63"
• "docker.io/bitnami/nginx:1.21.6-debian-10-r28"
• "docker.io/bitnami/kubeapps-apis:2.4.3-debian-10-r15"
• "docker.io/bitnami/kubeapps-kubeops:2.4.3-scratch-r2"
• "docker.io/bitnami/kubeapps-pinniped-proxy:2.4.3-debian-10-r12"
• "docker.io/bitnami/kubeapps-asset-syncer:2.4.3-scratch-r2"
• "docker.io/bitnami/nginx:1.21.6-debian-10-r28"