diff --git a/README.md b/README.md index e7620128d2..ecda5b0dda 100644 --- a/README.md +++ b/README.md @@ -2,273 +2,6 @@ This repository contains Helm charts served by Rancher Apps & Marketplace. -- More information on `how to make changes` to this repository: [`docs/developing.md`](docs/developing.md). -- More information on `experimental features`: [`docs/experimental.md`](docs/experimental.md). -- More information on `commands` that can be run in this repository: [`docs/makefile.md`](docs/makefile.md). -- More information on `Packages`: [`docs/packages.md`](docs/packages.md). -- More information on `CI validation`: [`docs/validation.md`](docs/validation.md). -- [New Out Of Band Release Process](#new-out-of-band-release-process) -- [New Assets Lifecycle](#new-assets-lifecycle) -- [New Release Process Workflow](#new-release-process-workflow) -- [Issues](#issues) -- [Branches](#branches) -- [Making Changes](#making-changes) -- [Adding Net-New dependencies to dev-v2.X](#adding-net-new-dependencies-to-dev-2x) -- [Versioning Charets](#versioning-charts) -- [Upstream Charts](#upstream-charts) -- [Local Charts](#local-charts) -- [Rancher Version Annotations](#rancher-version-annotations) -- [Versioning FAQ](#versioning-faq) -- [Supporting Images in Airgap](#supporting-images-in-airgap) +It is currently maintained by the Release Team. ---- - -### New Out Of Band Release Process -Starting on `17/May/2024`. - -This is only valid for `release-v2.*` branches. -Since this implementation, all teams may release each chart when they want. - -##### Overview of the process: -1. Assuming you have a chart ready and merged on `dev-v2.*` branch. -2. On your local machine: `fetch`, `pull` and `checkout` to `release-v2.*` -3. Create a new branch from `release-v2.*` -4. Execute `make forward-port` -5. Clear your `release.yaml` file, leave only your chart that will be released -6. Add, Commit and push your changes to your forked repository - -**Attention**: If you have a CRD that must be released with the chart, you should repeat `Step 4.` until `Step 6.` for the CRD chart. - -7. Create a Pull Request from your forked repository to `rancher/charts` pointing to `release-v2.*` - - -##### How to use `forward-port`: - -**Usage:** - -```(bash) -make forward-port CHART= VERSION= BRANCH= UPSTREAM= -``` - -Script Arguments Reference: -- CHART=`Chart name, exactly the same as in /charts and /assets folder` -- VERSION=`The version you want to release, the same one you would write into release.yaml` -- BRANCH=`The branch where the ready chart is merged in the remote repository` -- UPSTREAM=`The git remote name where the chart is present` - - -**Real-Example:** - -```(bash) -make forward-port CHART=rancher-istio VERSION=103.3.0+up1.21.1 BRANCH=dev-v2.8 UPSTREAM=upstream -``` - -In this case, we are at branch `release-v2.8`, we have a new version of Istio at `dev-v2.8`. - -The script will get all necessary changes for `assets`, `charts`, `release.yaml` and `index.yaml` and handle them all automatically. - -The changes will be pulled from the remote repository, the `UPSTREAM` variable tells which git remote the script must pull from, in my case I renamed it to upstream, the default value is `origin`. - -``` -❯ git remote -v -fork https://github.com/nicholasSUSE/charts (fetch) -fork https://github.com/nicholasSUSE/charts (push) -upstream https://github.com/rancher/charts (fetch) -upstream https://github.com/rancher/charts (push) - -``` - -### New Assets Lifecycle - -Starting on `17/May/2024` there is a new asset lifecycle in place. - -We will keep only the relevant assets in the corresponding branch. - -This means a cycle of always 3 active branches, with each branch always holding up to 2 previous versions before it. - -In a nutshell: -- release-v2.7 hold chart versions for Rancher: (2.5; 2.6; 2.7) -- release-v2.8 hold chart versions for Rancher: (2.6; 2.7; 2.8) -- release-v2.9 hold chart versions for Rancher: (2.7; 2.8; 2.9) - -![Assets Lifecycle](./docs/assets_lifecycle.png) - - -### New Release Process Workflow - -Starting on `17/May/2024` there is a new workflow for developing and releasing charts in place. - - -![Release Workflow](./docs/dev_workflow.png) - -Main changes from the previous workflow: - -- The development workflow is still the same however QA should test Charts from `dev-v2.X` branches now. -- Instead of the Mapps team releasing Charts in Bataches and waiting for Chart development to be ready, now each team owner is responsible for the release process using `make forward-port`. - - See: [New Out Of Band Release Process](#new-out-of-band-release-process) -- Each Chart owner must be aware of Rancher release dates and must coordinate with QA in order to have the Charts released before the Rancher release happens. - -### Issues - -All issues must be created in the [`rancher/rancher`](https://github.com/rancher/rancher) repository. - -### Branches - -- `dev-2.X` branches contain charts that are under active development, to be released in an upcoming Rancher release. -- `release-v2.X` branches contain charts that have already been developed, tested, and released on an existing Rancher release. - -### Making Changes - -Since this repository uses [`rancher/charts-build-scripts`](https://github.com/rancher/charts-build-scripts), making changes to this repository involves three steps: -1. Adding or modifying an existing `Package` tracked in the `packages/` directory. Usually involves `make prepare`, `make patch`, and `make clean`. -2. Running `make charts` to automatically generate assets used to serve a Helm repository (`charts/`, `assets/`, and `index.yaml`) based on the contents of `packages/`. -3. [CI] Running `make validate` to ensure that all generated assets are up-to-date and ready to be merged. - - -#### Adding Net-New dependencies to dev-2.x -A new build artifact was introduced in v2.7.0 of Rancher, titled `rancher-image-origins.txt`, which denotes the source code repository (github repository) of each image used in Charts and System-Charts. - -When adding new dependencies to dev-2.7+, a PR must first be raised and merged in the Rancher repository with the required changes to the `pkg/image/origins.go` file. - -This ensures that the artifact is up-to-date -with the latest images, and will prevent build failures within Rancher when attempting to generate the artifact. Changes to this file are **not** required when updating versions of existing dependencies. - -#### Versioning Charts - -Two kinds of charts exist in this repository. For each type the versioning is different. - -- upstream charts -- local charts. - -##### Upstream Charts - -In this repository, all packages specify the `version` field in the `package.yaml`. - -The upstream charts follow this versioning: `1.0.#+upX.Y.Z` - -`X`.`Y`.`Z` is the upstream chart's `major`.`minor`.`patch` - -The `1.0.#` versioning scheme roughly corresponds to the following rules (with exceptions): -- **Major Version**: represents the Rancher minor version these charts are being released to. - - Anything less than `100`: Rancher 2.5 - - `100`: Rancher 2.6 - - `101` and `102`: Rancher 2.7 - - `103`: Rancher 2.8 - - `104`: Rancher 2.9 - - etc. -- **Minor Version**: represents a release line of a given chart within a Rancher minor version. -- **Patch Version**: represents a patch to a given release line of a chart within a Rancher minor version. - - -For more information on how package versioning works, please see [`docs/developing.md`](docs/developing.md). - -##### Local Charts - -- For local charts, we don't follow any complex versioning scheme. Only one `semver`, versioning scheme `x.x.x` is being followed. - -#### Rancher Version Annotations - -In addition to modifying the chart version, the `catalog.cattle.io/rancher-version` annotation is required for user-facing charts that show up in Rancher UI; there is no need to add the annotation to CRD charts or internal charts (like fleet). - -General guidelines when releasing a new version of a user-facing chart: - -1. **Ensure the chart has the annotation `catalog.cattle.io/rancher-version` with a lower and upper bound, such as `>= 2.6.0-0 < 2.7.0-0`**. - - - This indicates that a fresh install of the chart should be allowed in any version of Rancher over `2.6.0-0` and below `2.7.0-0` line. - - - It should be freshly installable in `2.6.0+`, but should not be freshly installable in Rancher `2.7.0+`. The lower bound is particularly useful for charts that will **not** work in an older version of Rancher, e.g. `catalog.cattle.io/rancher-version: >= 2.6.2-0 < 2.7.0-0` indicates that this chart should only be freshly installable in Rancher `2.6.2+`, but should not be freshly installable in `Rancher 2.7.0+`. - - If you do this, it is also recommended that you **modify the previously released chart to have `catalog.cattle.io/rancher-version: < 2.6.2-0`**. For instructions on how to modify existing charts, see [`docs/developing.md`](docs/developing.md). -2. **Ensure the chart has the annotation `catalog.cattle.io/kube-version` with a lower and upper bound, such as `>= 1.16.0-0 < 1.25.0-0`**. - - This indicates that a fresh install of the chart should be allowed in a cluster with any version of Kubernetes over `1.16.0` and below `1.25.0` line. It should be freshly installable in a `1.16.0+` cluster, but should not be freshly installable in `1.25.0+`. - -#### Versioning FAQ - -1. Do we directly backport charts to previous Rancher minor versions (e.g. make `100.x.x` available in Rancher `2.5`)? - - - No, we do not. If a fix needs to go to both Rancher `2.5` and `v2.6`, we just release a new chart in each branch. Then, we forward-port the one released in the `release-v2.5` branch to `release-v2.6`. - - - If a fix that went into Rancher `2.6` needs to be backported to Rancher `2.5`, it will be the developer's responsibility to bump the chart version in `dev-v2.5`, copy back the changes, and release a **new** chart following the Rancher `2.5` versioning scheme to `release-v2.5`. - -2. If Rancher `2.5` releases Monitoring `14.5.100` and `16.6.0` and Rancher `2.6` releases Monitoring `100.0.0+up14.5.100` and `100.0.1+up16.6.0`, how do we prevent users from "downgrading" from `16.6.0` to `100.0.0+up14.5.100` on a `helm upgrade` after upgrading Rancher minor versions? - - - Currently, this is unavoidable. There is an expectation that users should look at the upstream annotation on the chart version (e.g. `+upX.Y.Z`), read the Rancher minor version release notes, or consult the chart's `README.md` or `app-README.md` before performing an upgrade on their applications after migrating to a new Rancher minor version. - - - We are still looking for a better way to mitigate this kind of risk. - -3. For Rancher version annotations, why don't we need to add the lower bound all the time? - - - Each Rancher minor version has its dedicated chart release branch (e.g. `release-v2.5`, `release-v2.6`, etc.), so a chart designed for Rancher `2.6.x` will never be available or show up in Rancher `2.5.x`; therefore, we do not need to worry about setting a lower bound of `> 2.5.99-0` on all charts. - -#### Supporting Images in Airgap - -Currently, the scripts used to generate the `rancher-images.txt` (used for mirroring a private registry in a air-gapped Rancher setup) rely on `values.yaml` files in charts that nest all image repository and tags used by the Helm chart under `repository` and `tag` fields. - -For example: - -```yaml -image: org/repo:v0.0.0 # will not be picked up - -hello: - world: - # will be picked up, even though it is nested under hello.world.* - repository: org/repo - tag: v0.0.0 - os: windows # optional, takes in a comma-delimited list of supported OSs. By default, the OS is assumed to be "linux" but you can specify "windows" or "linux,windows" as well. -``` - -Therefore, any charts that are committed into this repository must nest references to Docker images in this format within each chart's `values.yaml`; if an upstream chart you are referencing does not follow this format, it is recommended that you refactor the chart's values.yaml to look like this: - -```yaml -images: - config_reloader: - repository: rancher/mirrored-jimmidyson-configmap-reload - tag: v0.4.0 - fluentbit: - repository: rancher/mirrored-fluent-fluent-bit - tag: 1.7.9 - fluentbit_debug: - repository: rancher/mirrored-fluent-fluent-bit - tag: 1.7.9-debug - fluentd: - repository: rancher/mirrored-banzaicloud-fluentd - tag: v1.12.4-alpine-1 - nodeagent_fluentbit: - os: "windows" - repository: rancher/fluent-bit - tag: 1.7.4 -``` - -#### Pull Request rules - -Please create your Pull Request title following this rule: - -``` -[dev-v2.X] -[release-v2.X] -``` - -A working example: -``` -[dev-v2.8] rancher-istio 103.2.0+up1.19.6 update -``` - -- ``: The full name of the charts exactly how it is written under `/charts folder` -- ``: The full version of the chart, exactly how it is written under `release.yaml` -- ``: `update`; `remove`; `add` - -What you should keep in mind for releasing charts: - -##### Basics -- Each Pull Request should only modify one chart with its dependencies. - -##### release.yaml -- Each chart version in release.yaml DOES NOT modify an already released chart. If so, stop and modify the versions so that it releases a net-new chart. -- Each chart version in release.yaml IS exactly 1 more patch or minor version than the last released chart version. If not, stop and modify the versions so that it releases a net-new chart. - -##### Chart.yaml and index.yaml -- The `index.yaml` file has an entry for your new chart version. -- The `index.yaml` entries for each chart matches the `Chart.yaml` for each chart. -- Each chart has ALL required annotations - - kube-version annotation - - rancher-version annotation - - permits-os annotation (indicates Windows and/or Linux) +More information on [Wiki](https://github.com/rancher/charts/wiki) \ No newline at end of file diff --git a/docs/How-To-Guides/how_to_resolve_patch_failure.md b/docs/How-To-Guides/how_to_resolve_patch_failure.md deleted file mode 100644 index 16c613376a..0000000000 --- a/docs/How-To-Guides/how_to_resolve_patch_failure.md +++ /dev/null @@ -1,150 +0,0 @@ -## How to resolve patch failures - - -### Problem - -- This guide will help you resolve patch failure errors like the one shown below. - -``` -time="2023-12-01T13:45:56+05:30" level=info msg="Pulling k8snetworkplumbingwg/sriov-network-operator@bcab8844d807ee1db558533248273ccd492874bb/deployment/sriov-network-operator from upstream into charts" -time="2023-12-01T13:46:31+05:30" level=info msg="Loading dependencies for chart" -time="2023-12-01T13:46:31+05:30" level=info msg="Pulling https://github.com/kubernetes-sigs/node-feature-discovery/releases/download/v0.14.1/node-feature-discovery-chart-0.14.1.tgz from upstream into charts" -time="2023-12-01T13:46:33+05:30" level=info msg="Loading dependencies for chart" -time="2023-12-01T13:46:33+05:30" level=info msg="Applying changes from generated-changes" -time="2023-12-01T13:46:33+05:30" level=info msg="Updating chart metadata with dependencies" -time="2023-12-01T13:46:33+05:30" level=warning msg="Detected 'apiVersion:v2' within Chart.yaml; these types of charts require additional testing" -time="2023-12-01T13:46:33+05:30" level=info msg="Applying changes from generated-changes" -time="2023-12-01T13:46:33+05:30" level=info msg="Applying: generated-changes/patch/Chart.yaml.patch" -time="2023-12-01T13:46:33+05:30" level=error msg="\npatching file Chart.yaml\nHunk #1 FAILED at 1.\n1 out of 1 hunk FAILED -- saving rejects to file Chart.yaml.rej\n" -time="2023-12-01T13:46:33+05:30" level=fatal msg="encountered error while preparing main chart: encountered error while trying to apply changes to charts: unable to generate patch with error: exit status 1" -``` - -- This patch failure occured when running `make prepare` on `rancher-sriov` package. The patch file Chart.yaml.patch failed to apply here. So, how do you fix these kinds of patch failures. - -### Solution - -- First, we move out the patch file `Chart.yaml.patch` out of `generated-changes` folder. Here, for example, I am moving the patch file to the github repo directory. - -``` -charts$ mv packages/rancher-sriov/generated-changes/patch/Chart.yaml.patch ./ -``` - -- Later, we run `make prepare` again. If any of the patch files fail, we move out in the similar manner and run `make prepare` again. - - -- Now, we manually apply the Chart.yaml.patch onto `./packages/rancher-sriov/charts/Chart.yaml`. After manually applying the patch file - - -##### *Chart.yaml.patch* - -```--- charts-original/Chart.yaml -+++ charts/Chart.yaml -@@ -1,17 +1,29 @@ -+annotations: -+ catalog.cattle.io/auto-install: sriov-crd=match -+ catalog.cattle.io/certified: rancher -+ catalog.cattle.io/experimental: "true" -+ catalog.cattle.io/kube-version: '>= 1.16.0-0 < 1.28.0-0' -+ catalog.cattle.io/namespace: cattle-sriov-system -+ catalog.cattle.io/os: linux -+ catalog.cattle.io/permits-os: linux -+ catalog.cattle.io/rancher-version: '>= 2.8.0-0 < 2.9.0-0' -+ catalog.cattle.io/release-name: sriov -+ catalog.cattle.io/upstream-version: 1.2.0 - apiVersion: v2 --appVersion: 1.1.0 --dependencies: --- condition: rancher-nfd.enabled -- name: rancher-nfd -- repository: file://./charts/rancher-nfd -+appVersion: 1.2.0 - description: SR-IOV network operator configures and manages SR-IOV networks in the - kubernetes cluster - home: https://github.com/k8snetworkplumbingwg/sriov-network-operator -+icon: https://charts.rancher.io/assets/logos/sr-iov.svg - keywords: - - sriov -+- Networking - kubeVersion: '>= 1.16.0' --name: sriov-network-operator -+maintainers: -+- email: charts@rancher.com -+ name: Rancher Labs -+name: sriov - sources: --- https://github.com/k8snetworkplumbingwg/sriov-network-operator -+- https://github.com/rancher/charts - type: application - version: 0.1.0 -``` - -the `./packages/rancher-sriov/charts/Chart.yaml` is modified from - - -##### *Chart.yaml before manual patching* - - -``` -apiVersion: v2 -appVersion: 1.1.0 -dependencies: -- condition: rancher-nfd.enabled - name: rancher-nfd - repository: file://./charts/rancher-nfd - version: 0.14.1 -description: SR-IOV network operator configures and manages SR-IOV networks in the - kubernetes cluster -home: https://github.com/k8snetworkplumbingwg/sriov-network-operator -keywords: -- sriov -kubeVersion: '>= 1.16.0' -name: sriov-network-operator -sources: -- https://github.com/k8snetworkplumbingwg/sriov-network-operator -type: application -version: 0.1.0 -``` - -to - -##### *Chart.yaml after manual patching* - - ``` - annotations: - catalog.cattle.io/auto-install: sriov-crd=match - catalog.cattle.io/certified: rancher - catalog.cattle.io/experimental: "true" - catalog.cattle.io/kube-version: '>= 1.16.0-0 < 1.28.0-0' - catalog.cattle.io/namespace: cattle-sriov-system - catalog.cattle.io/os: linux - catalog.cattle.io/permits-os: linux - catalog.cattle.io/rancher-version: '>= 2.8.0-0 < 2.9.0-0' - catalog.cattle.io/release-name: sriov - catalog.cattle.io/upstream-version: 1.2.0 -apiVersion: v2 -appVersion: 1.2.0 -description: SR-IOV network operator configures and manages SR-IOV networks in the - kubernetes cluster -home: https://github.com/k8snetworkplumbingwg/sriov-network-operator -icon: https://charts.rancher.io/assets/logos/sr-iov.svg -keywords: -- sriov -- Networking -kubeVersion: '>= 1.16.0' -name: sriov -maintainers: -- email: charts@rancher.com - name: Rancher Labs -sources: -- https://github.com/rancher/charts -type: application -version: 0.1.0 - ``` - - -That's all. `maker prepare` is completed. Make sure to delete the `Chart.yaml.patch` in the repo directory - -``` -charts$ rm Chart.yaml.patch -``` - diff --git a/docs/assets_lifecycle.png b/docs/assets_lifecycle.png deleted file mode 100644 index 3660026051..0000000000 Binary files a/docs/assets_lifecycle.png and /dev/null differ diff --git a/docs/deprecation.md b/docs/deprecation.md deleted file mode 100755 index 37f3e6cc8a..0000000000 --- a/docs/deprecation.md +++ /dev/null @@ -1,42 +0,0 @@ -## Rancher Charts Deprecation Policy - -### Introduction - -This deprecation policy applies to all Helm charts maintained in this repository. It is designed to inform users about our approach to deprecating and removing charts, ensuring that transitions are smooth and expectations are managed appropriately. - -### Objectives - -Our deprecation policy aims to: - -- Provide clear and consistent guidelines on the lifecycle of Helm charts within our repository. -- Ensure stability for users utilizing our charts. -- Encourage the adoption of the latest features, fixes, and improvements. -- Efficiently manage project resources by focusing on charts that offer significant value to our users. - -### Versioning and Releases - -We adhere to [Semantic Versioning (SemVer)](https://semver.org/) for our Helm charts, where releases may introduce bug fixes, new features, or improvements. SemVer dictates: - -- **Major versions (X.y.z)** introduce breaking changes. -- **Minor versions (x.Y.z)** add functionality in a backward-compatible manner. -- **Patch versions (x.y.Z)** are for backward-compatible bug fixes. - -A chart may be deprecated for a number of reasons: upstream chart is no longer available or is not receiving updates, replacement by another chart, a business decision, etc. This repository follows the deprecation policy of Rancher. - -### Deprecation Timeline - -- **General Availability**: The chart is available in Rancher version X.Y.Z - -- **Notice Period**: Deprecation notice provided to users in Rancher X.(Y+1).0. The chart will be supported and maintained through out the supported lifecycle of the minor release. - -- **Chart Deprecated**: The chart will be deprecated in Rancher X.(Y+2).0. The chart will be available to support users who need to upgrade from the X.Y.Z release. The chart is only available as-is and will only receive critical security updates. - -- **End of Life (EOL)**: the chart EOL will be in Rancher X.(Y+3).0. The chart is removed from Rancher in this release. Users must have migrated away from or disabled this feature before upgrading to this release. - -### Migration Assistance - -For significant deprecations, migration guides or documentation will be provided to help users transition to newer versions or alternatives. - -## Exceptions - -Special circumstances, such as critical security vulnerabilities, may necessitate immediate action beyond this policy. Any exceptions will be communicated transparently and promptly. diff --git a/docs/dev_workflow.png b/docs/dev_workflow.png deleted file mode 100644 index 9621e59914..0000000000 Binary files a/docs/dev_workflow.png and /dev/null differ diff --git a/docs/developing.md b/docs/developing.md deleted file mode 100755 index 125039db51..0000000000 --- a/docs/developing.md +++ /dev/null @@ -1,216 +0,0 @@ -## Developer Workflow - -- [Introducing a new package](#introducing-a-new-package) -- [Local Chart](#local-chart) -- [Upstream Chart Types](#upstream-chart-types) -- [Making Changes To Packages](#making-changes-to-packages) -- [Rebasing An Existing Package](#rebasing-an-existing-package) -- [Versioning Packages](#versioning-packages) -- [Version](#version) -- [PackageVersion](#packageversion) -- [Updating Dependencies And Subcharts](#updating-dependencies-and-subcharts) -- [Making Changes to Released Charts](#making-changes-to-released-charts) -- [Troubleshooting](#troubleshooting) - - -### Introducing a new package - -Introducing a new package usually requires two things: creating a directory under `packages` and filling in a `package.yaml`. - -The following utility script can be used to create the necessary `package.yaml` file in the right location: - -```shell -PACKAGE= # can be nested, e.g. rancher-monitoring/rancher-windows-exporter is acceptable -mkdir -p packages/${PACKAGE} -touch packages/${PACKAGE}/package.yaml -``` - -Once the `packages/${PACKAGE}/package.yaml` file has been created, you will need to fill it in. A full explanation of the expected fields in the `package.yaml` can be found under [docs/packages.md](./packages.md); however, here are some simple common configurations you can use: - -#### Local Chart - -```yaml -url: local -# Depending on your organization, one of the following two fields might also need to be provided -# version: x.y.z -# packageVersion: 1 -``` - -*Note: For local charts, you will also need to commit the Helm chart itself under `packages/${PACKAGE}/charts`.* - -#### Upstream Chart Types - -From a Git Repository - -```yaml -url: https://github.com/ORG/REPO.git -commit: xXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxXxX -subdirectory: charts/mychart # optional -# Depending on your organization, one of the following two fields might also need to be provided -# version: x.y.z -# packageVersion: 1 -``` - -From a Chart Archive - -```yaml -url: https://github.com/ORG/REPO/releases/download/VERSION/CHART.tgz -subdirectory: charts/mychart # optional -# Depending on your organization, one of the following two fields might also need to be provided -# version: x.y.z -# packageVersion: 1 -``` - -### Making Changes To Packages - -As a developer making changes to a particular package, you will usually follow the following steps: - -0. If you are working with a single `Package`, set `export PACKAGE=` - - Note: This informs the scripts that you only want to make changes to a particular package. This will prevent the scripts from running commands on every package in this repository. - - Note: Starting v0.3.0 of the scripts, `PACKAGE` can refer to a nested structure, e.g. you can place packages under `packages/my-stuff/package-1` and `packages/my-stuff/package-2`. If you want to target all packages in this nested structure, set `PACKAGE=my-stuff`. If you want to target a specific package in this nested structure, set `PACKAGE=my-stuff/package-1`. It should be noted, however, that `make patch` will **only** work if you point to a specific package, so setting `PACKAGE=my-stuff` would cause it to fail. -1. If necessary, update the `version` or `packageVersion` field in the `package.yaml`. Then run `make charts` and commit the changes. - - Note: It is recommended that your commit message says something along the lines of `Bump ${PACKAGE} version to ${NEW_VERSION}`. -2. Run `make prepare`. This will produce a chart under `packages/${PACKAGE}/charts` that will serve as your working copy of the chart. -3. Make modifications **directly** to the working copy of the chart in `packages/${PACKAGE}/charts`. - - Note: **Do not modify `charts/${PACKAGE}/${CHART}/${VERSION}/` directly** since it will be overridden by changes to `packages/${PACKAGE}/charts`. -4. When you are happy with your changes, run `make patch`. This will automatically construct a `packages/${PACKAGE}/generated-changes` directory after assessing your current working directory in `packages/${PACKAGE}/charts`. - - Note: **You should never directly modify `packages/${PACKAGE}/generated-changes`** unless you are trying to change `packages/${PACKAGE}/generated-changes/dependencies` to update your chart dependencies. This directory is automatically constructed / destroyed by `make patch` to save the least amount of information necessary to reconstruct your working directory on a `make prepare`. -5. Run `make clean` to clean up your working directory. Then, commit your changes to Git with a commit message that indicates what you have changed. - - Note: **To avoid losing unsaved changes, do not run `make clean` unless you have already ran `make patch`.** `make clean` will delete the `packages/${PACKAGE}/charts` directory, so any modifications you made to the working copy of the chart will be lost. -6. To test your changes, run `make charts`. This will automatically create an `assets/${PACKAGE}/${CHART}-${VERSION}.tgz`, the `charts/${PACKAGE}/${CHART}/${VERSION}/` directory, and create or modify an existing `index.yaml`. Commit these changes to Git, usually with a commit titled `make charts`. - - Note: If you push the `make charts` commit to a repository, that repository would be a valid Helm repository to serve your chart. - -If you need to make additional changes after testing, repeat steps 2-6. - -If your repository is configured to use upstream validation (e.g. check if `validation.url` and `validation.branch` is specified in the root `configuration.yaml`), you will also need to add this new chart's name and version to the `release.yaml` or else you will fail CI. If you run `make validate` locally, it will automatically generate this file for you. - -For more information on how to do this or why this is required, please see [`docs/validation.md`](validation.md). - -Otherwise, you are ready to make a PR! - -### Rebasing An Existing Package - -For forked charts only (e.g. any chart where the `package.yaml` does not have `url: local`), currently the scripts do not have good support for rebasing charts to a new upstream. - -The reason why this is the case is that the patch files defined under `packages/${PACKAGE}/generated-changes/patch/*` are based on the old upstream, so when you change the URL it is unable to reconcile how to apply the patch. - -Therefore, the best way to currently rebase is to follow the following workflow: - -0. Set `PACKAGE=` pointing to the specific package you want to work with. -1. If the chart has not been released yet, delete your existing charts, assets, and `index.yaml` entries corresponding to the chart you are rebasing by running `CHART= VERSION= make remove` for each chart (e.g. if you have a chart that also packages a CRD chart, you will need to run `make remove` twice for the main chart and the CRD chart). Then, commit your changes to Git with a commit message that says "Remove charts/assets for " -2. Without making any other changes, run `make prepare`. This will apply your existing patches on your existing upstream to produce `packages/${PACKAGE}/${workingDir}` (usually `packages/${PACKAGE}/charts`). -3. Modify the `package.yaml` to point to your new upstream. -4. Run `make patch`. This will destroy the current contents of `packages/${PACKAGE}/generated-changes` and reconstruct everything as if you were patching the new upstream with your **existing** chart. -5. Run `make clean`. Then, commit your changes to Git with a commit message that says "Rebase from to "; this will make it easier for reviewers to see what you actually introduced in the next commit. -6. Follow the same developer workflow as defined under `Making Changes to Packages` to change the version, add back in changes introduced by upstream, and generate charts / assets. - -Once these steps are compplete, you should have something similar to the following four commits: -1. "Remove charts/assets for " -2. "Rebase from to " -3. "Add changes from rebasing to " -4. "make charts" - -As a result, developers reviewing your chart can see changes made to `packages/` by reviewing changes between commit 2 and commit 3; they can also inspect changes introduced to `charts/` by viewing the overall diff on the PR, since the old assets will show as renamed / modified. - -You are ready to make a PR! - -### Known Issue: Making Changes to the Version of an Existing Package - -If you are working with a repository using `charts-build-scripts` that uses remote validation (e.g. `validate.url` and `validate.branch` are provided in the `configuration.yaml`) and you are making a change that would modify the version of an existing package (e.g. replacing a version like `0.1.2-rc3` with `0.1.2-rc4`), please see the section `Modifying Chart Versions That Exist In Upstream` within [`docs/validation.md`](validation.md) for how to ensure CI still passes after making your change. - -### Versioning Packages - -Generally, repositories that are using `charts-build-scripts` use one of the following two types of built-in versioning schemes for packages: - -#### Version - -This versioning scheme is used if `version` is specified in the `package.yaml`. - -If a valid semver for `version` is provided, the final version of the chart will be the same as the `version` provided. - -The only caveat is that **if** the main chart corresponds to some upstream chart whose chart version is not the same as the `version` provided, then the upstream version will be appended as a build annotation following the pattern `+up`. - -*e.g. If `version` is 100.0.0 and the upstream chart's version is `1.2.3`, the final version will be `100.0.0+up1.2.3`.* - -#### PackageVersion - -This versioning scheme is used if `packageVersion` is specified in the `package.yaml`. - -If a two-digit `packageVersion` is provided, the final version of the chart that is produced under the generated assets will be the same as the version specified by the main chart in the package, except the patch version of will be `int(originalPatchVersion * 100 + packageVersion)`. - -Examples: -- If the main chart version is `1.2.3` and the packageVersion is `1`, the final chart version will be `1.2.301`. -- If the main chart version is `1.2.3` and the packageVersion is `56`, the final chart version will be `1.2.356`. -- If the main chart version is `2.1.0` and the packageVersion is `12`, the final chart version will be `2.1.12`. - - *Note: It is not `2.1.012` since a leading zero in the patch version is invalid semver.* - -##### When should I update the packageVersion? - -You should generally update the `packageVersion` **once per release**. - -If the chart version you are currently modifying has already been released before, you should **bump the `packageVersion` by 1** to ensure you aren't modifying an already released chart. - -*e.g. if chart version `1.2.301` is released, bumping the `packageVersion` to `2` will result in `1.2.302` being released next.* - -If the chart version you are currently modifying has never been released before, you should **reset the `packageVersion` to 1**. - -*e.g. if chart version `1.2.301` is released, but you are currently working on releasing a package based on `1.3.0`, you should reset the `packageVersion` to `1` to release `1.3.1`.* - -*Note: You should reset the packageVersion to 1 instead of 0 since the scripts will always introduce at least one change to the chart.* - -### Updating Dependencies and Subcharts - -The scripts used to maintain this repository natively supports managing dependencies / subcharts for Helm charts. - -Subcharts can be added by creating a file under `packages/${PACKAGE}/generated-changes/dependencies/${SUBCHART}/dependency.yaml`. - -The following utility script can be used to create the necessary `dependency.yaml` file in the right location: - -```shell -PACKAGE= -SUBCHART= -mkdir -p packages/${PACKAGE}/generated-changes/dependencies/${SUBCHART} -touch packages/${PACKAGE}/generated-changes/dependencies/${SUBCHART}/dependency.yaml -``` - -Once the `dependency.yaml` file has been created, you will need to fill it in. The `dependency.yaml` supports a **subset** of `package.yaml` fields (namely, those associated with `UpstreamOptions`; i.e. you can specify local charts, GitHub Repositories, or Chart Archives). More information on UpstreamOptions can be found in [docs/packages.md](./packages.md). - -Once declared, `make prepare` will automatically pull in your dependency under `packages/${PACKAGE}/charts/charts` and add a corresponding entry to the `packages/${PACKAGE}/charts/Chart.yaml` (or `requirement.yaml`, for Helm charts using the older `apiVersion: v1`). You will also be able to patch your dependency from there as if it was part of the original main chart. - -*Note: The name of your subchart, and the alias you can use to override settings of your subchart from the main chart, will be dependent on the name of the directory you place the `dependency.yaml` in. For example, if you created your `dependency.yaml` under `packages/mypackage/generated-changes/dependencies/mydep/dependency.yaml` and ran `PACKAGE=mypackage make prepare`, all subchart settings will be located under the main chart's `values.yaml` under `mydep.*` (e.g. `mydep.enabled`), even if the chart `mydep` points to is named something else.* - -*Note: A common practice for managing dependencies via these scripts is to keep the actual patches on the dependency in a separate package and refer to it in your main chart. To take this approach, declare your dependency as a separate packages under `packages/${DEPENDENCY}` and simply specify `url: packages/${DEPENDENCY}` in the `dependency.yaml` of your main chart. Then, on a `make prepare`, it will prepare the dependency's package first and pull it in on trying to prepare the main chart. It should also be noted that it is the developer's responsibility to ensure that no cyclical dependencies are introduced in this fashion.* - -*Note: if you manage a dependency as a separate package, it's often a good idea to set `doNotRelease: true` on that dependency package's `package.yaml` to indicate that the dependency should not be independently released. This prevents `make charts` from generating assets for the dependency, since it will already be packaged directly into your main chart.* - -*Note: When adding net-new dependencies, a PR must first be raised and merged in the `rancher/Rancher` repository with the required updates to the `rancher/pkg/image/origins.go` file. This file must be updated with the name of the dependency (without any version information) and the Github repository URL from where the image originates from. This information is used to generate an artifact during Rancher releases, and failure to provide it will interfere with Rancher's CI. This file does not need to be updated when bumping versions of released dependencies.* - -#### Known Issue: Managed Files - -In any Helm chart managed by these scripts, we consider the `Chart.yaml` / `requirements.yaml` to be `Managed Files` since they are the only files that end up going through a three-way merge. - -Specifically, the three-way merge occurs because there are three parties involved in applying changes on a `make prepare`: -1. The upstream chart source, which provides the base `Chart.yaml` / `requirements.yaml` -2. The scripts themselves, which make changes to support adding in dependencies based on those specified under `generated-changes/dependencies`. -3. The user, who commits patches to those files after running `make patch` - -As a result, on updating dependencies for charts, these files are prone to having conflicts. - -The only workaround for this issue is to delete the patch files manually (e.g. `rm packages/${PACKAGE}/generated-changes/patch/Chart.yaml.patch` and/or `rm packages/${PACKAGE}/generated-changes/patch/requirements.yaml.patch`), run `make prepare`, and redo the patches you added to these files manually. - -### Making Changes to Released Charts - -If a chart version that you want to make changes to has already been released (i.e. the chart already exists in `charts/`, `assets/` and `index.yaml` and the `Package` that was tracking that chart version has moved on to a future version), you will usually follow the following steps: - -1. Make the change directly to the `charts/{chart}/{version}` files -2. Run `make zip` to automatically zip up `charts/{chart}/{version}` -> `assets/{chart}-{version}.tgz` and update the `index.yaml`. This might also introduce some changes to `charts/{chart}/{version}`, such as when you add an annotation to `charts/{chart}/{version}/Chart.yaml` that needs to be re-ordered alphabetically. - -In addition, if your repository is configured to use upstream validation (e.g. check if `validation.url` and `validation.branch` is specified in the root `configuration.yaml`), you will also need to add this modified chart's name and version to the `release.yaml` or else you will fail CI. If you run `make validate` locally, it will automatically generate this file for you. - -For more information on how to do this or why this is required, please see [`docs/validation.md`](validation.md). - -Otherwise, you are ready to make a PR! - -### Troubleshooting - -Open up an issue on [https://github.com/rancher/charts-build-scripts](https://github.com/rancher/charts-build-scripts). diff --git a/docs/experimental.md b/docs/experimental.md deleted file mode 100755 index 5601871443..0000000000 --- a/docs/experimental.md +++ /dev/null @@ -1,44 +0,0 @@ -## Experimental - -- [Caching](#caching) -- [Using Manifest Upstreams Instead of Helm Charts](#using-manifest-upstreams-instead-of-helm-charts) -- [Performing only local or upstream validation](#performing-only-local-or-upstream-validation) - -### Caching - -If you specify `export USE_CACHE=1` before running the scripts, a cache will be used that is located at `.charts-build-scripts/.cache`. This cache is only used on `make prepare`, `make patch`, and `make charts`; it is intentionally disabled on `make validate`. - -This cache will be used to store references to anything that is pulled into the scripts (e.g. anything defined via `UpstreamOptions`, such as your upstream charts). If used, the speed of the above three commands may dramatically increase since it is no longer relying on making a network call to pull in your charts from the given cached upstream. - -However, currently caching is only implemented for `UpstreamOptions` that point to a GitHub Repository at a particular commit, since that is an immutable reference (e.g. any amends to that commit would result in a brand-new commit hash). - -If you would like to clean up your cache, either delete the `.charts-build-scripts/.cache` directory or run `make clean-cache`. - -### Using Manifest Upstreams Instead of Helm Charts - -If your package.yaml points to an upstream that does not declare a Chart.yaml, the default behavior of the scripts is as follows: -1) Move all YAML files to `templates` -2) Create a dummy, hard-coded `Chart.yaml`: - -```yaml -apiVersion: v2 -appVersion: 0.1.0 -description: A Helm chart for Kubernetes -name: my-helm-chart -type: application -version: 0.1.0 -``` - -This will be applied on the upstream chart before applying `make patch`, which means that the `generated-changes/patch/Chart.yaml.patch` represents changes you introduce on top of this dummy, hard-coded `Chart.yaml`. As a result, you can proceed to make changes such as adding dependencies, adding annotations, etc. - -Note: This feature is marked as experimental since it's unclear if there are any additional requirements necessary to support edge cases around pulling upstream manifests. Please open up an issue on [https://github.com/rancher/charts-build-scripts](https://github.com/rancher/charts-build-scripts) if you have any suggestions! - -### Performing only local or upstream validation - -In order to make it easier to debug issues related to a failure in `make validate`, two command-line flags were introduced. - -If you would like to perform local validation only (e.g. checking if `make charts` produces no changes), you can run `./bin/charts-build-scripts validate --local`. - -If you would like to perform remote validation only (e.g. checking if all differences between your current repository and an upstream repository are tracked in the `release.yaml`), you can run `./bin/charts-build-scripts validate --upstream`. - -Note: These options have **not** been exposed as environment variables since an average consumer of the scripts should rarely, if at all, have any reason for using these options. diff --git a/docs/makefile.md b/docs/makefile.md deleted file mode 100755 index 484d8faf9d..0000000000 --- a/docs/makefile.md +++ /dev/null @@ -1,59 +0,0 @@ -## Makefile - -- [Basic Commands](#basic-commands) -- [Package Commands](#package-commands) -- [Assets, Chart, and Index Commands](#assets,-chart,-and-index-commands) -- [CI Commands](#ci-commands) -- [Docs and Scripts Commands](#docs-and-scripts-commands) -- [Advanced Commands](#advanced-commands) - -### Basic Commands - -`make pull-scripts`: Pulls in the version of the `charts-build-scripts` indicated in scripts. - -### Package Commands - -`make prepare`: Pulls in your charts from upstream and creates a basic `generated-changes/` directory with your dependencies from upstream. By default, this prepares every `Package` in your repository, but it can be scoped by providing `PACKAGE=`, where `packagePrefix` can either be 1) the exact folder in which a `package.yaml` resides in `packages/` or 2) a directory that contains multiple directories with `package.yaml` files; in the latter case, all packages in that prefix will be prepared. *If you are working with a local chart with no dependencies, this command does nothing.* - -`make patch`: Updates your `generated-changes/` to reflect the difference between upstream and the current working directory of your branch (note: this command should only be run after `make prepare`). Unlike `make prepare`, `PACKAGE=` must point to an exact folder in which a `package.yaml` resides in `packages/`. *If you are working with a local chart with no dependencies, this command does nothing.* - -`make clean`: Cleans up all the working directories of charts to get your repository ready for a PR. Supports `PACKAGE=` as defined above. *If you are working with a local chart with no dependencies, this command does nothing.* - -`make charts`: Runs `make prepare` and then exports your charts to `assets/` and `charts/` and generates or updates your `index.yaml`. Supports `PACKAGE=` as defined above. - -Please see [`docs/developing.md`](developing.md) for more information on how to use these commands in a normal developer workflow. - -### Assets, Chart, and Index Commands - -`make index`: Reconstructs the `index.yaml` based on the existing charts. Used by `make charts` and `make validate` under the hood. - -`make remove`: Removes the asset and chart associated with a provided chart version. Performs the equivalent of an `rm -rf` on the provided `CHART=` and `VERSION=` entries and runs `make index`. - -`make zip`: Reconstructs archives in the `assets` directory based on the current contents in `charts` and updates the `charts/` contents based on the packaged archive(s). Can be scoped to specific charts via specifying `CHART={chart}` or `CHART={chart}/{version}`. Runs `make index` after reconstruction. - -Please see [`docs/developing.md`](developing.md) for more information on how to use these commands to modify released charts. - -### CI Commands - -`make validate`: Checks whether all generated assets used to serve a Helm repository (`charts/`, `assets/`, and `index.yaml`) are up-to-date. If `validate.url` and `validate.branch` are provided in the configuration.yaml, it will also ensure that any additional changes introduced only modify chart or package versions specified in the `release.yaml`; otherwise it will output the expected `release.yaml` based on assets it detected changes in. - -Please see [`docs/validation.md`](validation.md) for more information on how CI is performed. - -### Docs and Scripts Commands - -`make template`: Updates the current directory by applying the configuration.yaml on [upstream Go templates](https://github.com/rancher/charts-build-scripts/tree/master/templates/template) to pull in the most up-to-date docs, scripts, etc. from [rancher/charts-build-scripts](https://github.com/rancher/charts-build-scripts). - -### Advanced Commands - -`make list`: Prints the list of all packages tracked in the current repository and recognized by the scripts. `export PORCELAIN=1` allows you to specify that the output of this command should be script-friendly. - -`make unzip`: Reconstructs all charts in the `charts` directory based on the current contents in `assets`. Can be scoped to specific charts via specifying `ASSET=` or `ASSET=/-.tgz`. Runs `make index` after reconstruction. - -`make standardize`: Takes an arbitrary Helm repository (defined as any repository with a set of Helm charts under `charts/`) and standardizes it to the expected repository structure of these scripts. - -`make clean-cache`: Deletes `.charts-build-scripts/.cache`. Only used if `export USE_CACHE=1` is set, which indicates that you are using the experimental caching feature introduced in v0.3.0 of the scripts. Please see [`docs/experimental.md`](experimental.md) for more information. - -`BRANCH_VERSION="<2.X>" CHART="" DEBUG="" make enforce-lifecycle`: Lists all assets versions and then starts to remove older versions with `make remove` enforcing the rules defined at: [New Assets Lifecycle](../README.md#new-assets-lifecycle). -If run without specifying `CHART=`, will enforce lifecycle rules in all charts. - -`BRANCH_VERSION="<2.x>" CHART="" make lifecycle-status`: Analyzes the state of the current branch, analyzes the state of the official development and production branches for the given branch version, saves everything to logs on `logs/` folder. \ No newline at end of file diff --git a/docs/packages.md b/docs/packages.md deleted file mode 100755 index dece6033d8..0000000000 --- a/docs/packages.md +++ /dev/null @@ -1,81 +0,0 @@ -## Packages - -- [What is a Package?](#what-is-a-package?) -- [UpstreamOptions](#upstreamoptions) -- [Additional Charts CRD Options](#additional-charts-crd-options) -- [Directory Structure](#directory-structure) - - -### What is a Package? - -A Package represents a grouping of one or more Helm Charts. It is declared within `packages//package.yaml` with the following spec: - -```text -version: # The version of the generated chart. This value will override the upstream chart's version. Mutually exclusive with packageVersion -packageVersion: 1 # The value range is from 1 to 99. Mutually exclusive with version -workingDir: # The directory within your package that will contain your working copy of the chart (e.g. charts) -url: # A URL pointing to an UpstreamConfiguration -subdirectory: # Optional field for a specific subdirectory for all upstreams -commit: # Optional field for a specific commit if your URL point to a Github Repository -doNotRelease: # Optional field to specify that this chart should not produce any generated changes on running `make charts`. -additionalCharts: -# These contain other charts that you would like to package alongside this chart -- workingDir: # same as above - upstreamOptions: - url: # same as above - subdirectory: # optional, same as above - commit: # optional, same as above - crdOptions: - templateDirectory: # A directory within packages//template that will contain a template for your CRD chart - crdDirectory: # Where to place your CRDs within a CRD chart (e.g. crds for default charts) - addCRDValidationToMainChart: # Whether to add additional validation to your main chart to check that the CRD chart is installed. -``` - -As seen in the spec above, every Package must have exactly one Chart designated as a main Chart (multiple main Charts are not supported at this time) and all other Charts will be considered AdditionalCharts. - -#### UpstreamOptions - -Charts or AdditionalCharts can provide UpstreamOptions with the following possible configurations: -- Chart Archive: provide the `url` and optionally `subdirectory` -- Github Repository: provide the `url` (e.g. `https://github.com/rancher/charts-build-scripts.git`) and optionally a `subdirectory` and a `commit` -- Package: provide a `url: packages/` and the main Chart from that package can be pulled. You should ensure that a loop is not introduced. -- Local: provide `url: local` and the package will assume the contents of `workingDir` are exactly the chart you want to use. - -#### Additional Charts CRD Options - -AdditionalCharts can provide CRDOptions instead of or in addition to -UpstreamOptions. These CRDOptions allow the scripts to automatically construct a -CRD chart from your main Chart's contents based on the template provided. - -A CRD Chart is a Helm Chart whose sole purpose is to install CRDs onto a cluster before the main Chart is installed. - -You should not need a CRD chart if your main chart has the following qualities: -1) Your main chart does not install any CRDs. -2) Even if your main chart installs CRDs, it never installs resources of that kind as part of the release. In this case, CRDs can just remain in your `templates/` directory to be managed by Helm. -3) Neither option from above applies to you, but you do not need to facilitate automatically upgrading CRDs or providing a way for a user to cleanly delete CRDs via a second Helm release. In this case, the current Helm feature of having your CRDs placed in the `crds/` directory should work for you. - -### Directory Structure - -```text -packages/ - / - package.yaml # A file that represents your package's overall configuration - generated-changes/ - additional-charts/ - # Contains one directory per additional chart, keeping track of its dependencies and patches - / - generated-changes/ - # Same as above, but no more additionalCharts - dependencies/ - # Contains one directory per dependency. - - dependency.yaml # The UpstreamConfiguration of a particular dependency - exclude/ - # Files that were excluded from upstream verbatim. Follows the same directory structure as the chart - overlay/ - # Files that were overlaid onto upstream verbatim. Follows the same directory structure as the chart - patch/ - # Files that were patches from upstream. Follows the same directory structure as the chart and contains Unified Unix Diffs - templates/ - # Contains any templates. Currently only used by CRDOptions -``` diff --git a/docs/validation.md b/docs/validation.md deleted file mode 100755 index 5000e906cb..0000000000 --- a/docs/validation.md +++ /dev/null @@ -1,80 +0,0 @@ -## Validation - -- [Repository CI Validation](#repository-ci-validation) -- [What is the release yaml file](#what-is-the-release-yaml-file) -- [Modifying Chart Versions That Exist In Upstream](#modifying-chart-versions-that-exist-in-upstream) - -### Repository CI Validation - -In order to provide a way for CI to ensure that the current state of a repository is valid and all necessary commits that produce generated changes have been run by developers, `make validate` runs a series of checks on a clean Git repository. - -Specifically, the workflow used by `make validate` does the following: -1. Ensure Git is clean; if not, fail. -2. Run `make charts`; if Git is no longer clean, fail and leave behind the assets. -3. **Only if `validate.url` and `validate.branch` are provided in the `configuration.yaml`**, pull in the specified Git repository, standardize the repository, and check each asset: - - For any assets that exist in upstream, check if it is modified or does not exist in local. If so, copy it over, unzip it, and fail. - - For any assets that exist in local but not in upstream, check if it corresponds to an entry in the `release.yaml`; if not, fail. -4. Run `make unzip`; if Git is no longer clean, fail. - -### What is the release yaml file - -The `release.yaml` is only specified if `validate.url` and `validate.branch` are provided in the repository's `configuration.yaml`. It is created automatically if you run `make validate`, which will produce a list of assets that have been modified based on your upstream repository. - -When a GitHub repository is provided for this repository to validate against, the scripts ensure that any changes introduced to the current repository make **no additions, modifications, or deletions** to the upstream repository's `charts/`, `assets/`, or `index.yaml`. - -**However, if this were the case always, we would not be able to add charts or make modifications to existing charts!** - -Therefore, to signal to the scripts that you are adding a new chart to upstream, making a modification to an existing chart, or removing a chart, you will need to specify the versions under `${CHART}`. - -For example: - -```yaml -: -- -- -- -- ... -rancher-monitoring: -- 100.0.0+up16.6.0 -rancher-monitoring-crd: -- 100.0.0+up16.6.0 -fleet: -- 100.0.0+up0.3.6 -fleet-agent: -- 100.0.0+up0.3.6 -fleet-crd: -- 100.0.0+up0.3.6 -longhorn: -- 100.0.0+up1.1.2 -- 100.0.0+up1.2.0 -longhorn-crd: -- 100.0.0+up1.1.2 -- 100.0.0+up1.2.0 -``` - -### Modifying Chart Versions That Exist In Upstream - -One of the caveats with using the `release.yaml` is that **renames are not supported** (e.g. you cannot remove and replace a chart in a single step). - -As a result, if you attempt to modify a version of a chart that already exists in upstream, **both the old version and the new version must exist in the release.yaml for CI to pass**. Once the changes have been merged, you can later remove the old version from the release.yaml (usually as part of a release process). - -To give a concrete example of such a scenario, let's say that you have currently committed `my-chart` version `0.1.2-rc3`. You then take the following steps: -1. You modify the `package.yaml` to point at a new upstream URL that points to `0.1.2-rc4` and resolve any conflicts with the patch files under `packages/my-chart-package/generated-changes` -2. You run `CHART=my-chart VERSION=0.1.2-rc3 make remove` to delete the older version of the chart -3. You run `make charts` to produce the new assets and charts for `my-chart` version `0.1.2-rc4`. -4. You modify the release.yaml to **replace** `my-chart[0] = 0.1.2-rc3` with `my-chart[0] = 0.1.2-rc4`. -5. You make a PR to your repository. - -In this case, CI will fail since you are attempting to remove `0.1.2-rc3` but it is not tracked in the `release.yaml`. - -Therefore, the correct resolution would be to leave your `release.yaml` as: - -```yaml -... -my-chart: -- 0.1.2-rc3 -- 0.1.2-rc4 -... -``` - -That way, both the removal of `0.1.2-rc3` and the addition of `0.1.2-rc4` are accepted. Later, you can remove `0.1.2-rc3` once the PR has been committed.