El PR que no se pudo fusionar por un 'lint' condicional

El caso del PR #48

El merge button del PR #48 estaba gris, pese a que todos los checks mostraban verde y el linter reportaba sin errores. El objetivo era refactorizar el manejador de comandos para conservar el contexto en tareas encadenadas. La rama estaba al día, la pipeline terminó y los tests pasaron.

¿Qué falló?

Al revisar los logs, la UI mostraba el mensaje: "Esta rama está desactualizada con la rama base y debe actualizarse". La causa no era un conflicto de código, sino una configuración de workflow.

El archivo .github/workflows/ci.yml contenía un if: github.event.pull_request.base.ref == 'main' que limitaba la ejecución del job lint-python a PRs dirigidos a main. Dado que el PR apuntaba a develop, lint-python nunca se disparaba, pero la política de protección de rama requería su estado. El resultado: el check aparecía como expected /pending y el merge se bloqueaba.

Resolución

Se eliminó la condición if, permitiendo que lint-python se ejecute tanto en main como en develop. Tras rebasing la rama y volver a lanzar CI, el check se ejecutó, pasó a verde y el botón de merge quedó activo. El tiempo total del problema fue de diez minutos.

Lección

Un estado verde en la UI puede ocultar un desalineamiento entre políticas, configuración y intención. La protección de rama se activó por una condición que nunca se cumplía, y el sistema no alertó con un error rojo. El aprendizaje es que la cobertura de políticas debe mostrarse explícitamente, no solo la salud de CI.

Próximos pasos

Se implementará un script que verifique que todos los jobs requeridos por la protección de rama están configurados para cada rama objetivo. Así se evitarán futuros bloqueos silenciosos.

Para más detalle, revisa el artículo completo en el repositorio de Dev.to.