Skip to main content

Creación de conjuntos de reglas para repositorios de la organización

Puedes crear un conjunto de reglas para tener como destino varios repositorios de tu organización.

¿Quién puede utilizar esta característica?

Organization owners can create rulesets at the organization level.

Introducción

Puedes crear conjuntos de reglas en tu organización para controlar cómo los usuarios pueden interactuar con los repositorios de tu organización. Puedes controlar aspectos como quién puede insertar confirmaciones en una rama determinada y cómo se debe dar formato a las confirmaciones, o quién puede eliminar una etiqueta o cambiarle el nombre. También puedes impedir que los usuarios cambien el nombre de los repositorios.

Cuando se crea un conjunto de reglas para una organización, se usa la sintaxis fnmatch para definir qué repositorios de la organización y qué ramas o etiquetas de esos repositorios tienen como destino el conjunto de reglas. Esto proporciona una manera más rápida de dirigirse a los repositorios de tu organización que crear un conjunto de reglas independiente para cada repositorio. Para obtener más información, consulta "Información sobre patrones fnmatch para ramas, etiquetas y repositorios".

Las bifurcaciones no heredan conjuntos de reglas de sus repositorios ascendentes. Sin embargo, las bifurcaciones que pertenecen a tu organización están sujetas a los conjuntos de reglas que crees, como cualquier otro repositorio.

Puedes importar un conjunto de reglas desde otro repositorio u organización mediante un archivo JSON. Esto puede ser útil si deseas aplicar el mismo conjunto de reglas a varios repositorios u organizaciones. Para obtener más información, consulta «Administración de conjuntos de reglas para repositorios de la organización».

Lleva a cabo los siguientes procedimientos para crear un conjunto de reglas:

Creación de un conjunto de reglas de rama o etiqueta

  1. En la esquina superior derecha de GitHub.com, selecciona la foto de perfil y luego haz clic en Sus organizaciones.

    Captura de pantalla del menú desplegable en la imagen de perfil de @octocat. "Sus organizaciones" se destaca en naranja oscuro.

  2. Junto a la organización, haga clic en Settings.

  3. En la barra lateral izquierda, en la sección "Código, planeamiento y automatización", haz clic en Repositorio y, luego, haz clic en Conjuntos de reglas.

    Captura de pantalla de la página de configuración de una organización. En la barra lateral, aparece un vínculo etiquetado como "Conjuntos de reglas" con un contorno naranja.

  4. Puedes crear un conjunto de reglas que tenga como destino ramas o un conjunto de reglas que tenga como destino etiquetas.

    • Para crear un conjunto de reglas que tenga como destino ramas, haz clic en Nuevo conjunto de reglas de rama.

    • Para crear un conjunto de reglas destinado a etiquetas, selecciona y, a continuación, haz clic en Nuevo conjunto de reglas de etiquetas.

      Captura de pantalla de la página "Conjuntos de reglas". Junto al botón "Nuevo conjunto de reglas de rama", se expande un menú desplegable, con una opción denominada "Nuevo conjunto de reglas de etiquetas" resaltado en naranja.

  5. En la sección "General", escriba un nombre para el conjunto de reglas y seleccione Deshabilitado y seleccione uno de los siguientes estados de obligatoriedad.

Concesión de permisos de omisión para el conjunto de reglas

Puede conceder determinados roles, equipos o aplicaciones que omitan permisos para el conjunto de reglas. Los siguientes son aptos para omitir el acceso:

  • Administradores del repositorio o propietarios de la organización
  • Rol de mantenimiento o escritura, o roles de repositorio personalizados basados en el rol de escritura
  • Teams
  • GitHub Apps
  • Dependabot. Para obtener más información sobre Dependabot, consulta "Guía de inicio rápido de Dependabot".
  1. Para conceder permisos de omisión para el conjunto de reglas, en la sección "Lista de omisión", haga clic en Agregar omisión.

  2. En el cuadro de diálogo modal "Agregar omisión" que aparece, busque el rol, el equipo o la aplicación que desea conceder permisos de omisión y, a continuación, seleccione el rol, el equipo o la aplicación en la sección "Sugerencias" y haga clic en Agregar seleccionado.

  3. Opcionalmente, para conceder omisión a un actor sin permitirles insertar directamente en un repositorio, seleccione Always y, a continuación, haga clic en Solo para solicitudes de incorporación de cambios.

    El actor seleccionado debe ahora abrir una solicitud de incorporación de cambios para realizar cambios en un repositorio, creando una pista digital clara con sus cambios. Después, el actor puede optar por omitir las protecciones de rama y combinar esa solicitud de incorporación de cambios.

Elección de los repositorios de destino en la organización

Con el conjunto de reglas, puedes elegir tener como destino todos los repositorios de la organización, repositorios de la organización que coincidan con una determinada convención de nomenclatura o una lista de repositorios seleccionados manualmente en la organización.

Si un repositorio tiene como destino un conjunto de reglas creado en el nivel de organización, solo los propietarios de la organización pueden editar el conjunto de reglas. Sin embargo, los usuarios con acceso de administrador al repositorio o con un rol personalizado, incluido el permiso "editar reglas del repositorio", pueden crear conjuntos de reglas adicionales en el nivel de repositorio. Las reglas de estos conjuntos de reglas se agregarán con las reglas definidas en el nivel de organización. El resultado es que la creación de un nuevo conjunto de reglas puede hacer que las reglas destinadas a una rama o etiqueta sean más restrictivas, pero nunca menos restrictivas. Para más información sobre la creación de conjuntos de reglas, consulta "Acerca de los conjuntos de reglas".

Destino de todos los repositorios de la organización

Para definir como destino todos los repositorios de la organización, en la sección "Repositorios de destino", selecciona Destino: REPOSITORIOS y, a continuación, haz clic en Todos los repositorios.

Destino de repositorios por convención de nomenclatura en la organización

  1. Para definir como destino una lista dinámica de repositorios de la organización por convención de nomenclatura, en la sección "Repositorios de destino", selecciona Destino: REPOSITORIOS y, a continuación, haz clic en Lista dinámica de repositorios.

  2. Para empezar a definir un patrón de destino, en la sección "Criterios de destino", selecciona Agregar un destino , y haz clic en Incluir por patrón o Excluir por patrón.

  3. En el cuadro de diálogo modal que aparece, escribe un patrón de nomenclatura de repositorio mediante la sintaxis fnmatch y, a continuación, haz clic en Agregar patrón de inclusión o Agregar patrón de exclusión. Para más información sobre la sintaxis fnmatch, consulta "Uso de la sintaxis fnmatch".

    Nota: Puedes agregar varios criterios de selección de destino al mismo conjunto de reglas. Por ejemplo, podrías incluir cualquier repositorio que coincida con el patrón *cat* y, a continuación, excluir específicamente un repositorio que coincida con el patrón not-a-cat.

  4. Opcionalmente, en la página de configuración del conjunto de reglas, selecciona Impedir cambiar el nombre de los repositorios de destino.

Establecer repositorios como destinos por propiedades en tu organización

Puede dirigirse a repositorios de su organización mediante propiedades personalizadas. Para obtener más información, vea «Administración de propiedades personalizadas para repositorios de la organización».

  1. Para definir como destino una lista dinámica de repositorios de la organización por propiedades, en la sección «Repositorios de destino», selecciona Destino: REPOSITORIOS y, a continuación, haz clic en Lista dinámica por propiedades.
  2. Para agregar un destino, en la sección «Criterios de destino», selecciona Agregar un destino , y haz clic en Incluir por propiedad o Excluir por propiedad.
  3. En el diálogo modal que aparece, selecciona una propiedad en el menú desplegable y, a continuación, selecciona un valor para la propiedad.
  4. Haz clic en Agregar tablas.

Destino de repositorios seleccionados en la organización

  1. Para definir como destino una lista estática seleccionada manualmente de repositorios de la organización, en la sección "Repositorios de destino", selecciona Destino: REPOSITORIOS y, a continuación, haz clic en Seleccionar repositorios.
  2. Para seleccionar repositorios de destino, en la sección "Criterios de selección de destino", selecciona Seleccionar repositorios y busca el nombre de cada repositorio al que deseas dirigirte. Selecciona cada repositorio en los resultados de la búsqueda.

Elección de las ramas o etiquetas de destino

Para definir ramas o etiquetas, en la sección "Ramas objetivo" o "Etiquetas objetivo", seleccione Agregar un objetivo y, a continuación, seleccione cómo desea incluir o excluir ramas o etiquetas. Puedes usar la sintaxis fnmatch para incluir o excluir ramas o etiquetas en función de un patrón. Para más información, consulta "Uso de la sintaxis fnmatch".

Puedes agregar varios criterios de selección de destino al mismo conjunto de reglas. Por ejemplo, podrías incluir la rama predeterminada, incluir cualquier rama que coincida con el patrón *feature* y, a continuación, excluir específicamente una rama que coincida con el patrón not-a-feature.

Selección de protecciones de rama o etiqueta

En la sección "Protecciones de ramas" o "Protecciones de etiquetas", selecciona las reglas que deseas incluir en el conjunto de reglas. Al seleccionar una regla, es posible que puedas especificar una configuración adicional para la regla. Para obtener más información sobre las reglas, consulta "Reglas disponibles para conjuntos de reglas".

Notas: Si seleccionas Requerir comprobaciones de estado antes de la combinación en la sección "Configuración adicional":

  • Puedes escribir el nombre de cada comprobación de estado que quieres requerir. Para terminar de agregar la comprobación de estado como requisito, debes hacer clic en .
  • Si seleccionas Requerir que las ramas estén actualizadas antes de combinar, debes definir una comprobación para que la protección surta efecto.

Adición de restricciones de metadatos

Notas:

  • Agregar restricciones de metadatos puede afectar a la experiencia de los usuarios que contribuyen al repositorio. Antes de aplicar un conjunto de reglas con restricciones de metadatos, puedes seleccionar el estado de cumplimiento "Evaluar" para el conjunto de reglas para probar los efectos de las restricciones de metadatos sin que ello afecte a los colaboradores. Para más información sobre las restricciones de metadatos, consulta "Reglas disponibles para conjuntos de reglas".
  • Las restricciones de metadatos están pensadas para aumentar la coherencia entre confirmaciones en el repositorio. No están diseñadas para reemplazar medidas de seguridad, como requerir la revisión de código mediante solicitudes de cambios.
  • Si realizas en una rama una fusión mediante combinación con "squash", todas las confirmaciones de esa rama deben cumplir los requisitos de metadatos de la rama base.
  1. Opcionalmente, en la sección "Restricciones de metadatos", para agregar una regla para controlar los metadatos de las confirmaciones que se insertan en la rama o etiqueta, haz clic en .

    Captura de pantalla de la sección "Restricción de metadatos". A la derecha del encabezado, se resalta un icono más con un contorno naranja.

  2. Configure las opciones de la regla de restricción de metadatos y, a continuación, haga clic en Agregar. Puedes agregar varias restricciones al mismo conjunto de reglas.

    Para la mayoría de los requisitos, como "Debe empezar con un patrón coincidente", el patrón que escribas se interpreta literalmente y no se admiten caracteres comodín. Por ejemplo, el carácter * solo representa el carácter literal *.

    Para patrones más complejos, puedes seleccionar "Debe coincidir con un patrón regex determinado" o "No debe coincidir con un patrón regex determinado", y luego usar la sintaxis de expresión regular para definir el patrón coincidente. Para obtener más información, consulta "Uso de expresiones regulares para metadatos de confirmación".

    Cualquier persona que vea los conjuntos de reglas de un repositorio podrá ver la descripción que proporciones.

Finalización del conjunto de reglas y pasos siguientes

Para terminar de crear el conjunto de reglas, haga clic en Crear. Si el estado de cumplimiento del conjunto de reglas se establece en "Activo", el conjunto de reglas entra en vigor inmediatamente.

Puede ver información sobre el conjunto de reglas para ver cómo afectan las reglas a los colaboradores. Si el estado de cumplimiento se establece en "Evaluar", puede ver qué acciones habrían pasado o fallado si el conjunto de reglas estaba activo. Para más información sobre conclusiones para conjuntos de reglas, consulte "Administración de conjuntos de reglas de un repositorio".

Información sobre patrones fnmatch para ramas, etiquetas y repositorios

Puede usar la sintaxis fnmatch para definir patrones para establecer como destino los nombres de ramas, etiquetas y repositorios al crear un conjunto de reglas.

Puede usar el carácter comodín * para que coincida con cualquier cadena de caracteres. Como GitHub usa la marca File::FNM_PATHNAME para la sintaxis File.fnmatch, el carácter comodín * no coincide con los separadores de directorios (/). Por ejemplo, qa/* coincidirá con todas las ramas que comienzan por qa/ y que contienen una sola barra diagonal, pero no coincidirá con qa/foo/bar. Puedes incluir cualquier número de barras diagonales después de qa con qa/**/*, que coincidiría, por ejemplo, con qa/foo/bar/foobar/hello-world. También puedes extender la cadena qa con qa**/**/* para que la regla sea más inclusiva.

Para más información sobre las opciones de sintaxis, consulta la documentación de fnmatch.

Nota: No todas las expresiones de la sintaxis fnmatch se admiten en las reglas de protección de ramas. Ten presente las siguientes consideraciones:

  • No se puede usar el carácter de barra diagonal inversa (\) como carácter de comillas, ya que GitHub no admite el uso de barras diagonales inversas en las reglas de protección de ramas.
  • Puedes especificar juegos de caracteres entre corchetes ([]), pero actualmente no puedes complementar un conjunto con el operador ^ (por ejemplo, [^charset]).
  • Aunque GitHub admite File::FNM_PATHNAME en la sintaxis de fnmatch, File::FNM_EXTGLOB no se admite.

Información sobre expresiones regulares para metadatos de confirmación

Al agregar restricciones de metadatos, puedes usar la sintaxis de expresión regular para definir patrones con los que los metadatos pertinentes, como el mensaje de confirmación o el nombre de la rama o etiqueta, deben o no coincidir.

Los conjuntos de reglas admiten la sintaxis RE2. Para más información, consulta la guía de la sintaxis de Google. Para validar las expresiones, puedes usar el validador en regex101.com, seleccionando el tipo "Golang" en la barra lateral izquierda.

De forma predeterminada, en las restricciones de metadatos las expresiones regulares no tienen en cuenta varias líneas de texto. Por ejemplo, si tienes un mensaje de confirmación con varias líneas, el patrón ^ABC será una coincidencia si la primera línea del mensaje comienza por ABC. Para que coincidan varias líneas del mensaje, inicia la expresión con (?m).

No se admite la aserción de búsqueda anticipada (lookahead) negativa, indicada como ?!. Sin embargo, en los casos en los que necesites buscar una cadena determinada que no vaya seguida de otra cadena específica, puedes usar la aserción de búsqueda anticipada (lookahead) positiva, indicada como ?, combinada con el requisito "No debe coincidir con un patrón regex determinado".

Nota: Si necesitas que los colaboradores cierren sesión en las confirmaciones, esto puede interferir con los patrones de expresiones regulares. Cuando alguien cierra sesión, GitHub agrega una cadena como Signed-off-by: #AUTHOR-NAME <#AUTHOR-EMAIL> al mensaje de confirmación. Para obtener más información, vea «Administración de la directiva de aprobación de confirmaciones para la organización».

Patrones de expresiones regulares útiles

En los ejemplos siguientes se proporcionan patrones útiles para los metadatos de confirmación. Para usar estos patrones, establece Requisito en "Debe coincidir con un patrón regex determinado".

Asegurarse de que los nombres de rama son compatibles con Windows

Puedes usar el siguiente patrón para asegurarte de que los nombres de rama solo incluyen números, letras minúsculas y los caracteres - y _. Esto garantiza que los nombres de rama sean compatibles con sistemas operativos que no usen sistemas de archivos que distinguen mayúsculas de minúsculas de forma predeterminada.

Text
\A[0-9a-z-_]$

Coincide con: my-branch.

No coincide con: myBranch.

Asegurarse de que los nombres de etiqueta usan el versionamiento semántico

Puedes usar el siguiente patrón para asegurarte de que los nombres de etiqueta se ajustan al versionamiento semántico. Para obtener más información, consulta la documentación sobre semver.org.

Text
^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$

Coincide con: 1.2.3, 10.20.30 y 1.1.2-prerelease+meta.

No coincide con: 1.2 y 1.2-SNAPSHOT.

Limitar la longitud de las líneas en los mensajes de confirmación

El libro Pro Git recomienda limitar la primera línea de un mensaje de confirmación a unos 50 caracteres.

Puedes usar el siguiente patrón para asegurarte de que la primera línea de un mensaje de confirmación contiene 50 caracteres o menos.

Text
\A.{1,50}$
Asegurarse de que los mensajes de confirmación comienzan con una resolución y un número de incidencia

Puedes usar el siguiente patrón para asegurarte de que los mensajes de confirmación contienen la palabra Resolves: o Fixes:, seguida de una cadena como #1234.

Text
^(Resolves|Fixes): \#[0-9]+$

Coincide con: Fixes: #1234.

No coincide con: Add conditional logic to foo.bar.

Aplicación de confirmaciones convencionales

Puedes usar el siguiente patrón para asegurarte de que los mensajes de confirmación se ajustan a la especificación de confirmaciones convencionales. Para obtener más información, consulta conventionalcommits.org.

Text
^(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test){1}(\([\w\-\.]+\))?(!)?: ([\w ])+([\s\S]*)

Coincide con: feat: allow provided config object to extend other configs.

No coincide con: Add conditional logic to foo.bar.