By utilizing the `clean-crds` script, both `validate` and `clean` can cleanly deal with issues related to annotations added and files overlaid as part of the CRD chart process.
This commit deprecates the providesGVR flag used by charts in favor of charts adding this annotation directly to the patch of their chart (or their Chart.yaml).
Before, the logic for reverting a CRD chart was located in `generate-patch` since it was the only script that required these changes. Now that the same logic is required on a `make clean` in order to support reverting just the generateCRDChart changes from local charts, this commit moves that logic out to its own script `clean-crds`.
Based on discussion in https://github.com/rancher/charts/pull/607#discussion_r483288658.
This commit adds the ability to add patches on subcharts in `rancher/charts` that meet the following constraints:
- Must be a remote chart (i.e. the repo url cannot point to a `file://<path>`)
- Must have a fixed version number (since we need a consistent base to apply the patch on)
The following changes have been made to the scripts to faciliate this feature:
**prepare**
Only run the patch after preparing the subchart
**prepare-subcharts:**
Inital checks:
1. We only prepare the subcharts if the chart has a `requirements.yaml`.
2. Extract the patches that would be applied to the requirements.yaml and only apply that
Note: in the future, we need to add support for dependencies outlined in the Chart.yaml directory, which is currently the recommended approach for Helm 3 charts that use `apiVersion: v2`, but since none of our charts currently use that it is assumed that they will encode their dependencies in a `requirements.yaml` at the moment.
Generate special dependencies (overlay, package.yaml):
1. For dependencies that are mirrored (i.e. rancher-kiali-server, where the dependency itself is stored as a `package.yaml`) that have not generated a `charts/` directory yet, we recursively run the `prepare` script for them in order to generate the directories so that `helm dependency update` can pull them in. The assumption here is that there will be no circular dependencies, although there is no explicit check for this.
2. For dependencies that are overlaid, we perform the overlay so that `helm dependency update` operates as expected.
Pull in latest subcharts and update files:
1. Perform `helm dependency update` to update the `requirements.yaml` and `requirements.lock` with the latest subchart versions
Cleanup (overlay, package.yaml, patched requirements)
1. Remove overlaid dependencies since they won't be tracked in the patch
2. Run the `clean` script on the mirrored dependencies
3. Revert the patch on the requirements.yaml
Apply logic to enable / disable patching:
1. If a subchart is a local chart, leave it as a tgz so it will be ignored on patch
2. If a subchart does not have a fixed version number, leave it as a tgz so it will be ignored on patch
3. If neither of these are true, unarchive the tgz for the subchart and delete the tgz so it will be tracked by the patch
NOTE: since the dependency still exists as either a tgz or a directory, `generate-charts` will not break from this change.
**generate-patch:**
Loop through the local `charts/requirements.yaml` to update the `charts-original/charts` directory:
1. If a subchart is not a local chart, remove it as we don't need to check for patches against it
2. If a subchart does not have a fixed version number, remove it as we don't need to check for patches against it
3. If neither of these are true, pull in the version number specified from the remote helm repo to track patches against it.
**Why does the version number need to be fixed?**:
In general, Helm chart owners can use wildcards within a `requirements.yaml` to specify the version of a subchart when a specific patch version does not necessarily need to be fixed. This is usually a great feature since that means that parent charts do not need to be updated in order for a `helm dependency update` to automatically pull in the latest versions of a dependency that do not break the parent chart; however, this causes an issue with patching subcharts since the base that the patch is applied on is not fixed.
Therefore, this commit only allows users to apply patches on subcharts that have a fixed subchart version specified in their `requirements.yaml`.
**Why can't we track local charts?**
If the chart is local to this repo, the assumption is that you should directly be making the changes to the chart.
This commit splits the subchart logic from the `prepare` script into a separate `prepare-subcharts` script and slightly modifies the prepare logic to generate CRD charts only after preparing subcharts and applying the patch file.
aiyengar2
aiyengar2
Arvind Iyengar
cbron
Caleb Bron
Brenda Rearden
brendarearden
paynejacob
PennyScissors
Steven Crespo
ibuildthecloud
Darren Shepherd