Si tienes una comprobación y un estado con el mismo nombre y seleccionas dicho nombre como una comprobación de estado requerida, tanto la comprobación como el estado serán necesarios. Para más información, consulta AUTOTITLE.
Nota:
Para que sean obligatorias, las comprobaciones de estado deben haberse completado correctamente en el repositorio elegido durante los últimos siete días.
Después de que habilitas la verificación de estado requerida, tu rama podría tener que actualizarse con la rama base antes de que se pueda fusionar. Esto garantiza que tu rama ha sido probada con el último código desde la rama base. Si tu rama no está actualizada, necesitarás fusionar la rama base en tu rama. Para más información, consulta AUTOTITLE.
Nota:
También puedes actualizar tu rama según la rama base utilizando rebase de Git. Para más información, consulta AUTOTITLE.
No podrás subir cambios locales a una rama protegida hasta que se hayan aprobado todas las verificaciones de estado requeridas. En su lugar, recibirá un mensaje de error similar al siguiente:
remote: error: GH006: Protected branch update failed for refs/heads/main.
remote: error: Required status check "ci-build" is failing
Nota:
Las solicitudes de cambios que están actualizadas y pasan las comprobaciones de estado necesarias se pueden fusionar localmente y enviarse a la rama protegida. Esto se puede hacer sin que las verificaciones de estado se ejecuten en el propio commit de fusión.
La comprobación requerida debe tener éxito contra el SHA del último commit.
Para que se fusionen las solicitudes de extracción, deben superarse todas las comprobaciones necesarias en el SHA del último commit. Esto garantiza que los cambios recientes se validen y cumplan los estándares necesarios antes de fusionarlos mediante combinación. Las comprobaciones que se hayan desencadenado con un SHA de confirmación anterior no se usarán para las comprobaciones necesarias. Los estados de comprobación correctos son: , y . Para más información, consulta AUTOTITLE.
Conflictos entre confirmaciones de encabezado y confirmaciones de fusiones de prueba
Algunas veces, los resultados de las verificaciones de estado para la confirmación de la prueba de fusión y de la confirmación principal entrarán en conflicto. Si la confirmación de fusión de prueba tiene un estado, la confirmación de fusión de prueba debe aprobarse. De lo contrario, el estado del commit principal deberá pasar antes de que puedas fusionar la rama.
Si hay un conflicto entre la confirmación de fusión de prueba y la confirmación principal, las comprobaciones de la confirmación de fusión de prueba se muestran en el cuadro de verificación de estado en la solicitud de extracción. Esto se indica en el cuadro de estado de la solicitud de incorporación de cambios mediante una línea que comienza por . Para obtener más información sobre los commits de combinación de prueba, consulta AUTOTITLE.
Manejo de verificaciones omitidas pero requeridas
Advertencia
Si se omite un flujo de trabajo debido al filtrado de rutas de acceso, al filtrado de ramas o a un mensaje de confirmación, las comprobaciones asociadas a ese flujo de trabajo permanecerán en estado "Pending". Se bloqueará la fusión de un pull request que requiera que esas comprobaciones se realicen correctamente.
No debes usar el filtrado de rutas de acceso o de ramas para omitir las ejecuciones de flujo de trabajo si el flujo de trabajo debe completarse antes de la combinación. Para más información, consulta Saltarse las ejecuciones de código y Reglas disponibles para conjuntos de reglas.
Sin embargo, si se omite un trabajo de un flujo de trabajo debido a una condicional, se notificará su estado como "Correcto". Para más información, consulta AUTOTITLE.
Cuando se produce un error en un trabajo, los trabajos que dependen del trabajo fallido se omiten y no informan un error. Es posible que una solicitud de incorporación de cambios que requiere la comprobación no sea bloqueada. Para usar una comprobación necesaria en un trabajo que depende de otros trabajos, usa la expresión condicional además de ; consulta AUTOTITLE.
Ejemplo
En el ejemplo siguiente se muestra un flujo de trabajo que requiere un estado de finalización "Exitoso" para el trabajo, pero el flujo de trabajo se pasará por alto si el pull request no cambia ningún archivo en el directorio.
name: ci
on:
pull_request:
paths:
- 'scripts/**'
jobs:
build:
runs-on: ubuntu-latest
strategy:
matrix:
node-version: [12.x, 14.x, 16.x]
steps:
- uses: actions/checkout@v5
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node-version }}
cache: 'npm'
- run: npm ci
- run: npm run build --if-present
- run: npm test
Debido al filtrado de ruta, un pull request que solo cambia un archivo en la raíz del repositorio no desencadenará este flujo de trabajo y su fusión será bloqueada. En la solicitud de pull, verá "Esperando que se reporte el estado".
No debes usar el filtrado de rutas de acceso o de ramas para omitir las ejecuciones de flujo de trabajo si el flujo de trabajo debe completarse antes de la combinación. Para más información, consulta Saltarse las ejecuciones de código y Reglas disponibles para conjuntos de reglas.
Comprobaciones de estado con GitHub Actions y una lista de espera para la fusión
Cuando se agrega una solicitud de incorporación de cambios a una cola de integración, debes usar el evento para desencadenar un flujo de trabajo de GitHub Actions.
Nota:
Un flujo de trabajo que informa de una comprobación requerida por las protecciones de la rama de destino tendría este aspecto:
on:
pull_request:
merge_group:
Para obtener más información sobre el evento , consulta AUTOTITLE.
Verificaciones de estado necesarias de orígenes inesperados
También es posible que una rama protegida requiera una verificación de estado desde una GitHub App específica. Si ves un mensaje similar al siguiente, entonces deberías verificar que la aplicación esperada haya configurado la selección listada en el cuadro de combinación.
Required status check "build" was not set by the expected GitHub App.