Open daviddvir14 opened 3 months ago
I'm having the same issue on argocd version v2.10.5
Same here on v2.12.0
.
Update:
Checking out the main
branch locally, the auto sync works!
I have confirmed that this issue does not happen in v2.9.21
.
I'm afraid this optimization actually caused it, which was introduced in v2.10.0: https://github.com/argoproj/argo-cd/pull/16501
According to the PR:
When GenerateManifest is called with a ref only source manifest generation is still run, and since there are no manifests this is always considered a manifest cache miss causing an excess number of fetch requests to the git server
If I understand this correctly, it looks like the desire solution is to trigger manifest regeneration for the entire multi source repo when any of its sources changes, including the ones containing just values.yaml
files which are depending on the helm chart repo for the complete manifest; but in order to avoid the repeated cache miss while checking the ref repos, there will need to be a new support for ref-only caching .
cc @nromriell
I took a quick look at this and I wasn't able to reproduce, updates were getting picked up automatically for ref only sources. In the PR you link the call you see for newClientResolveRevision inside the short circuit branch calls the git ls remote to solve the new revision, and that call is still there on head.
What I do see is that the UI always shows the commit sha of only the first helm ref which I believe is by design, the second sha for the ref repo can be seen if you click into the sync status or by checking the status of the Application, but changes were happening automatically and I could see them in the cluster.
Tested against a locally built head (de53d8eb61ba995adc0e0832e0ccf2dc99d04b38) and the active v2.12.1 image. I pushed the reproduction environment to this branch https://github.com/nromriell/argocd-test-git-local-env/tree/debug-19382
The caching for refs here does follow the same timeout as other revisions set by ARGOCD_RECONCILIATION_TIMEOUT
env var for the repo server or timeout.reconciliation
from the helm chart deploy values. The changes I made though did help prevent a large number of those calls be made between that configured timeout, so if you have that value set high and you're now not getting changes fast enough you could try either reducing that configured time or setting up the git webhook to trigger updates with push events
I took a quick look at this and I wasn't able to reproduce, updates were getting picked up automatically for ref only sources. In the PR you link the call you see for newClientResolveRevision inside the short circuit branch calls the git ls remote to solve the new revision, and that call is still there on head.
What I do see is that the UI always shows the commit sha of only the first helm ref which I believe is by design, the second sha for the ref repo can be seen if you click into the sync status or by checking the status of the Application, but changes were happening automatically and I could see them in the cluster.
Tested against a locally built head (de53d8e) and the active v2.12.1 image. I pushed the reproduction environment to this branch https://github.com/nromriell/argocd-test-git-local-env/tree/debug-19382
The caching for refs here does follow the same timeout as other revisions set by
ARGOCD_RECONCILIATION_TIMEOUT
env var for the repo server ortimeout.reconciliation
from the helm chart deploy values. The changes I made though did help prevent a large number of those calls be made between that configured timeout, so if you have that value set high and you're now not getting changes fast enough you could try either reducing that configured time or setting up the git webhook to trigger updates with push events
Yup, it works. I just tested it again on v2.10.16 and v2.12.1. It just takes like 3-4 mins. Thank you for quickly clarifying and confirming this.
Checklist:
argocd version
.Describe the bug
Argo does not automatically sync an application after changes are made to a source repository (Git) when using a multi-repo configuration. However, manual sync works as expected.
To Reproduce
Expected behavior
Argo should automatically sync the application when there is a change in the source repository.
Screenshots
Version
Logs
application-controller:
repo-service: