[Bug][Argocd] Bug title all deployments reported as Succeeded — health status ignored, sync history phase hardcoded
維護者通常 2 天內回覆
評估
- 難度
- 4/5
- 預估耗時
- 3-5 天
- 新手友好度
- 51/100
- Issue 類型
- 缺陷
- 描述清晰度
- 描述清楚
- 活躍度
- 活躍
- 技術堆疊
- go
研究方向
Start by reading the three named task files: backend/plugins/argocd/tasks/sync_operation_collector.go, sync_operation_extractor.go, and sync_operation_convertor.go. Trace how application health and history entries flow into deployment results, then check the existing ArgoCD task tests. Done when degraded rollouts no longer appear successful and history entries without an outcome signal are not marked succeeded.
由索引模型根據 Issue 內容生成。
描述
Search before asking
- I had searched in the issues 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:
- 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.
- 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.
- 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
- Configure the ArgoCD data connection against an Application whose rollout becomes Degraded after sync (e.g., bad image, failing readiness probe).
- Run the argocd plugin collection/extraction/conversion tasks.
- 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
- I agree to follow this project's Code of Conduct
- 主要語言
- Go
- 星號
- 3.2k
- 分支
- 840
- 平均合併
- 1 天 21 小時
- 30 天內合併 PR
- 104
環境準備
在瀏覽器裡用你自己的 GitHub 帳號啟動這個專案的開發容器。
- 沒有 Dockerfile 或 Docker Compose 檔案
- 有 Pull Request 範本
- 沒有貢獻指南
從這裡開始
- 先讀完整個 Issue，再讀專案的貢獻指南。
- 在 Issue 下留言說明你要接手 —— 這能避免兩個人做同樣的事。
- Fork 儲存庫，在一個分支上完成修改。
- 送出 Pull Request，並在描述裡引用這個 Issue 編號。
apache/devlake 的其他 Issue
-
難度 2/5 1-3 小時 新手友好度 60/100
維護者通常 2 天內回覆
-
[Bug][CircleCI] collectPipelines panics with a nil pointer dereference when the sync policy has no timeAfter可能已有人在做 @ShivamSharma43 今天認領。 未關閉
apache/devlake#9367 · 已指派 1 人 ·
維護者通常 2 天內回覆
-
[Bug][Asana] Story, subtask and tag collectors stop at 100 per task; task and user collectors restart on a full last page可能已有人在做 @ShivamSharma43 今天認領。 未關閉
apache/devlake#9365 · 已指派 1 人 ·
維護者通常 2 天內回覆
-
[Bug][GitHub] Extract Issues succeeds without extracting when the issue regexes or milestones can't be loaded可能已有人在做 @ShivamSharma43 於 1 天前認領。 未關閉
apache/devlake#9358 · 已指派 1 人 ·
維護者通常 2 天內回覆
-
[Bug][Linear] Config UI cannot associate a scope config with Linear team scopes可能已有人在做 @VictorColomb 於 1 天前認領。 未關閉type/bug
apache/devlake#9355 · 已指派 1 人 ·
維護者通常 2 天內回覆
相似的 Issue
-
難度 2/5 1-3 小時 新手友好度 68/100
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 75/100
維護者通常 1 天內回覆
-
GitHub webhook is not subscribed to release events, so `event: release` never triggers可能已有人在做 @qsun 今天認領。 未關閉
難度 2/5 1-3 小時 新手友好度 78/100
woodpecker-ci/woodpecker#7542 ·
維護者通常 1 天內回覆
-
難度 2/5 1-3 小時 新手友好度 74/100
zilliztech/milvus-backup#1386 ·
維護者通常 1 天內回覆
-
Pipelined flush no longer observes kill signals after #2042: flush backoffer is built with nil vars未關閉
難度 2/5 1-3 小時 新手友好度 78/100
維護者通常 1 天內回覆