Support defining image paths for HelmReleases

[hiddeco]

This commit adds support for supplying image paths for HelmRelease
resources through annotations, and introduces a new alias for image
tag filters.

For an image mapping to be valid, the image path must be defined
and may be supplemented by a tag and/or registry path. In case
the combination of resolved values does not result in a valid image
ref, the mapping will be ignored.

Supported annotations:

registry.fluxcd.io/<alias>: <registry path>
repository.fluxcd.io/<alias>: <image path>
tag.fluxcd.io/<alias>: <tag path>
filter.fluxcd.io/<alias>: <tag filter>

Image mappings are composed by <alias>.

A valid annotation mapping is for example:

annotations:
  registry.fluxcd.io/container: some.custom.registry
  repository.fluxcd.io/container: some.custom.image
  tag.fluxcd.io/container: some.custom.tag
  filter.fluxcd.io/container: glob: master-*

  repository.fluxcd.io/anotherone: depth.knows.no.limits.image

which would map the image for the following values structure:

values:
  some:
    custom:
      registry: docker.io
      image: fluxcd/flux-prerelease
      tag: master-abcdefg
  depth:
    knows:
      no:
        limits:
          image: fluxcd/helm-operator:0.10.0

This PR is in need of squaremo/kubeyaml#11 squaremo/kubeyaml#14 to persist the actual changes to git.

Fixes: #1262

[2opremio]

Where, container a parameter, right? (i.e. does the scheme support multiple containers?)

The use of subdomains (as opposed to e.g. a path) to denote what you are specifying seems a bit funky, but we probably can't do better due to the restrictions of the annotation syntax imposed by k8s.

Maybe we could add another subdomain to make it more clear? e.g.
tag.pathspec.flux.weave.works?

[hiddeco]

Where, container a parameter, right? (i.e. does the scheme support multiple containers?)

container in this case is just an alias for your collection of mappings (it represents one image definition), it can be any string and multiple mappings can be defined.

The use of subdomains (as opposed to e.g. a path) to denote what you are specifying seems a bit funky, but we probably can't do better due to the restrictions of the annotation syntax imposed by k8s.

Correct, this is the most Kubernetes native approach to defining the mapping and is conform their specifications for annotations.

Maybe we could add another subdomain to make it more clear? e.g.
tag.pathspec.flux.weave.works?

Can not decide if the clarity improvement would weight up to the annoyance of a really long annotation key.

[squaremo]

Mostly just suggestions. One item that does need a revision, or a rebuttal: shouldn't SetWorkloadContainerImage fail if it finds annotations but can't make sense of them?

[squaremo]

Does this mean the mapper stuff above can be removed?

[hiddeco]

Above where? Quite a lot of 'mapper' things on this page...