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

ensure results are returned even when `code-review` task doesn't run automatically

Abierto
#3,740 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

@bhearsum ya está trabajando en esto.

Desde el 21/10/2026.

  • #3751 de @bhearsum — abierto

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
python
Área
ci-cd, devtools

Línea de trabajo

Start by reading the discussion in pull request 3720 and trace how the code-review task and publication task are scheduled when upstream tasks do not run. Verify the behavior of Taskcluster's taskGroupResolved exchange and compare it with the cron option described here. Done means a chosen approach reliably publishes results and resolves Phabricator builds when an upstream task is skipped.

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

Descripción

Some discussion in https://github.com/mozilla/code-review/pull/3720 has highlighted the fact that it's possible for us never to publish status of a phab revision or github pull request. Because this happens in the publication task, and that publication task only runs when a code-review task completes, any issues that cause any of the direct upstream of that task not to run will result in the publication task never running. This, in turn, causes no feedback to be posted to github or phabricator, and worse yet, builds on phabricator not to be resolved. This is a more likely problem for builds and tests, but it is still possible to happen for linting as well.

It's not immediately clear to me how to deal with this. There is no way that I'm aware of to make the code-review tasks run when a direct upstream does not. Some ideas could be:

  • Run something on a cron schedule that looks for reviewbot task groups that are not doing anything, but haven't run code-review. Then, somehow kick that task to run, or directly schedule the publication task for them. The main downside to this is that unless we run this very frequently, we delay results.
  • Fire something on task-group-resolved. I believe this fires whenever a task group is idle (even if not all tasks have completed) - but this needs to be verified. This event doesn't have enough information in its payload to immediately fire a publication task; we'd need to run some small task to determine if it's a group we care about, and then to force the code-review task to run or directly schedule the publication task if it is.
Lenguaje dominante
Python
Estrellas
68
Forks
53
Merge medio
1 d 17 h
PR fusionados (30 d)
35

Preparar el entorno

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 mozilla/code-review

Todos los issues de mozilla/code-review

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.