Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

[Bug][jenkins] Incremental collection skips the stages of builds that finish after the next sync

Aperta
  • Qualcosa non va?
#9,177 1 commento 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
3/5
Tempo stimato
1-2 giorni
Idoneità per principianti
76/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
go
Ambito
ci-cd

Direzione di ricerca

Start in backend/plugins/jenkins/tasks/stage_collector.go and inspect the incremental filters in both the single-job and multi-branch collectors. Reproduce a build that spans two collections, then verify that an incremental run finds its stages and that full and incremental collections produce the same stage records.

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

Descrizione

Search before asking
  • I had searched in the issues and found no similar issues.
What happened

With incremental collection, collectApiStages never collects the stages of a Jenkins build that started before the previous collection and finished after it. Those builds end up in _tool_jenkins_builds with a result, but with no rows in _raw_jenkins_api_stages / _tool_jenkins_stages, so their deployment stages never become cicd_tasks and the deployments are missing from DORA.

Cause (backend/plugins/jenkins/tasks/stage_collector.go, both the single-job and the multi-branch collectors):

if apiCollector.IsIncremental() && apiCollector.GetSince() != nil {
    clauses = append(clauses, dal.Where(`tjb.start_time >= ?`, apiCollector.GetSince()))
}

The build collectors skip builds that are still running (buildObj["result"] != nil), so a build is stored the first time it is collected finished. For a build that started before since and finished after it, that happens in a later run, and the stage collector filters it out by start_time in that run and in every run after it. Nothing reports it.

This is common in pipelines that wait on an input step, e.g. a "rollback?" or "deploy to production?" approval left open for hours or days after the deploy.

Evidence from our instance (v1.0.3-beta15, 190 multi-branch scopes, daily collection):

Build duration Builds with stages, first (full) collection Builds with stages, incremental runs since
< 6 h 508 / 561 680 / 711
6–24 h 25 / 25 5 / 68
> 24 h 698 / 814 13 / 389

For example, front-channel/master#111 (SUCCESS, 148 h) is in _tool_jenkins_builds and has no row in _raw_jenkins_api_stages. The collector is unchanged on main.

What do you expect to happen

An incremental run collects the stages of every build that became available since the previous run, i.e. every build that finished since then, whenever it started. A full and an incremental collection should produce the same stages.

How to reproduce
  1. Jenkins scope with incremental collection (any sync after the first).
  2. Start a pipeline build that waits on an input step, and let a collection run while it waits.
  3. Answer the input after that collection so the build finishes, then run another collection.
  4. The build is in _tool_jenkins_builds, but _tool_jenkins_stages has no rows for it.
Anything else

Proposed fix, PR to follow: filter on the finish time, tjb.timestamp + tjb.duration >= since. Both columns are milliseconds, so it is plain arithmetic on MySQL and PostgreSQL, no dialect-specific date functions. It is a superset of the current condition (duration ≥ 0).

Version

v1.0.3-beta15 (collector unchanged on main)

Are you willing to submit PR?
  • Yes I am willing to submit a PR!
Code of Conduct
Lingua principale
Go
Stelle
3.1k
Fork
812
Merge medio
2g 8h
PR unite (30g)
50

Preparare l'ambiente

Non abbiamo ancora controllato i file di configurazione di questo progetto. Parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

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.