Open flozzone opened 2 years ago
+1
+1
hi, my workaround is using app-of-apps pattern (disclamer - the behavior is not ideal as it is randomly removing the tags and adding them again - this is something I want to investigate)
app-of-apps.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: app-of-apps
namespace: argocd
finalizers:
- resources-finalizer.argocd.argoproj.io
annotations:
argocd-image-updater.argoproj.io/write-back-target: kustomization
argocd-image-updater.argoproj.io/image-list: myalias=registry.gitlab.com/...
argocd-image-updater.argoproj.io/myalias.pull-secret: pullsecret:argocd/regcreds
argocd-image-updater.argoproj.io/myalias.force-update: "true"
argocd-image-updater.argoproj.io/write-back-method: git:secret:argocd/image-updater-repocreds
argocd-image-updater.argoproj.io/git-branch: main
spec:
...
source:
repoURL: https://gitlab.com/some/repo.git
targetRevision: HEAD
path: app-prod
destination:
server: https://kubernetes.default.svc
namespace: argocd
syncPolicy:
automated:
selfHeal: true
prune: false
application.yaml
apiVersion: argoproj.io/v1alpha1
kind: Application
...
spec:
...
source:
...
helm:
parameters:
- name: image
value: image_name:image_tag
kustomconfig.yaml - to tell kustomize to overwrite those values use following configuration
# kustomconfig.yaml
images:
- path: spec/source/helm/parameters[]/value
kind: Application
kustomization.yaml
apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
configurations:
- kustomconfig.yaml
Looks interesting! @filiprafaj could you please complete your example, its kind of hard to understand:
@flozzone app-of-apps.yaml is something like this
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
name: app-prod
namespace: argocd
finalizers:
- resources-finalizer.argocd.argoproj.io
annotations:
argocd-image-updater.argoproj.io/write-back-target: kustomization
argocd-image-updater.argoproj.io/image-list: myalias=registry.gitlab.com/...
argocd-image-updater.argoproj.io/myalias.pull-secret: pullsecret:argocd/regcreds
argocd-image-updater.argoproj.io/myalias.force-update: "true"
argocd-image-updater.argoproj.io/write-back-method: git:secret:argocd/image-updater-repocreds
argocd-image-updater.argoproj.io/git-branch: main
spec:
project: prod
source:
repoURL: https://gitlab.com/some/repo.git
targetRevision: HEAD
path: app-prod
destination:
server: https://kubernetes.default.svc
namespace: argocd
syncPolicy:
automated:
selfHeal: true
prune: false
@filiprafaj nice hack but this work around would probably not work if the Helm chart define tags and image as separate values.
Most of the charts write the image structure like this:
image:
repository: nginx
tag: 1.23.1
@filiprafaj nice hack but this work around would probably not work if the Helm chart define tags and image as separate values.
Most of the charts write the image structure like this:
image: repository: nginx tag: 1.23.1
you're right :) I use it only on my own charts
Is there any workaround for this? I am using the helm chart from AWS ECR OCI, and it seems the same error occurs. Argo Image Updater cannot commit to git since it is a helm repo.
time="2022-11-25T15:01:03Z" level=error msg="`git fetch origin --tags --force` failed exit status 128: fatal: '550842083568.dkr.ecr.us-east-1.amazonaws.com' does not appear to be a git repository\nfatal: Could not read from remote repository.\n\nPlease make sure you have the correct access rights\nand the repository exists." execID=8c2ea
time="2022-11-25T15:01:03Z" level=info msg=Trace args="[git fetch origin --tags --force]" dir=/tmp/git-gen5-backend-api-release765755698 operation_name="exec git" time_ms=6.568499
time="2022-11-25T15:01:03Z" level=error msg="Could not update application spec: `git fetch origin --tags --force` failed exit status 128: fatal: '550842083568.dkr.ecr.us-east-1.amazonaws.com' does not appear to be a git repository\nfatal: Could not read from remote repository.\n\nPlease make sure you have the correct access rights\nand the repository exists." application=gen5-backend-api-release
time="2022-11-25T15:01:03Z" level=info msg="Processing results: applications=2 images_considered=2 images_skipped=0 images_updated=0 errors=1"
This issue makes the image updater so bad since we are using helm repo to deploy instead of directly pointing to the Git repo containing the chart manifests
@AnhQKatalon - I worked around this by creating a "local" chart (in the ArgoCD repo) that has the upstream chart as a dependency. I also had to override the image tag and image repository keys to target the dependency.
The override values get created inside the local helm chart directory and Argo applies them.
@filiprafaj - can you please elaborate your setup and solution? Not able to follow. The app of apps is not getting picked up by the image updater as it is of kind Directory - so it skips it.
hi @rakeshramakrishnan-hbk, I have updated my comment to be more clear I have the app-of-apps.yaml of kind kustomize
Hi @filiprafaj - I'm trying to make this work in my environments (thank you so much btw for this work around). If you don't mind, are you using an app-of-apps pattern w/ multiple applications inside and all are sharing the
images:
- path: spec/source/helm/parameters[]/value
kind: Application
value? Would you be so kind as to share how you store your image
value in your values.yaml
file in your helm repo? Do you encompass your child applications in the same directory as your app-of-apps application?
Hi @devopsidiot , at the moment I use something like this https://github.com/filiprafaj/argocd-image-updater-helm-demo
The new thing there is the Deployment in the app folder - thanks to this I don't need the force-update
annotation anymore - it behaves better when there are multiple images to update in a single helmchart.
(btw for some large images I use DaemonSet
instead of Deployment
together with argocd.argoproj.io/hook: PreSync
, so it also work as a pre-pull)
@filiprafaj - thank you SO MUCH. Just one final question and I think you've given me the keys to my kingdom: The image updater HAS to be installed in the app-of-apps? I currently have it installed elsewhere but it has access to all namespaces.
@devopsidiot I have image uptater running in the argocd
namespace where I also deploy the Application
resources, but I don't think it is necessary
I hope with the following option available the issue can be resolved https://argocd-image-updater.readthedocs.io/en/latest/basics/update-methods/#specifying-a-repository-when-using-a-helm-repository-in-repourl
/reopen
I hope with the following option available the issue can be resolved https://argocd-image-updater.readthedocs.io/en/latest/basics/update-methods/#specifying-a-repository-when-using-a-helm-repository-in-repourl
@chengfang i can see that this annotation allows to keep .argocd-source-<appName>.yaml
file in the git repo where argo app manifests are maintained instead of helm repo.
But argocd never picks up parameters in this file when rendering manifests for the application.
i can see that this annotation allows to keep .argocd-source-
.yaml file in the git repo where argo app manifests are maintained instead of helm repo. But argocd never picks up parameters in this file when rendering manifests for the application.
Thanks for the feedback. I'll look into that. Feedback and other updates are also welcome and much appreciated!
Describe the bug
Using GIT write back together with Helm Chart from Helm Chart repository in repoURL isn't supported, because the ArgoCD image-updater tries to resolve the URL under
spec.source.repoURL
as the GIT repository to create update-commits, but since its a Helm repository, this fails with:To Reproduce
Create a Application resource like the following one:
Expected behavior
Having ArgoCD image updates committed to GIT
Additional context
One would expect to have a annotation based configuration alternative to set repoURL to a separate GIT repository url, looking like:
Version
quay.io/argoprojlabs/argocd-image-updater:v0.12.0
Logs