[Bug][Argocd] Bug title all deployments reported as  Succeeded  — health status ignored, sync history phase hardcoded

Aperta
  • Qualcosa non va?
#9,329 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 2 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
51/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
go
Ambito
data-engineering

Direzione di ricerca

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.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

type/bug
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:

  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.

  1. 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
Lingua principale
Go
Stelle
3.2k
Fork
832
Merge medio
1g 21h
PR unite (30g)
78

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

  • Nessun Dockerfile né file Docker Compose
  • Ha un modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di apache/devlake

Tutte le issue di apache/devlake

Issue simili

Altre issue su Go

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.