[Bug][Argocd] Bug title all deployments reported as Succeeded — health status ignored, sync history phase hardcoded
维护者通常 2 天内回复
还没有人认领这个 Issue。
评估
- 难度
- 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
- 派生
- 832
- 平均合并
- 1 天 21 小时
- 30 天内合并 PR
- 78
环境准备
在浏览器里用你自己的 GitHub 账号启动这个项目的开发容器。
- 没有 Dockerfile 或 Docker Compose 文件
- 有 Pull Request 模板
- 没有贡献指南
从这里开始
- 先读完整个 Issue，再读项目的贡献指南。
- 在 Issue 下留言说明你要接手 —— 这能避免两个人做同样的事。
- Fork 仓库，在一个分支上完成修改。
- 提交 Pull Request，并在描述里引用这个 Issue 编号。
apache/devlake 的其他 Issue
-
[Bug][Testmo] Runs, milestones and automation runs: only the first 100 are collected可能已有人在做 @ShivamSharma43 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 2 天内回复
-
[Bug][Tempo] Worklog domain ids lack the connection id, so connections with the same worklog id overwrite each other可能已有人在做 @ShivamSharma43 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 78/100
维护者通常 2 天内回复
-
[Bug][linker] LinkPrToIssue never matches lowercase issue keys (e.g. in branch names)可能已有人在做 @VictorColomb 于 4 天前认领。 未关闭type/bug
难度 2/5 1-3 小时 新手友好度 78/100
apache/devlake#9283 · 1 条评论 · 1 个 reaction · 已指派 1 人 ·
维护者通常 2 天内回复
-
难度 2/5 1-3 小时 新手友好度 60/100
维护者通常 2 天内回复
-
[Bug][JIRA Service API TOKEN] Jira API Gateway: saved service-account token truncated by varchar(255), causing Base64 errors and HTTP 500可能已有人在做 @RyoKusnadi 今天认领。 未关闭type/bug
难度 3/5 1-2 天 新手友好度 58/100
维护者通常 2 天内回复
相似的 Issue
-
难度 2/5 1-3 小时 新手友好度 65/100
SAP/crossplane-provider-btp#1175 ·
维护者通常 1 天内回复
-
adk: stream concatenation errors bypass retry and failover可能已有人在做 @OUAO-FRANK 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 82/100
维护者通常 1 天内回复
-
难度 2/5 1-3 小时 新手友好度 76/100
google/osv-scalibr#2586 ·
维护者通常 2 天内回复
-
needs-triage
难度 2/5 1-3 小时 新手友好度 72/100
stacklok/toolhive-catalog#1890 ·
维护者通常 1 天内回复
-
heap: pushing an item that is already queued corrupts the index可能已有人在做 @lbarrosby 今天认领。 未关闭
难度 2/5 1-3 小时 新手友好度 75/100
kubernetes-sigs/kwok#1800 ·
维护者通常 1 天内回复