seaneagan
commented
3 years ago Items 2. and 3. are definitely needed so we can deploy without reaching out to external helm repositories. For item 1. during the CI process (master branch) it may prove difficult to both update the helm-chart-collator input (charts.yaml) and use the output (image) in a single commit, since it will need to be stored somewhere (likely quay.io) before it can be referenced/used, unless we can create a local docker repository to store it in or something. So I am not sure how we can get around needing two commits: 1) Update charts.yaml (CI pushes to quay.io on merge) 2) Update treasuremap to use image from 1)
Thus, putting the charts.yaml in treasuremap directly will have the down side of needing to wait for the (expensive) treasuremap gates for both commits, and on the first commit there is really nothing to validate, unless we can do some fancy zuul job trigger file exclusion. It would be nice to keep the charts versions in treasuremap where they will be used, but maybe keeping it in airship/images for now would be simplest. In any case I think we should probably change the name to indicate that it is for use by treasuremap e.g. quay.io/airshipit/treasuremap-helm-charts.
lb4368
Problem description Treasuremap manifests currently use the default
quay.io/airshipit/helm-chart-collator:latestimage. This requires that charts needed by treasuremap (e.g. Dex) be managed in the charts.yaml file in the images repository where the helm-chart-collator is defined and built. It would be better if treasuremap managed its own charts.yaml and created a helm-chart-collator image specific for the needs of treasuremap. This would make it easier to place all charts needed by treasuremap into a single helm-chart-collator repository image to avoid having to access multiple helm repositories during deployment. This may also make it easier for downstream sites to build their own collators using the treasuremap charts.yaml as a base.Proposed change
Potential impacts