feat(helm-promotion): allow arbitrarily updating a key from a yaml file with the new helm chart version

[CCOLLOT]

When promoting images, we can use the following directive:

  - uses: helm-update-image
    as: update-image
    config:
      path: ./path/to/values.yaml # arbitrary filename
      images:
        - image: <image-name>
          fromOrigin:
            kind: Warehouse
            name: <warehouseName>
          key: image.Tag # arbitrary key
          value: Tag

I would like to be able to do the same thing with helm charts, without needing a Chart.yaml file. I use an applicationSet to create ArgoCD applications pointing to helm repos based on the content of certain files (containing keys like .chartVersion, .repoURL and .chartName), using the ArgoCD ApplicationSet git-generator.

It could either be achieved by making the helm-update-image directive generic, or by extending the current helm-update-chart directive.

Something like that would do the trick:

Option 1

Introduce a generic directive to update yaml keys based on the supported artifacts

# generic directive
  - uses: helm-update-key # or yaml-update-key
    as: update-key
    config:
      path: ./path/to/file.yaml
      update:
        - type: helm # or image
          chartName: <chartName> # or image
          fromOrigin:
            kind: Warehouse
            name: <warehouseName>
          key: my.yaml.key
          value: Version # may be omitted 

Option 2

Alternatively, we could extend the helm-update-chart directive

# extending helm-update-chart
  - uses: helm-update-chart
    as: update-key
    config:
      path: ./path/to/file.yaml # if not a directory but a yaml file, do not look for Chart.yaml and expect a key to replace
      charts:
      - repository: https://example-chart-repo
         name: some-chart
         fromOrigin:
            kind: Warehouse
            name: <warehouseName>
        key: my.yaml.key # used only if config.path points to a yaml file and not a directory
        value: Version # may be omitted
    path: ./src/charts/my-chart

Option 2 seems like a minor change that would make the helm-update-chart as flexible as helm-update-image. I'm open to contributing if necessary

[krancour]

I support the notion generically updating any key in any YAML file with any value, however, I'd like to hold off on this until we have support for some kind of expression language, which is on the roadmap, and should happen in the v1.1 timeframe or so.

As things stand currently, the options are to add more steps or add more configuration options to existing steps and both of those things make Kargo more complicated both for users and to maintain.

Once there is support for some kind of expression language, a truly generic YAML updater will be much easier to achieve and I'd prefer we tackle this then.

[CCOLLOT]

I agree with you on the end-solution, leveraging an expression language to produce a generic YAML updater. Updating any YAML key is a critical feature for us in adopting Kargo, as we try to get Chart.yaml files away from developers in favor of simplified YAML files + git-generator.

Admittedly, it would become obsolete with the addition of a generic YAML updater, but so would the helm-image-updater.

If the project supports flexible updates for images, I believe it should support it for the other artifact type (helm chart), and if one were to be deprecated, so should the other.

For example, Crossplane started deprecating its native patch-and-transform or environmentConfigs "statements" in favor of functions way after the major 1.0.0, and they were still implementing features in the native "statements" until very recently. As long as the transition is made easy for users (battle-tested expression-language-based directives + comprehensive documentation), I don't think it's a big deal.

In the meantime, Kargo's higher-level directives (since directives are similar to GitHub actions, I guess we are talking about something like reusable actions) are yet to be implemented, and so is the expression language.

[CCOLLOT]

In the meantime I have made a working patch implementing option 2. I understand if you prefer to wait for the final solution but let me know if you change your mind

[krancour]

EL is coming sooner than later, so I'd like to wait for that.