Arreglar una ejecución fallida en su propio checkout
De una ejecución fallida, Inspect failure evidence muestra un extracto delimitado y Create and verify a CI fix abre una compra por separado en la revisión fallida. Fix with Nour es opcional. Check hosted result busca una ejecución alojada de esa confirmación exacta. Una reproducción local no prueba que se haya aprobado la ejecución alojada.
Parte de GitTree Pro, que todos tienen ahora mismo sin coste alguno; Gratis mantiene todas las funciones locales de Git. Comparar los planes.
En esta página
Antes de empezar
- GitTree Pro, que todos tienen sin costo en este momento, y una cuenta conectada para el host que ejecutó la canalización. Las tuberías son una característica Pro. Planes enumera lo que incluye Pro.
- La ejecución fallida tiene una revisión conocida. This run has no known immutable revision significa que el checkout de la solución no se puede anclar.
donde encontrarlo
- Abra la ejecución fallida en Pipelines, luego Inspect failure evidence y Create and verify a CI fix.
- Return to failed run vuelve a esa ejecución desde la vista de corrección.
| acción | macOS | Windows y Linux |
|---|---|---|
| Tuberías | ⌥P | Alt+P |
Pasos
Inspeccionar la evidencia de falla
En la ejecución fallida, abra Inspect failure evidence. La nota dice que las líneas son puntos de partida sugeridos a partir de un extracto delimitado y redactado, no una causa raíz confirmada, y que el texto del registro no es de confianza. Los tipos incluyen Setup, Dependency resolution, Compiler, Test, Reported diagnostic y Exit summary; may be downstream. Open failing job log muestra el registro de origen.
La ejecución fallida está en esta lista. La evidencia de falla y la verificación de solución se abren desde la ejecución. La imagen fija es la lista de ejecuciones.GitTree interfaz con un repositorio de demostración. Crear un checkout arreglado
Create and verify a CI fix dice que se inicie un checkout por separado en la revisión fallida, se revise la solución y luego se compare el contenido exacto con el CI alojado. Establezca New fix branch y New checkout folder como ruta absoluta. Create local fix checkout lo crea. Open fix checkout abre esa carpeta. Un checkout hermano no puede reemplazar el checkout reparado original.
Cambia el código ahí
Edite en la caja de corrección. Fix with Nour le pide a Nour, en ese checkout, que inspeccione la evidencia con su aprobación y deje un parche enfocado. El mensaje le indica a Nour que no publique ni inicie ejecuciones alojadas. Prepare local reproduction puede escribir un comando de ejecución local. Su nota dice que un ejecutor instalado puede diferir de los servicios, secretos, imágenes y permisos alojados, y que la salida del terminal no prueba que la CI alojada haya sido aprobada.
Verifique el resultado alojado
Confirme la solución a través del flujo de confirmación normal. Review publishing in Ship Preview cuando estés listo para enviar. La vista nunca envía ni inicia una carrera. Después de que exista una ejecución alojada, Check hosted result. Passed for this clean committed content es el estado que desea. Outdated: local content changed significa que editaste después de esa confirmación.
Resultado esperado
La solución está en su propia rama en su propia carpeta y tiene un estado alojado para una identificación de confirmación o sabe que no se observó ninguna ejecución alojada coincidente. El checkout original no ha cambiado excepto lo que usted mismo hizo allí.
Estados anfitriones
| Estado | Significado |
|---|---|
| No marcado: no se observó ninguna ejecución alojada coincidente | No se vio ninguna ejecución alojada para esta confirmación. |
| En cola para este commit | Una ejecución alojada está en cola |
| Corriendo para este commit | Hay una ejecución alojada en curso. |
| Aprobado para este contenido limpio y confirmado. | La ejecución alojada pasó para esa confirmación y el contenido local aún coincide con ella. |
| Error al realizar esta confirmación | La ejecución alojada falló para esa confirmación. |
| Desactualizado: el contenido local cambió; confirmar y verificar de nuevo | Editaste después de la confirmación que se verificó. |
| No disponible: falta el flujo de trabajo exacto o la identidad de checkout | La ejecución no se puede vincular a este flujo de trabajo y checkout |
| Resultado desconocido: evidencia cancelada, incompleta o no disponible | La evidencia no dice aprobado o reprobado. |
Only the newest 30 candidate runs were checked. Older results may exist. Un pase en esa ventana no es una búsqueda en todo el historial del host. Explicar un error es la lectura más corta de un registro. Este artículo es el método de checkout que utiliza cuando desea cambiar la revisión que falló.
El local no está alojado
Prepare local reproduction no tiene ningún resultado verificado en esta vista. Ejecutar una canalización localmente escribe un comando act o gitlab-ci-local. Presionas Enter. El código de salida de ese comando es sobre su máquina. Only a hosted run for the exact committed fix can verify it. La vista de corrección nunca presiona ni inicia esa ejecución.
git rev-parse HEAD
git status --porcelain
git worktree listgit rev-parse HEAD en el checkout de corrección es la confirmación que Check hosted result debe coincidir. Un git status sucio es la razón por la que el estado se vuelve obsoleto. git worktree list muestra la nueva carpeta al lado del checkout original. El tutorial cubre las confirmaciones diarias antes de una corrección de CI.
Cómo leer el extracto
Only part of the source log was inspected cuando el extracto es parcial. No recognizable primary diagnostic was found in this excerpt significa que debes abrir el registro de origen. Compare compatible successful run es un punto de partida, no una diferencia de cada paso. Open source on provider deja GitTree para la página del anfitrión. El texto del registro no es de confianza. No pegue un comando del registro en una terminal hasta que lo haya leído.
Si algo sale mal
"Esta ejecución no tiene ninguna revisión inmutable conocida".
El checkout de la solución necesita una identificación de confirmación. Abra una ejecución que registre una o busque la confirmación en el host y compruébelo usted mismo.
"Abra el checkout de la solución original para continuar. Un checkout hermano no puede reemplazarlo".
Estás en un árbol de trabajo diferente. Abra la carpeta que se creó para esta solución. No espere que otro checkout se convierta en el checkout fijo.
"Obsoleto: el contenido local cambió; confirme y verifique nuevamente".
Confirme los archivos nuevos, publíquelos mediante el flujo de revisión normal, espere la ejecución alojada y vuelva a verificar. El pase anterior fue para la confirmación anterior.
"No marcado: no se observó ninguna ejecución alojada coincidente".
No hubo ninguna carrera alojada para ese commit entre los 30 candidatos más nuevos. Envíe e inicie el flujo de trabajo en el host si esperaba uno, luego actualice. Esta vista no lo inicia.
Preguntas
¿La ejecución de un acto local significa que se aprobó la ejecución GitHub Actions?
No. La reproducción local no tiene ningún resultado verificado aquí. Los secretos, las imágenes y los permisos pueden diferir. Sólo una ejecución alojada para la confirmación exacta verifica la solución.
¿Crear checkout de corrección local impulsará la rama?
No. Crea una rama local y una carpeta en la revisión fallida. Revisa la publicación en Vista previa del envío cuando quieras enviarla. Esta vista nunca envía ni inicia una carrera.
¿Es el extracto del fallo la causa raíz?
No. Es un punto de partida sugerido a partir de un extracto redactado. Un resumen de salida puede ser posterior a un error anterior. Abra el registro de origen.
¿Fix with Nour publica el parche?
El mensaje indica que no se debe publicar ni iniciar ejecuciones alojadas sin su acción explícita. Usted revisa el parche, confirma y publica usted mismo.
¿Qué plan incluye esto?
Las canalizaciones, incluido este flujo de reparación, necesitan GitTree Pro, que todos tienen sin costo en este momento. Nour en la solución de pago también necesita Pro.