-
Notifications
You must be signed in to change notification settings - Fork 5.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
CLI app sync --retry-limit does not work #4505
Comments
Not familiar enough with the code base yet to make a PR to fix this. But to triage this for someone else it appears that the CLI calls this Function which always exits with an error if an operation is in progress. |
This is actually unrelated to The workaround for this is: argocd app wait APPNAME --operation && argocd app sync APPNAME |
So we are using that workaround but are still seeing errors 10-20% of the time in our pipeline. I was hoping this switch would help. Is there any plans to allow queuing or retry logic into the cli in the case a pipeline hits this error? Is the solution to just turn of autosync so our deploy pipeline doesn't take this error, or are there other operations that could also result in this error? |
+1 for this. Seeing this error too. |
Any update about this issue? |
We ended up Turning off autosync and it seems to have mitigated the issue a bit. We still have problems around app of apps that can be syncd by multiple deployments fail because another deploy/sync is happening at the same time. |
Turn off the autosync seems not elegant, hope there is a better way. |
We have the same issue. Running ver 2 Multiple microservices handled by the same ArgoCD Application. Builds start on commit. Each build calls: If multiple builds are "waiting", once the first sync completes, the rest attempt to kick off their own sync at the same time, returning the same "operation already in progress" error. Is selective sync our only solution here? |
+1, getting bit by this too. Given that ArgoCD is founded on the concept of declarative management, it seems bewildering that there's no single operation that says "Wait until synced to the latest, do whatever you need to ensure that happens, only fail if that is impossible or takes too long". In order to get pipelines which don't spuriously fail, we've been reduced to scraping the log output for that particular error message, and log scraping is generally a sign that something has gone wrong at a fundamental level. |
+1, getting this problem. We want to have parallel pipelines to do
|
The workaround for me is to discard For example: My CI system happen to be Jenkins, so the Jenkins-specific solution looks like this in Jenkinsfile:
In this case, multiple pipelines (and their forks due to |
Checklist:
argocd version
.Describe the bug
argocd app sync myapp --retry-limit 5 does not work as expected. It does not seem to retry at all if another sync or operation is in progress. If another sync is running already via autosync or manually started in the UI the CLI will error out and exit without completing the sync.
To Reproduce
Start manual sync of an app in the ui, at the same time slightly after the ui sync has started manually sync the app with the command argocd app sync myapp --retry-limit 5. The CLI will not retry the sync and exit with a code of 20 and output the following:
Expected behavior
CLI retries the sync properly with backoffs and does not exit with an error code.
Version
The text was updated successfully, but these errors were encountered: