Si tienes una verificación y un estado con el mismo nombre y seleccionas dicho nombre como una verificación de estado requerida, tanto la verificación como el estado se requerirán. Para obtener más información, vea «Puntos de conexión de la API de REST para comprobaciones».
Note
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 obtener más información, vea «Acerca de las ramas protegidas».
Note
También puedes actualizar la rama con la rama base utilizando la fusión mediante cambio de base de Git. Para obtener más información, vea «Acerca de la fusión mediante cambio de base de Git».
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
Note
Las solicitudes de cambios que están actualizadas y pasan las comprobaciones de estado necesarias se pueden fusionar localmente mediante combinación y enviarse a la rama protegida. Esto se puede hacer sin las verificaciones de estado ejecutándose en la propia confirmación de fusión.
La comprobación requerida debe realizarse correctamente respecto al SHA de confirmación más reciente.
Para que se fusione mediante combinación una solicitud de cambios, deben superarse todas las comprobaciones necesarias respecto al SHA de confirmación más reciente. 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 no se usarán como parte de las comprobaciones necesarias.
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, ésta pasará. De otra manera, el estado de la confirmación principal deberá pasar antes de que puedas fusionar la rama.
Si hay un conflicto entre la confirmación de combinación de pruebas y la confirmación principal, las comprobaciones de la confirmación de combinación de pruebas se muestran en la casilla de comprobación de estado de la solicitud de incorporación de cambios. Esto se indica en el cuadro de estado de la solicitud de incorporación de cambios mediante una línea que comienza por Showing checks for the merge commit. Para obtener más información sobre las confirmaciones de combinación de prueba, consulta "Puntos de conexión de la API de REST para solicitudes de incorporación de cambios".
Se salta el manejo pero se requieren las verificaciones
Warning
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 mediante combinación de una solicitud de incorporación de cambios que requiera esas comprobaciones para realizarse 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 es necesario. Para más información, consulta "Saltarse las ejecuciones de código" y "Flujos de trabajo obligatorios."
Sin embargo, si se omite un trabajo de un flujo de trabajo debido a una condicional, se notificará su estado como "Correcto". Para obtener más información, vea «Utilizar condiciones para controlar la ejecución de jobs».
Cuando se produce un error en un trabajo, los trabajos que dependen del trabajo con errores se omiten y no notifican un error. Es posible que no se bloquee una solicitud de incorporación de cambios que requiera la comprobación. Para usar una comprobación necesaria en un trabajo que depende de otros trabajos, usa la expresión condicional always() además de needs; consulta "Utilizar jobs en un flujo de trabajo".
Ejemplo
En el ejemplo siguiente se muestra un flujo de trabajo que requiere un estado de finalización "Correcto" para el trabajo build, pero el flujo de trabajo se omitirá si la solicitud de incorporación de cambios no cambia ningún archivo en el directorio scripts.
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@v4
- 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, una solicitud de incorporación de cambios que solo cambia un archivo en la raíz del repositorio no desencadenará este flujo de trabajo y se bloqueará su fusión mediante combinación. En la solicitud de incorporación de cambios, verá "Esperando que se notifique 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 es necesario. Para más información, consulta "Saltarse las ejecuciones de código" y "Flujos de trabajo obligatorios."
Comprobaciones 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 app esperada haya configurado la verificación que se lista en la caja de fusión.
Required status check "build" was not set by the expected GitHub App.