Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enhance support for kube-version and api-versions #2121

Merged
merged 1 commit into from
Mar 31, 2022

Conversation

mumoshu
Copy link
Collaborator

@mumoshu mumoshu commented Mar 30, 2022

This adds support for kube-version and api-versions to be available to chartify so that it works even if your release requires chartify due to that you use features like forceNamespace, jsonPatches, strategicMergePatches, and so on.

This also enhances ReleaseSpec which corresponds to each item of releases[] in your helmfile.yaml to also accept kubeVersion and apiVersions, in addition to the top-level kubeVersion and apiVersions we have today.

The top-level ones works as the default values for release-specific ones. If you have been using the top-level ones, keep using it. It is backward-compatible. If you want to specify it per release, because, for example, your releases are deployed across clusters(in case you differentiate kubeContext fields), try the new fields added to the release spec.

Resolves #1864

This adds support for `kube-version` and `api-versions` to be available to `chartify` so that it works even if your release requires `chartify` due to that you use features like `forceNamespace`, `jsonPatches`, `strategicMergePatches`, and so on.

This also enhances `ReleaseSpec` which corresponds to each item of `releases[]` in your `helmfile.yaml` to also accept `kubeVersion` and `apiVersions`, in addition to the top-level `kubeVersion` and `apiVersions` we have today.

The top-level ones works as the default values for release-specific ones. If you have been using the top-level ones, keep using it. It is backward-compatible. If you want to specify it per release, because, for example, your releases are deployed across clusters(in case you differentiate `kubeContext` fields), try the new fields added to the release spec.
@mumoshu mumoshu force-pushed the enhance-kube-version-and-api-versions branch from 45578ad to d9e08a7 Compare March 30, 2022 01:27
@mumoshu mumoshu merged commit be5af8e into master Mar 31, 2022
@mumoshu mumoshu deleted the enhance-kube-version-and-api-versions branch March 31, 2022 02:02
@rayterrill
Copy link

@mumoshu This looks awesome - will this also work for specifying kubeVersion at the environment level? We do a lot of custom configs per environment - would be nice to be able to specify it there if possible vs at the release.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Chartify renders objects with incorrect apiVersion
2 participants