Feature/allow empty helm.image-name annotation

[will4j]

In case when only image tag is required to update, like:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
...
  annotations:
    argocd-image-updater.argoproj.io/image-list: app=harbor.example.com/nginx
    argocd-image-updater.argoproj.io/app.helm.image-tag: image.tag
    argocd-image-updater.argoproj.io/app.update-strategy: newest-build
    argocd-image-updater.argoproj.io/app.allow-tags: regexp:^sha-[0-9a-f]{7}$
    argocd-image-updater.argoproj.io/write-back-target: helmvalues

It make no sense to let argocd-image-updater.argoproj.io/app.helm.image-name annotation mandatorily, either I have to fill a fake image name value, still it produces meaningless configs in target .argocd-source or helm value files.

By this pr, I Supposed to get values.yaml file like

image:
  registry: harbor.example.com
  repository: nginx
  tag: "sha-xxxx"

instead of

image:
  registry: harbor.example.com
  name: harbor.example.com/nginx # which actually not used
  repository: nginx
  tag: "sha-xxxx"

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 63.53%. Comparing base (cc9f71b) to head (334f575).
⚠️ Report is 57 commits behind head on master-annotation-based.

Additional details and impacted files

@@                     Coverage Diff                     @@
##           master-annotation-based    #1211      +/-   ##
===========================================================
+ Coverage                    63.52%   63.53%   +0.01%     
===========================================================
  Files                           23       23              
  Lines                         3191     3192       +1     
===========================================================
+ Hits                          2027     2028       +1     
  Misses                        1054     1054              
  Partials                       110      110              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[chengfang]

when image-name annotation is absent, it defaults to image.name. That's why there is an extra image.name fields generated in your values file. But if you specify it with the following, the expected fields will be updated.

argocd-image-updater.argoproj.io/app.helm.image-name: image.repository

The above tells image updater to use image.repository field for image name.

See https://argocd-image-updater.readthedocs.io/en/stable/configuration/images/#specifying-helm-parameter-names

[chengfang]

see similar discussion: #1189

[will4j]

see similar discussion: #1189

The point is app.helm.image-name annotation is not required in my situation, even if I make it with argocd-image-updater.argoproj.io/app.helm.image-name: image.repository, it will not work as expected, it will generate values file like:

image:
  registry: harbor.example.com
  repository: harbor.example.com/nginx
  tag: "sha-xxxx"

exactly the same problem as mentioned in discussion: #1189

[chengfang]

Can you update the relevant sections of docs to reflect the new behavior?

Can you also add tests to verify the content of helm values when missing image-name annotation?

[chengfang]

Can you also update the docs file: docs/configuration/images.md, e.g., around line 359, to describe the new behavior, that if the <image_alias>.helm.image-tag annotation is set but <image_alias>.helm.image-name annotation is not set, image updater will update the image tag value in the target helm values file, without updating the image name value.

[will4j]

@chengfang I'm reconsidering the situation that image.name is the default value of anntotation helm.image-name， which used in both UpdateApplication flow and marshalParamsOverride flow. currently, this pr only handle marshalParamsOverride flow with helmvalues but marshalParamsOverride with default target (which is .argocd-source-*.yaml file) keeps unchanged. I'm not sure if this inconsistent will cause new problem, in addition, I have to confirm that this pr will not affect the UpdateApplication flow. After solving these uncertainty, I will update the doc files.