Solución de problemas de los conjuntos de reglas
Si no puedes realizar una acción en un repositorio y deseas saber por qué, puedes ver los conjuntos de reglas activos destinados a la rama o etiqueta con la que estás trabajando. Para más información, consulta Administración de conjuntos de reglas de un repositorio.
En función de las reglas activas, es posible que tengas que editar el historial de confirmaciones localmente antes de poder insertar las confirmaciones en la rama remota. Por ejemplo, si una rama requiere que se firmen confirmaciones, puedes actualizar la configuración de firma y, a continuación, usar una fusión mediante cambio de base interactiva en la rama local para volver a escribir el historial de Git con confirmaciones firmadas. Para más información, consulta Reglas disponibles para conjuntos de reglas y Utilizar la rebase de Git en la línea de comando.
Si una rama o etiqueta está destinada a reglas que restringen los metadatos de las confirmaciones, es posible que las confirmaciones se rechacen si parte de los metadatos de la confirmación no coincide con un patrón determinado. Por ejemplo, es posible que tengas que agregar un número de incidencia al inicio del mensaje de confirmación o cambiar el nombre de una nueva rama o etiqueta que intentas insertar en el repositorio. Si se rechazan las confirmaciones, verás un mensaje que te indicará el patrón con el que deben coincidir los metadatos pertinentes. Al igual que con las confirmaciones firmadas, es posible que tengas que realizar una fusión mediante cambio de base para fusionar las confirmaciones mediante combinación con "squash" o volver a escribir cada confirmación individualmente. Para más información, consulta Reglas disponibles para conjuntos de reglas.
Al usar conjuntos de reglas de inserción, se permite un máximo de 1000 actualizaciones de referencia por inserción. Si la inserción supera este límite, se rechazará. Para obtener más información, consulta Creación de conjuntos de reglas de un repositorio.
Solución de problemas de los flujos de trabajo de los conjuntos de reglas
Los flujos de trabajo del conjunto de reglas se pueden configurar en el nivel de organización para requerir que se pasen flujos de trabajo antes de fusionar mediante combinación solicitudes de cambios. Para obtener más información, vea «Creación de conjuntos de reglas para repositorios de la organización».
Flujos de trabajo de los conjunto de reglas con solicitudes de cambios abiertas
Si crea una regla con una solicitud de cambios abierta, el flujo de trabajo necesario no se ejecutará automáticamente. Para desencadenar el flujo de trabajo necesario, inserte una nueva confirmación, actualice la rama o cierre y vuelva a abrir la solicitud de cambios.
Eventos de flujo de trabajo del conjunto de reglas admitidos
Los flujos de trabajo del conjunto de reglas admiten el uso de los eventos pull_request, pull_request_target y merge_group. Como resultado, debe especificar uno o varios de estos eventos en la sección on: del flujo de trabajo para que un conjunto de reglas ejecute el flujo de trabajo.
Los filtros que especifique para los eventos admitidos se omiten (por ejemplo, branches, branches-ignore, paths, types, etc.) El flujo de trabajo únicamente se desencadena y siempre se desencadena según los tipos de actividad predeterminados de los eventos admitidos.
| Evento | Tipos de actividad predeterminados |
|---|---|
pull_request | opened, synchronize, reopened |
pull_request_target | opened, synchronize, reopened |
merge_group | checks_requested |
Para más información, consulta Eventos que desencadenan flujos de trabajo.
Los flujos de trabajo del conjunto de reglas no se ejecutan en eventos desencadenados por GITHUB_TOKEN. Para más información, consulta Autenticación automática de tokens.
Bloqueo de la creación del repositorio
Un flujo de trabajo necesario puede impedir que alguien cree un repositorio, ya que un flujo de trabajo no se puede ejecutar en un repositorio que se está inicializando. Para solucionar este problema, el conjunto de reglas debe tener "Evaluar" como estado de cumplimiento, o alguien con permisos de omisión debe crear el repositorio y omitir la protección de la rama.
Para obtener más información sobre los estados de obligatoriedad y el modo "Calcular", consulta Creación de conjuntos de reglas de un repositorio.
Para más información sobre los permisos de omisión, consulta Acerca de las ramas protegidas.
Destinos de rama en un conjunto de reglas
Verifique que el flujo de trabajo del conjunto de reglas no tiene como destino todas las ramas del repositorio. Solo debe dirigirse a ramas en las que todos los cambios en la rama se realicen mediante solicitudes de cambios.
Directorio admitido
Verifique que el archivo de flujo de trabajo existe en el directorio .github/workflows. Si desea ejecutar un flujo de trabajo de conjunto de reglas en eventos pull_request de un repositorio que no sea el repositorio de origen, puede realizar cualquiera de las siguientes acciones:
- Agregue un condicional al archivo de flujo de trabajo, como
if: true. Para más información, consulta Sintaxis del flujo de trabajo para Acciones de GitHub. - Inhabilite acciones completamente en el repositorio de origen. Para más información, consulta Administrar los ajustes de las GitHub Actions de un repositorio.
- Inhabilite el flujo de trabajo individual en el repositorio de origen. Para más información, consulta Deshabilitación y habilitación de un flujo de trabajo.
Uso del desencadenador merge_group
Si el repositorio usa GitHub Actions para realizar las comprobaciones necesarias o si necesita flujos de trabajo a través de conjuntos de reglas de la organización en las solicitudes de incorporación de cambios en el repositorio, debe actualizar los flujos de trabajo para incluir el evento merge_group como desencadenador adicional. De lo contrario, las comprobaciones de estado no se desencadenarán al agregar una solicitud de incorporación de cambios a una cola de fusión. Se producirá un error en la fusión mediante combinación, ya que no se notificará la comprobación de estado necesaria. El evento merge_group es independiente de los eventos pull_request y push.
Permisos del repositorio de origen
Verifique que los permisos del repositorio de origen están establecidos en «Accesible desde repositorios de la organización ORGANIZATION NAME».
Para más información, consulta Administrar los ajustes de las GitHub Actions de un repositorio.
Configuración de privacidad del repositorio de origen
Verifique que el archivo de flujo de trabajo del conjunto de reglas está en un repositorio de origen que tenga la misma configuración de privacidad o menos restrictiva que los repositorios en los que desea ejecutarlo. En concreto, un flujo de trabajo público se puede ejecutar en cualquier repositorio de la organización, un flujo de trabajo interno se puede ejecutar en repositorios internos y privados, y un flujo de trabajo privado se puede ejecutar en repositorios privados. Para más información, consulta Acerca de los flujos de trabajo.
Permisos para crear un nuevo repositorio
Para crear un nuevo repositorio cuando se configura un flujo de trabajo de conjunto de reglas, asegúrese de que tiene permisos de omisión para el conjunto de reglas. Para más información, consulta Creación de conjuntos de reglas de un repositorio.
Información sobre reglas
GitHub no registra información sobre reglas hasta que se fusiona mediante combinación una solicitud de cambios o se intenta realizar una fusión mediante combinación.
Simultaneidad
Verifique que el flujo de trabajo del conjunto de reglas no utiliza la configuración de simultaneidad cancel-in-progress. Para obtener más información sobre simultaneidad, consulta Control de la simultaneidad de flujos de trabajo y trabajos.