¿Diferencias entre los estados de confirmación de la API de github “falla” y “error”?

4 minutos de lectura

¿Cuál es la diferencia entre los estados de confirmación de la API de github “fallo” y “error”?

Avatar de usuario de VonC
VonC

los Estados de la API de GitHub incluya marcar compromisos con un estado de éxito, falla, error o pendiente.

Típicamente, en un contexto de integración continuaun compromiso es:

  • marcado como ha fallado porque el trabajo falló completo
  • marcado como error porque el trabajo completópero salió con un estado distinto de cero
  • marcado como éxito porque el trabajo se completó y salió con un estado cero

(trabajo como tareas ejecutadas por programador de trabajos)


Desde 2014, la integración de GitHub con CI evolucionó.
En mayo de 2018, tuviste “Presentamos la API Checks, una mejor forma de conectar integraciones y código“.
Introdujo la noción de cheques

En lugar de estados de compilación binarios de aprobación/rechazo, las integraciones pueden informar estados enriquecidos, anotar líneas de código con información detallada e iniciar repeticiones.

Encuentras el fracaso en ese nuevo contexto (de cheques)

https://developer.github.com/assets/images/check_runs.png

Cuando alguien envía código a un repositorio, GitHub crea un conjunto de verificación para la última confirmación. Aplicaciones de GitHub con el checks:write permiso recibe un webhook check_suite con la acción solicitada. Cuando tu GitHub App recibe el evento check_suite, puede crear nuevas ejecuciones de verificación para la última confirmación.

Esto funciona con:

En ese nuevo contexto (Nueva versión beta pública de la API Checks):

  • la falla está asociada con una verificación que se ejecuta, pero sale con un estado distinto de cero,
  • el error está asociado con un cheque que ni siquiera puede ejecutarse

Ver Preguntas:

¿En qué se diferencian las ejecuciones de verificación de los estados de confirmación?

Los estados de compromiso permiten un simple estado de aprobación o falla.
Las ejecuciones de verificación permiten obtener información mucho más granular: pueden concluir como éxito, error, neutral, cancelado, tiempo de espera agotado o acción requerida. Las ejecuciones de verificación son más flexibles que los estados de confirmación.


De los comentarios

Juraj Martinka:

En terminología de pruebas unitarias:

  • “fracaso” generalmente representa una prueba fallida, es decir, el código debajo de la prueba devolvió una respuesta, pero esta es diferente de la esperada;
  • “error” representa un error inesperado en el código, como una excepción.

Esto también es lo que he visto que se usa en CI como Travis:

  • “Error de compilación” significa que su cambio rompe algunas pruebas, tiene errores de linter, etc.
  • “error de compilación” significa un error inesperado en el trabajo de compilación (terminación anticipada).

Bob Bell está de acuerdo:

Yo suelo:

  • “fracaso” para decir “la prueba falló contra los criterios”, y
  • “error” para ser “la prueba no se pudo ejecutar correctamente”.

Considero que “fracaso” y “éxito” son opuestos, los dos resultados de una prueba completa, mientras que “error” es el valor atípico, el resultado de una prueba abortada.

  • ¡Hola! ¿Podría explicar por favor es esta su opinión personal? Porque la persona en la otra respuesta tiene un comentario oficial del soporte de github.

    – Alexander Myshov

    5 de febrero de 2019 a las 4:39

  • @AlexanderMyshov No, es lo que he visto con la mayoría de los CI que he usado. Sin embargo, la respuesta oficial de GitHub alude a las “verificaciones de GitHub”, que se introdujeron 4 años después de esta respuesta. He editado mi respuesta para documentar eso.

    – VoC

    5 de febrero de 2019 a las 7:53

  • En la terminología de pruebas unitarias, “fracaso” generalmente representa una prueba fallida, es decir, el código debajo de la prueba devolvió una respuesta, pero esta es diferente de la esperada; “error” representa un error inesperado en el código, como una excepción. Esto también es lo que he visto que se usa en CI como Travi: “error de compilación” significa que su cambio rompe algunas pruebas, tiene errores de linter, etc. “error de compilación” significa un error inesperado en el trabajo de compilación (terminación anticipada).

    – Juraj Martinka

    31 de julio de 2019 a las 11:21


  • Estoy de acuerdo con @JurajMartinka. Uso “fracaso” para decir “la prueba falló según los criterios” y “error” para decir “la prueba no se pudo ejecutar correctamente”. Considero que “fracaso” y “éxito” son opuestos, los dos resultados de una prueba completa, mientras que “error” es el valor atípico, el resultado de una prueba abortada.

    – Bob Bell

    3 de marzo de 2021 a las 23:44


  • @BobBell Buen punto. Gracias por los comentarios. He incluido tu comentario en la respuesta para mayor visibilidad.

    – VoC

    4 de marzo de 2021 a las 8:02

Hice esta pregunta desde GitHub oficial y recibí la siguiente respuesta:

Hola Alejandro,

¡Gracias por contactar al soporte de GitHub!

  • Una verificación de CI fallida es cuando la verificación no ha pasado las condiciones requeridas.
  • Una verificación de CI que tiene un error es cuando la verificación en sí tiene un error que impide que se ejecute correctamente.

Avísame si necesitas más información.

¿Ha sido útil esta solución?