Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#9,177 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
3/5
Tiempo estimado
1-2 días
Aptitud para principiantes
76/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
go
Área
ci-cd

Línea de trabajo

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.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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
Lenguaje dominante
Go
Estrellas
3.1k
Forks
812
Merge medio
2 d 8 h
PR fusionados (30 d)
51

Preparar el entorno

Aún no hemos revisado los archivos de configuración de este proyecto. Empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de apache/devlake

Todos los issues de apache/devlake

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.