toontijtgatsfpd opened a new issue, #9329: URL: https://github.com/apache/devlake/issues/9329
### Search before asking - [x] I had searched in the [issues](https://github.com/apache/incubator-devlake/issues?q=is%3Aissue) and found no similar issues. ### What happened The argocd plugin never reflects the actual outcome of a deployment (ReplicaSet/Pod health). Virtually every cicd_deployments / cicd_deployment_commits record ends up with result = SUCCESS , even for rollouts that are Degraded /crash-looping, because: 1. The plugin only reads status.operationState and status.history[] from the ArgoCD Application API — it never reads status.health.status ( Healthy / Degraded / Progressing / Suspended / Unknown ), which is ArgoCD's actual indicator of rollout success. 2. For every entry sourced from status.history[] , sync_operation_extractor.go hardcodes the phase: // sync_operation_extractor.go } else { ... syncOp.Phase = "Succeeded" // always, regardless of real outcome ... } ArgoCD's status.history[] entries don't carry a phase/result field at all, so this hardcoding silently converts every historical sync into a "success," independent of whether the resulting Deployment ever became healthy. 3. The one place a real failure phase could surface — status.operationState.phase ( Failed / Error ) — is discarded via isRedundantOperationState() once superseded by a newer sync, and ArgoCD itself doesn't persist failed operations into history[] . So failed deployments effectively never make it into DevLake at all. Impact • DORA metrics (Change Failure Rate, MTTR) computed from cicd_deployments.result are meaningless for ArgoCD-sourced data — failure rate is always ~0%. • Deployment status in DevLake dashboards doesn't match what's visible in the ArgoCD UI ( Degraded / Progressing apps still show as successful deployments). Suggested Fix • Additionally collect status.health.status (and status.health.message ) from the Application API in sync_operation_collector.go . • In sync_operation_convertor.go , derive Result / Status from health ( Healthy → SUCCESS , Degraded → FAILURE , Progressing/Suspended/Unknown → DEFAULT / IN_PROGRESS ) instead of/in addition to sync phase . • Remove or properly justify the Phase = "Succeeded" hardcoding in sync_operation_extractor.go for status.history[] entries — fall back to DEFAULT / UNKNOWN when no real signal is available, instead of asserting success. Relevant files • backend/plugins/argocd/tasks/sync_operation_collector.go • backend/plugins/argocd/tasks/sync_operation_extractor.go • backend/plugins/argocd/tasks/sync_operation_convertor.go ### What do you expect to happen Deployment result / status should reflect the actual rollout outcome — ideally derived from (or combined with) status.health.status , not solely from sync phase , and status.history[] entries should not be blanket-marked Succeeded . ### How to reproduce 1. Configure the ArgoCD data connection against an Application whose rollout becomes Degraded after sync (e.g., bad image, failing readiness probe). 2. Run the argocd plugin collection/extraction/conversion tasks. 3. Inspect cicd_deployments for that application — result is SUCCESS even though the Application's status.health.status is Degraded . ### Anything else _No response_ ### Version v1.0.3-beta19 ### Are you willing to submit PR? - [ ] Yes I am willing to submit a PR! ### Code of Conduct - [x] I agree to follow this project's [Code of Conduct](https://www.apache.org/foundation/policies/conduct) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
