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, consulta las "Verificaciones".
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, consulta"Acerca de las ramas protegidas".
Nota: También puedes actualizar tu rama con la rama base utilizando Git rebase. Para obtener más información, consulta Accerca del rebase 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ás 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 failingNota: Las solicitudes de extracción que están actualizadas y aprobaron las verificaciones de estado requeridas pueden fusionarse localmente y subirse a la rama protegida. Esto se puede hacer sin las verificaciones de estado ejecutándose en la propia confirmación de fusión.
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. Para obtener más información sobre las confirmaciones de fusiones de prueba, consulta la sección "Extracciones".
Se salta el manejo pero se requieren las verificaciones
Nota: Si se omite un flujo de trabajo debido a filtrado de ruta, filtrado de rama o a un mensaje de confirmación, entonces las verificaciones asociadas con este flujo de trabajo permanecerán en un estado de "Pendiente". Las solicitudes de cambios que requieran que esas verificaciones tengan éxito quedarán bloqueadas para fusión.
Si se omite un job en un flujo de trabajo debido a una condicional, este reportará su estado como "Éxito". Para obtener más información, consulta las secciones de Omitir las ejecuciones de flujo de trabajo y Utilizar condiciones para controlar la ejecución de jobs.
Ejemplo
El siguiente ejemplo muestra un flujo de trabajo que requiere un estado de finalización "Exitoso" para el job build, pero el flujo de trabajo se omitirá si la solicitud 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@v2
- name: Use Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v2
with:
node-version: ${{ matrix.node-version }}
cache: 'npm'
- run: npm ci
- run: npm run build --if-present
- run: npm test
Debido al filtrado de rutas, una solicitud de cambios que solo cambie un archivo en la raíz del repositorio ya no activará este flujo de trabajo y se bloqueará para su fusión. Verías el siguiente estado en la solicitud de cambios:
Puedes arreglar esto creando un flujo de trabajo genérico con el mismo nombre, el cual devolverá "true" en cualquier caso similar al flujo de trabajo siguiente:
name: ci
on:
pull_request:
paths-ignore:
- 'scripts/**'
- 'middleware/**'
jobs:
build:
runs-on: ubuntu-latest
steps:
- run: 'echo "No build required" '
Ahora las verificaciones siempre pasarán cuando alguien envíe una solicitud de cambios que no cambie los archivos que se listan bajo paths en el primer flujo de trabajo.
Notas:
- Asegúrate de que la llave
namey el nombre de job requerido en ambos archivos de flujo de trabajo sean los mismos. Para obtener más información, consulta "Sintaxis de flujo de trabajo para GitHub Actions". - El ejemplo anterior utiliza GitHub Actions, pero esta solución también aplica a otros proveedores de IC/DC que se integran con GitHub.