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

Aberta
  • Algo errado?
#9,329 0 comentários 0 reações 0 responsáveis Ver no GitHub

Mantenedores costumam responder em até 2 dias

Ninguém assumiu esta issue ainda.

Avaliação

Dificuldade
4/5
Tempo estimado
3-5 dias
Facilidade para iniciantes
51/100
Tipo de issue
Bug
Clareza
Claramente especificada
Status de atividade
Ativa
Stack de tecnologia
go
Domínio
data-engineering

Direção de pesquisa

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.

Escrita pelo modelo de indexação a partir do texto da issue.

Descrição

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
Linguagem predominante
Go
Estrelas
3.2k
Forks
840
Merge médio
2d 6h
PRs com merge (30d)
85

Preparar o ambiente

Abrir no Codespaces

Inicia o contêiner de desenvolvimento do projeto no navegador, com a sua própria conta do GitHub.

  • Sem Dockerfile nem arquivo Docker Compose
  • Tem um modelo de pull request
  • Sem guia de contribuição

Primeiros passos

  1. Leia a issue inteira e depois o guia de contribuição do projeto.
  2. Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
  3. Faça um fork do repositório e trabalhe em uma branch.
  4. Abra um pull request que referencie o número da issue.

Mais de apache/devlake

Todas as issues de apache/devlake

Issues semelhantes

Mais issues de Go

Receba novas issues na sua caixa de entrada

Um resumo curto de issues do GitHub para quem está começando.