GitHub AE release notes

Los propietarios de empresa pueden unirse a organizaciones de GitHub AE como miembro o como propietario desde la página Organizaciones de la cuenta de la empresa. Para más información, vea "Administración del rol en una organización que pertenece a la empresa".

Los roles de repositorio personalizados están disponibles con carácter general. Con los roles de repositorio personalizados, los propietarios de organizaciones ahora tienen un control más granular sobre los permisos de acceso al repositorio que pueden conceder a los usuarios. Los roles de repositorio personalizados también son totalmente compatibles con la API REST. Para más información, consulta "Administración de roles de repositorio personalizados para una organización" y "Organizaciones" en la documentación de la API REST.

Los propietarios empresariales pueden evitar que los propietarios de organizaciones inviten a colaboradores a los repositorios de GitHub AE. Para obtener más información, consulta "Aplicación de una directiva para invitar a colaboradores a los repositorios".

Los usuarios pueden optar por recibir un evento de webhook que se desencadene cuando alguien habilite o deshabilite una característica de análisis o seguridad de código para una organización o repositorio. Para más información, consulte la siguiente documentación.

• "Eventos y cargas útiles de un webhook" en la documentación del webhook
• "Administración de la configuración de seguridad y análisis de la organización"
• "Administración de características de seguridad y análisis para el repositorio"

Los propietarios empresariales y los usuarios pueden ver las alertas de examen de secretos y evitar la protección de inserciones de examen de secretos en los registros de auditoría de la empresa y la organización mediante la API REST. Para más información, consulte la siguiente documentación.

• "Protección de inserciones con examen de secretos"
• "Eventos de registro de auditoría de la empresa"
• "Revisión del registro de auditoría de la organización"
• "Examen de secretos" en la documentación de la API REST

Ahora los propietarios de organizaciones pueden configurar dos nuevos permisos para el examen de secretos al administrar roles de repositorio personalizados.

• Ver resultados del examen de secretos
• Descartar o reabrir resultados del examen de secretos

Para más información, vea "Administración de roles de repositorio personalizados para una organización".

Los usuarios pueden ejecutar un simulacro de patrones de examen de secretos personalizados en el nivel de empresa, organización o repositorio, en función de su acceso. Los simulacros permiten a los usuarios revisar y perfeccionar sus patrones antes de publicarlos y generar alertas. Puedes redactar un patrón y luego utilizar Guardar y simular para recuperar los resultados. Los exámenes generalmente tardan solo unos segundos, pero GitHub AE también notificará a los usuarios por correo electrónico cuando los resultados del simulacro estén listos. Para más información, consulta "Acerca del examen de secretos" y "Definición de patrones personalizados para el examen de secretos".

Los usuarios pueden habilitar el examen de secretos para repositorios archivados mediante la interfaz de usuario o la API. Para más información, consulta "Acerca del examen de secretos", "Acerca de los repositorios archivados" y "Repositorios" en la documentación de la API REST.

El examen de secretos impide la filtración de secretos en el editor web. Para más información, vea "Protección de inserciones para el examen de secretos".

El examen del código ahora detecta una mayor cantidad de CWE, y el examen del código de CodeQL es totalmente compatible con las funciones de idioma estándar en las siguientes versiones de idioma.

• C# 10/.NET 6
• Python 3.10
• Java 17
• TypeScript 4.5

Para más información, consulta el blog de GitHub.

Los propietarios de la organización y los administradores de seguridad pueden ver las alertas de examen de código en la pestaña Seguridad de una organización. Para más información, consulta "Acerca de la información general de seguridad".

La página de alerta de examen del código ahora siempre muestra el estado de la alerta y la información de la rama predeterminada. Hay un nuevo panel "Sucursales afectadas" en la barra lateral donde puedes ver el estado de la alerta en otras ramas. Si la alerta no existe en tu rama predeterminada, la página de alerta mostrará el estado como "En rama" o "En solicitud de incorporación de cambios" para la ubicación donde se vio la alerta por última vez. Esta mejora facilita la comprensión del estado de las alertas que se han introducido en la base de código. Para más información, vea "Acerca de las alertas de análisis de código". La página de la lista de alertas no cambia y se puede filtrar por branch. Puedes usar la API de examen del código para recuperar información de rama más detallada para alertas. Para más información, consulta "Examen del código" en la documentación de la API REST.

El examen del código ahora muestra los detalles del origen del análisis de una alerta. Si una alerta tiene más de un origen de análisis, se muestra en la barra lateral "Ramas afectadas" y en la línea de tiempo de la alerta. Los usuarios pueden mantener el puntero sobre el icono del origen del análisis en la barra lateral "Ramas afectadas" para ver el estado de alerta en cada origen del análisis. Si una alerta solo tiene un único origen de análisis, no se muestra información sobre los orígenes de análisis en la página de alerta. Estas mejoras facilitarán la comprensión de las alertas. En concreto, ayudará a los usuarios a comprender las que tienen varios orígenes de análisis. Esto es especialmente útil para ajustes con varias configuraciones de análisis, como repositorios únicos. Para más información, vea "Acerca de las alertas de análisis de código".

Los usuarios pueden usar los parámetros sort y direction en la API REST cuando recuperan alertas de examen de secretos y ordenar en función de los campos created o updated de la alerta. Los nuevos parámetros están disponibles para toda la implementación de GitHub AE, o bien para organizaciones o repositorios individuales. Para más información, consulte la siguiente documentación.

• "Enumeración de alertas de examen de secretos para una empresa"
• "Enumeración de alertas de examen de secretos para una organización"
• "Enumeración de alertas de examen de secretos para un repositorio"
• "Examen de secretos" en la documentación de la API REST

Los usuarios pueden optar por recibir un webhook que se desencadene cuando se detecte un secreto en una nueva ubicación. El evento de webhook secret_scanning_alert_location incluye detalles de ubicación, como el SHA de confirmación, y la alerta asociada para la detección. Se crea una ubicación para cada nueva ruta de acceso de archivo que contiene el secreto detectado. Para más información, vea "Eventos y cargas de webhook".

Los usuarios pueden agregar de forma opcional un comentario cuando descarten una alerta de examen de código en la IU web o mediante la API REST. Los comentarios de descarte aparecen en la escala de tiempo del evento. Los usuarios también pueden añadir o recuperar un comentario de descarte mediante la API de REST. Para obtener más información, consulta "Evaluación de prioridades de las alertas de examen de código en solicitudes de incorporación de cambios" y "Examen de código" en la documentación de la API REST.

Ahora los usuarios pueden recuperar alertas de examen de código para una organización mediante la API REST. Este nuevo punto de conexión de API complementa al punto de conexión para repositorios existente. Para más información, consulta "Examen del código" en la documentación de la API REST.

Los contenidos del repositorio github/codeql-go se han movido al repositorio github/codeql para que estén en bibliotecas parecidas para todos los otros lenguajes de programación admitidos por CodeQL. Las consultas de código abierto de CodeQL, las bibliotecas y el extractor para analizar códigos bases escritos en el lenguaje de programación Go con las herramientas de análisis de código CodeQL de GitHub se pueden encontrar en la nueva ubicación. Para obtener más información, incluidas las instrucciones para migrar los flujos de trabajo existentes, consulta github/codeql-go#741.

Los propietarios empresariales pueden ver un resumen de las alertas de Dependabot para toda la implementación de GitHub AE, incluida una vista centrada en los repositorios de los riesgos de seguridad de la aplicación, y una vista centrada en las alertas de todas las del examen de secretos y de Dependabot. Las vistas están en versión beta y están sujetas a cambios. Para más información, vea "Visualización de la información general sobre seguridad".

Los propietarios de la organización y los administradores de seguridad pueden ver las alertas de Dependabot en la pestaña Seguridad de una organización. Para más información, consulta "Acerca de la información general de seguridad".

Los usuarios pueden volver a abrir una alerta de Dependabot descartada mediante la interfaz de usuario web. Esto no afecta a las solicitudes de incorporación de cambios de Dependabot ni a la API de GraphQL. Para más información, consulta "Acerca de las alertas de Dependabot".

Los usuarios pueden ver alertas fijas de Dependabot con GraphQL API. Los usuarios también pueden acceder y filtrar por estado, así como por identificador numérico único, y filtrar por estado en el objeto de alerta de vulnerabilidad. Los campos siguientes ahora existen para RepositoryVulnerabilityAlert.

• number
• fixed_at
• fix_reason
• state

Para más información, consulta "Objetos" en la documentación de GraphQL API.

Los propietarios de la organización y los administradores de seguridad pueden usar la información general de seguridad de una organización para ver una vista centrada en el repositorio de los riesgos de seguridad de la aplicación, o bien una vista centrada en las alertas de todas las de examen de código, Dependabot y examen de secretos para todos los repositorios de una organización. Para obtener más información, consulte Acerca de la información general sobre seguridad.

Las Acciones de GitHub pueden imponer revisiones de dependencia en las solicitudes de incorporación de cambios de los usuarios al escanear para dependencias y avisarán a los usuarios sobre sus vulnerabilidades de seguridad asociadas. La acción dependency-review-action está asistida por un nuevo punto de conexión de API que diferencia las dependencias desde dos revisiones cualesquiera. Para más información, vea "Acerca de la revisión de dependencias".

El gráfico de dependencias detecta archivos YAML para flujos de trabajo de Acciones de GitHub. GitHub AE mostrará los archivos de flujo de trabajo dentro de la sección del gráfico de dependencias de la pestaña Conclusiones. Los repositorios que publican acciones también podrán ver la cantidad de repositorios que dependen de esa acción desde el control "Usado por" de la página de inicio del repositorio. Para más información, vea "Acerca del gráfico de dependencias".

El gráfico de dependencias detecta los archivos Cargo.toml y Cargo.lock para Rust. Estos archivos se mostrarán en la sección Gráfico de dependencias de la pestaña Información. Los usuarios recibirán alertas y actualizaciones de Dependabot para detectar vulnerabilidades asociadas a sus dependencias de Rust. Los metadatos del paquete, incluida la asignación de paquetes a repositorios, se añadirán en una fecha posterior. Para más información, vea "Acerca del gráfico de dependencias".

Si GitHub Connect está habilitado para GitHub AE, los usuarios pueden contribuir con una mejora a una asesoría de seguridad en GitHub Advisory Database. Para contribuir, haz clic en Sugerir mejorías para vulnerabilidad en la vista de detalles del asesor. Para obtener más información, consulte los siguientes artículos.

• "Administración de GitHub Connect"
• "Exploración de vulnerabilidades de seguridad en GitHub Advisory Database" en la documentación de GitHub Enterprise Cloud
• "Acerca de los avisos de seguridad de GitHub para repositorios" en la documentación de GitHub Enterprise Cloud
• "Edición de avisos de seguridad en GitHub Advisory Database" en la documentación de GitHub Enterprise Cloud

Los usuarios que mantienen ejecutores autohospedados ahora tienen más control sobre cuándo los ejecutores realizan actualizaciones de software. Si especificas la marca --disableupdate para el ejecutor, este no intentará realizar una actualización de software automática si hay disponible una versión más reciente del ejecutor. Esto permite actualizar el ejecutor autohospedado en función de una programación propia, y es especialmente conveniente si el ejecutor autohospedado está en un contenedor. Para la compatibilidad con el servicio Acciones de GitHub, es necesario actualizar el software del ejecutor dentro de los 30 días posteriores a que haya disponible una versión nueva. Para más información sobre la instalación de la versión más reciente del ejecutor, consulta las instrucciones de instalación de la versión más reciente en actions/runner.

Cuando se utilizan las Acciones de GitHub, para reducir el riesgo de fusionar un cambio que no había sido revisado por otra persona en una rama protegida, los propietarios empresariales y los administradores del repositorio pueden evitar que las Acciones creen solicitudes de incorporación de cambios. Los propietarios de las organizaciones podían habilitar esta restricción previamente. Para obtener más información, consulte los siguientes artículos.

• "Aplicación de directivas de Acciones de GitHub en tu empresa"
• "Deshabilitación o limitación de Acciones de GitHub para la organización"
• "Administración de la configuración de Acciones de GitHub para un repositorio"

Los propietarios de la organización pueden aumentar la seguridad de los flujos de trabajo de CI/CD en ejecutores autohospedados si eligen qué flujos de trabajo pueden acceder a un grupo de ejecutores. Anteriormente, cualquier flujo de trabajo de un repositorio, como un etiquetador de incidencias, podía acceder a los ejecutores autohospedados disponibles para una organización. Para más información, consulta "Administración del acceso a ejecutores autohospedados mediante grupos" y el blog de GitHub.

Los propietarios de la organización pueden controlar si Acciones de GitHub puede aprobar solicitudes de incorporación de cambios. Esta característica protege contra un usuario que usa Acciones de GitHub para cumplir el requisito de protección de rama "Aprobaciones requeridas" y combinar un cambio que otro usuario no revisó. Para evitar interrumpir los flujos de trabajo existentes, Permitir que las revisiones de Acciones de GitHub cuenten para la aprobación requerida está habilitada de manera predeterminada. Los propietarios de la organización pueden deshabilitar la característica en la configuración de Acciones de GitHub de la organización. Para más información, consulta "Deshabilitación o limitación de Acciones de GitHub para la organización".

Los usuarios pueden escribir un único flujo de trabajo desencadenado por workflow_dispatch y workflow_call, y usar el contexto inputs para acceder a los valores de entrada. Anteriormente, las entradas workflow_dispatch estaban en la carga del evento, lo cual aumentaba la dificultad para los creadores de flujos de trabajo que querían escribir un flujo de trabajo que fuera tanto reutilizable como desencadenado manualmente. En el caso de los flujos de trabajo desencadenados por workflow_dispatch, las entradas siguen estando disponibles en el contexto github.event.inputs para mantener la compatibilidad. Para más información, vea "Contextos".

Ahora los usuarios pueden volver a ejecutar solo trabajos con error o un trabajo individual en una ejecución de flujo de trabajo de Acciones de GitHub. Para más información, consulta "Volver a ejecutar flujos de trabajo y trabajos".

Para resumir el resultado de un trabajo, los usuarios pueden generar Markdown y publicar el contenido como un resumen del trabajo. Por ejemplo, después de ejecutar pruebas con Acciones de GitHub, un resumen puede aportar información general de las pruebas aprobadas, falladas u omitidas, reduciendo potencialmente la necesidad de revisar el resultado completo de la bitácora. Para más información, consulta "Comandos de flujo de trabajo para Acciones de GitHub".

Para diagnosticar con más facilidad los fallos al volver a ejecutar un trabajo durante un flujo de trabajo, los usuarios pueden habilitar el registro de depuración, el cual emite información sobre la ejecución y el entorno del trabajo. Para obtener más información, consulta "Volver a ejecutar flujos de trabajo y trabajos" y "Uso de registros de ejecución de flujo de trabajo".

Si gestionas ejecutores autoalojados para Acciones de GitHub, puedes asegurarte de un estado consistente en el propio ejecutor antes y después de ejecutar un flujo de trabajo al definir qué scripts se ejecutan. Al usar scripts, ya no necesitas que los usuarios incorporen manualmente estos pasos en los flujos de trabajo. Los scripts antes y después del trabajo están en versión beta y sujetos a cambios. Para obtener más información, consulta "Ejecución de scripts antes o después de un trabajo".

Los propietarios empresariales pueden configurar una directiva para controlar si los nombres de usuario o los nombres completos de los usuarios se muestran en los repositorios internos. Para más información, vea "Aplicación de directivas de administración de repositorios en la empresa".

Los propietarios empresariales pueden anclar un repositorio al perfil de una organización desde el repositorio mediante el nuevo menú desplegable Anclar repositorio.

Al crear una bifurcación, los usuarios pueden personalizar el nombre de la bifurcación. Para obtener más información, consulte "Bifurcación de un repositorio".

Los usuarios pueden eliminar una rama que esté asociada con una solicitud de incorporación de cambios abierta. Para más información, vea "Creación y eliminación de ramas dentro del repositorio".

CODEOWNERS ha recibido las mejoras siguientes.

• Los errores de sintaxis ahora aparecen al ver un archivo CODEOWNERS desde la IU web. Anteriormente, cuando una línea de un archivo CODEOWNERS tenía un error de sintaxis, este se omitía o, en algunos casos, provocaba que no se cargara todo el archivo CODEOWNERS. Las aplicaciones de GitHub y Acciones de GitHub pueden acceder a la misma lista de errores mediante nuevas API REST y de GraphQL. Para más información, consulta "Repositorios" en la documentación de la API REST y "Objetos" en la documentación de GraphQL API.
• Después de que alguien crea una solicitud de incorporación de cambios o envía nuevos cambios a un borrador de solicitud de incorporación de cambios, los propietarios del código a los que se les solicitará la revisión ahora se enumeran en la solicitud de incorporación de cambios en "Revisores". Esta característica ofrece una visión anticipada de a quién se le solicitará que realice la revisión una vez que la solicitud de incorporación de cambios esté marcada como preparada para revisión.
• Los comentarios en los archivos CODEOWNERS ahora pueden aparecer al final de una línea, no solo en líneas dedicadas.

Para más información, vea "Acerca de los propietarios del código".

Cuando un usuario renombra o mueve un archivo a un nuevo directorio, si al menos la mitad de los contenidos del archivo son idénticos, el historial de confirmación indica que el archivo fue renombrado, de forma similar a git log --follow. Para más información, consulta el blog de GitHub.

Los usuarios pueden requerir una implementación exitosa de una rama antes de que nadie pueda combinar la solicitud de incorporación de cambios asociada con la rama. Para más información, consulta "Acerca de las ramas protegidas" y "Administración de una regla de protección de rama".

Los administradores de repositorios ahora pueden configurar reglas de protección de etiquetas para proteger las etiquetas de un repositorio. Una vez que se protegen por una regla de protección de etiquetas, las etiquetas que coincidan con un patrón de nombre específico solo las pueden crear y eliminar usuarios con el rol de mantenimiento o acceso de administrador al repositorio. Para obtener más información, vea "Configuración de reglas de protección de etiquetas".

Los usuarios pueden omitir las revisiones en la vista de último responsable si crean un archivo .git-blame-ignore-revs en la raíz de un repositorio. Para más información, consulta "Visualización de un archivo".

Los usuarios pueden conceder excepciones a las Aplicaciones de GitHub para cualquier regla de protección de la rama que admita excepciones. Para más información, consulta "Acerca de las aplicaciones" y "Administración de una regla de protección de rama".

Para las claves de firma GPG públicas que han caducado o se han revocado, GitHub AE verifica las firmas de confirmación y muestra las confirmaciones como verificadas si el usuario las ha realizado mientras la clave era todavía válida. Los usuarios también pueden cargar claves GPG caducadas o revocadas. Para obtener más información, consulte "Acerca de la comprobación de firmas de confirmación".

Para afirmar que una confirmación cumple las reglas y licencias del repositorio, los propietarios empresariales y los administradores del repositorio ahora pueden pedirle a los desarrolladores que firmen las confirmaciones hechas a través de la interfaz web. Para obtener más información, consulta "Administración de la directiva de aprobación de confirmaciones para la organización" y "Administración de la directiva de aprobación de confirmaciones para el repositorio".

Al utilizar el árbol de archivos situado en la pestaña Archivos cambiados de una solicitud de incorporación de cambios, los usuarios pueden navegar en archivos modificados, entender el tamaño y ámbito de los cambios y concentrarse en la revisión. El árbol de archivos aparece si una solicitud de incorporación de cambios modifica al menos dos archivos y si la ventana del navegador es suficientemente ancha. Para obtener más información, consulta "Revisión de los cambios propuestos en una solicitud de incorporación de cambios" y "Filtrado de archivos en una solicitud de incorporación de cambios".

Los usuarios pueden usar de forma predeterminada los títulos de la solicitud de incorporación de cambios como mensaje de confirmación para fusión mediante combinación con "squash". Para más información, vea "Configuración de las fusiones mediante combinación con "squash" de confirmaciones para las solicitudes de incorporación de cambios".

El botón Actualizar rama de la página de solicitud de incorporación de cambios permite a los usuarios actualizar la rama de la solicitud de incorporación de cambios con los cambios más recientes de la rama base. Esto es útil para comprobar que los cambios de la solicitud de incorporación de cambios son compatibles con la versión actual de la rama base antes de realizar la combinación. Dos mejoras proporcionan más formas de mantener actualizada una rama.

• Cuando la rama puntual de una solicitud de incorporación de cambios está desactualizada con respecto a la rama base, los usuarios pueden actualizarla si la fusionan mediante cambio de base con la versión más reciente de la rama base. La fusión mediante cambio de base aplica los cambios de la rama puntual a la versión más reciente de la rama base, lo que da lugar a una rama con un historial lineal, ya que no se crea una confirmación de combinación. Para actualizar con la fusión mediante cambio de base, haz clic en el menú desplegable situado junto al botón Actualizar rama, luego en Actualizar con fusión mediante cambio de base y, por último, en Fusionar rama mediante cambio de base. Anteriormente, la opción Actualizar rama realizaba una combinación tradicional que siempre daba lugar a una confirmación de combinación en la rama de solicitud de incorporación de cambios. Esta opción todavía está disponible, pero ahora los usuarios tienen la opción. Para más información, vea "Mantenimiento de la solicitud de incorporación de cambios sincronizada con la rama base".
• Una nueva configuración de repositorio permite que el botón Actualizar rama siempre esté disponible cuando la rama puntual de una solicitud de incorporación de cambios no está actualizada con la rama base. Anteriormente, este botón solo estaba disponible cuando el valor de protección de rama Requerir que las ramas estén actualizadas antes de la combinación estaba habilitado. Las personas con acceso de administrador o de responsable de mantenimiento pueden administrar el valor Sugerir siempre la actualización de ramas de solicitudes de incorporación de cambios desde la sección Solicitudes de incorporación de cambios en la configuración del repositorio. Para más información, consulta "Administración de sugerencias para actualizar ramas de solicitudes de incorporación de cambios".

Al ver los detalles de una versión concreta, los usuarios pueden ver la fecha de creación para cada versión del recurso. Para más información, vea "Visualización de las versiones y etiquetas del repositorio".

Al crear una versión con notas de la versión generadas automáticamente, los usuarios pueden ver que la etiqueta se identifica como la versión anterior y, a continuación, seleccionar una etiqueta diferente para especificar como la versión anterior. Para más información, vea "Notas de la versión generadas automáticamente".

Gists ahora solo muestra los 30 comentarios más recientes cuando se muestran por primera vez. Los usuarios pueden hacer clic en Cargar comentarios anteriores... para ver más. Esto permite que los gists que tienen muchos comentarios aparezcan más rápidamente. Para más información, consulta "Edición y uso compartido de contenido con gists".

La edición de Markdown en la interfaz web se ha mejorado.

• Después de que un usuario seleccione texto y pegue una URL, el texto seleccionado se convertirá en un hipervínculo de Markdown a la URL pegada.
• Cuando un usuario pega celdas de una hoja de cálculo o tablas HTML, el texto resultado se representará como una tabla.
• Cuando un usuario copie texto que contenga hipervínculos, el texto pegado incluirá el hipervínculo como hipervínculo de Markdown.

Para más información, vea "Sintaxis básica de escritura y formato".

Al editar un archivo Markdown en la interfaz web, al hacer clic en la pestaña Versión preliminar se desplazará automáticamente al lugar que se estaba editando en la versión preliminar. La ubicación del desplazamiento se basa en la posición del cursor antes de hacer clic en la pestaña Versión preliminar.

Ahora hay disponible un tema de contraste alto claro, con mayor contraste entre los elementos de primer plano y de fondo. Para más información, vea "Administración de la configuración de temas".

Las listas de repositorios propiedad de un usuario u organización ahora tienen una opción de filtro adicional, "Plantillas", lo que facilita la búsqueda de repositorios de plantillas.

GitHub AE puede mostrar varios formatos de imagen comunes, incluidos PNG, JPG, GIF, PSD y SVG, y ofrece varias formas de comparar las diferencias entre versiones. Ahora, al revisar las imágenes agregadas o modificadas en una solicitud de incorporación de cambios, las vistas previas de esas imágenes se muestran de forma predeterminada. Anteriormente, los usuarios veían un mensaje que indicaba que los archivos binarios no se podían mostrar y tenían que alternar la opción "Mostrar diferencias enriquecidas". Para más información, consulta "Uso de archivos que no son de código".

Se han rediseñado las páginas de configuración para usuarios, organizaciones, repositorios y equipos, agrupando páginas de configuración similares en secciones para mejorar la arquitectura de la información y la capacidad de detección. Para más información, consulta el registro de cambios de GitHub.

Los elementos interactivos de la interfaz web como hipervínculos y botones muestran un contorno visible cuando se enfocan con el teclado, para ayudar a los usuarios a encontrar la posición actual en una página. Además, cuando se enfocan, los campos de formulario tienen un contorno con un contraste mayor.

Al enfocar o mantener el puntero sobre una etiqueta, ahora se muestra una información sobre herramientas con la descripción de la etiqueta.

Si un usuario actualiza la página mientras crea una incidencia o solicitud de incorporación de cambios, se conservarán los usuarios asignados, los revisores, las etiquetas y los proyectos.

A fin de usar el flujo de autorización del dispositivo para aplicaciones de OAuth y GitHub, los creadores de aplicaciones deben habilitar manualmente la característica. Este cambio reduce la probabilidad de que las aplicaciones se utilicen en ataques de suplantación de identidad (phishing) contra los usuarios de GitHub AE al garantizar que los integradores son conscientes de los riesgos y tomen una decisión consciente para admitir esta forma de autenticación. Los usuarios que poseen o administran una aplicación de OAuth o GitHub, y que quieren usar el flujo de dispositivos, pueden habilitarlo para una aplicación desde su página de configuración. Los puntos de conexión de la API de flujo de dispositivos responderán con código de estado 400 a las aplicaciones que no han habilitado esta característica. Para obtener más información, consulte "Autorización de aplicaciones de OAuth".

Los usuarios con acceso de administrador a un repositorio pueden comprender mejor quién tiene acceso al repositorio, ver qué nivel de acceso tiene cada usuario y administrar más fácilmente el acceso al repositorio. Por ejemplo, los usuarios pueden realizar las tareas siguientes.

• Buscar todos los miembros, equipos y colaboradores que tienen acceso al repositorio.
• Ver cuándo los miembros tienen asignaciones de roles mixtas, concedidos de manera directa como individuos, o bien de manera indirecta mediante un equipo: una nueva advertencia de "roles mixtos" muestra el rol de nivel más alto que se concede el usuario si su acceso es mayor que su rol asignado.

Para obtener más información, vea "Administración de equipos y personas con acceso al repositorio".

Ahora los propietarios de empresas pueden mostrar vínculos adicionales a miembros y colaboradores de la empresa en un pie de página personalizado. Para más información, consulta "Configuración de pies de página personalizado".

Los usuarios pueden reutilizar un flujo de trabajo con una sola línea de configuración. Los flujos de trabajo reutilizables ahorran tiempo y mantenimiento al quitar la necesidad de copiar y pegar definiciones de flujo de trabajo entre repositorios. Los flujos de trabajo reutilizables se encuentran actualmente en versión beta y están sujetos a cambios. Para más información, vea "Reutilización de flujos de trabajo".

La experiencia de administración actualizada para los ejecutores autohospedados simplifica la administración de grupos de ejecutores y proporciona una visión general mejorada de los ejecutores. Para más información, consulta "Acerca de los ejecutores autohospedados" y "Administración del acceso a ejecutores autohospedados mediante grupos".

Ahora Dependabot comparte secretos con Acciones de GitHub cuando desencadena una ejecución de flujo de trabajo, de forma que ahora los usuarios pueden extraer de registros de paquetes privados dentro de canalizaciones de CI mediante secretos de Dependabot. Para más información, vea "Administración de secretos cifrados para Dependabot".

Los usuarios pueden usar una construcción if condicional para evitar que se ejecuten pasos específicos en una acción compuesta a menos que se cumpla una condición. Como sucede con los pasos definidos en los flujos de trabajo, puedes usar cualquier contexto y expresión admitidos para crear una condicional. Para más información sobre las acciones compuestas, consulta "Creación de una acción compuesta".

Los usuarios pueden proporcionar una mejor experiencia a los usuarios de un flujo de trabajo mediante la especificación de tipos de entrada para flujos de trabajo desencadenados de forma manual. Ahora los flujos de trabajo admiten choice, booleany environment. Para más información, vea "Sintaxis de flujo de trabajo para Acciones de GitHub".

El primer ejecutor coincidente disponible en el nivel de repositorio, organización o empresa ejecutará cada trabajo en todos los casos, lo que significa que los trabajos se envían a ejecutores autohospedados mucho más rápido, especialmente para organizaciones y empresas con muchos ejecutores autohospedados. Anteriormente, al ejecutar un trabajo que necesitaba un ejecutor autohospedado, Acciones de GitHub tenía que buscar ejecutores autohospedados en el repositorio, la organización y la empresa, en ese orden. Para más información, consulta "Uso de ejecutores autohospedados en un flujo de trabajo".

Los usuarios pueden especificar que una acción de JavaScript se debe ejecutar en Node.js 16 si especifica runs.using como node16. La compatibilidad con Node.js 16 complementa la existente para Node.js 12. Los ejecutores deben tener instalada la versión 2.285.0 o posterior del ejecutor de Acciones de GitHub. Para más información, consulta "Sintaxis de metadatos para Acciones de GitHub" y el repositorio actions/runner.

Los usuarios pueden agregar, enumerar y quitar etiquetas para los ejecutores autohospedados mediante la API REST. Para más información, consulta "Ejecutores autohospedados" en la documentación de la API REST.

Los usuarios pueden mejorar la seguridad de los servicios y herramientas creados con Ruby mediante el examen de código de CodeQL. Para todas las versiones comunes de Ruby hasta la versión 3.02, CodeQL puede detectar problemas comunes, como los de inyección de código SQL, ReDoS, comando del sistema operativo e inserción de argumentos, expansión de entidades XML, scripting entre sitios (XSS), XSS almacenado, deserialización no segura y credenciales codificadas de forma rígida. Para habilitar el análisis de Ruby, los usuarios deben actualizar un archivo de flujo de trabajo de examen de código de CodeQL existente. La compatibilidad de Ruby con CodeQL se encuentra en versión beta y está sujeta a cambios. Para más información, consulta "Configuración del examen de código" y la documentación de CodeQL. Para más información sobre el examen de código con CodeQL, consulta "Acerca del examen de código con CodeQL".

El análisis de Python de CodeQL admite marcos adicionales y puede detectar más orígenes de datos de usuario que no son de confianza, pasos por los que fluyen esos datos y receptores potencialmente peligrosos en los que estos datos podrían terminar. Para más información, consulta "Lenguajes y marcos admitidos" en la documentación de CodeQL.

Los usuarios pueden recuperar los detalles de confirmación de los secretos detectados en los exámenes del repositorio privado mediante la API REST. El nuevo punto de conexión mostrará detalles de la primera detección de un secreto en un archivo, incluida su ubicación y el SHA de confirmación. Para más información, consulta "Acerca del examen de secretos" y "Examen de secretos" en la documentación de la API REST.

La API de examen de código incluye las siguientes mejoras.

• Las alertas incluyen la marca de tiempo fixed_at, que indica la primera vez que no se ha detectado la alerta en un análisis Los usuarios pueden usar estos datos para comprender mejor cuándo se corrigen las alertas de examen de código.
• Los usuarios pueden ordenar los resultados de alertas más importantes mediante sort y direction en created, updated o number. Para más información, consulta Examen del código en la documentación de la API REST.
• Las alertas y la respuesta del punto de conexión de alerta incluyen un encabezado Last-Modified. Para más información, consulta Last-Modified en la documentación de Mozilla.
• Las respuestas SARIF para los análisis de examen de código incluyen relatedLocations, que puede contener ubicaciones que no son la principal de la alerta. Para obtener un ejemplo, consulta la especificación SARIF. Para más información, consulta Examen de código en la documentación de la API REST.
• El objeto de regla de alertas de respuesta de webhook incluye datos help y tags. Para más información, vea "Eventos y cargas de webhook".

Los propietarios de la organización y los administradores de seguridad pueden recuperar los resultados del examen de secretos de los repositorios privados en el nivel empresarial mediante la API REST. Para más información, consulta "Acerca del examen de secretos" y "Examen de secretos" en la documentación de la API REST.

Los usuarios pueden descartar las alertas de Dependabot mediante GraphQL API. Para más información, consulta "Mutaciones" en la documentación de GraphQL API.

El gráfico de dependencias detecta dependencias de Python en repositorios en los que se usa el administrador de paquetes Poetry. Las dependencias se detectarán desde los archivos de manifiesto pyproject.toml y poetry.lock. Para más información, vea "Acerca del gráfico de dependencias".

Los desarrolladores e investigadores de seguridad pueden usar CodeQL para crear bases de datos y analizar código en máquinas con chips de silicio de Apple, como M1. Tanto la CLI de CodeQL como la extensión de VS Code admiten silicio de Apple. Para usar la CLI de CodeQL o la extensión de VS Code en silicio de Apple, los usuarios deben instalar las herramientas para desarrolladores de la línea de comandos de Xcode y Rosetta 2. La compatibilidad de CodeQL con el silicio de Apple se encuentra en versión beta y está sujeta a cambios.

• Para más información sobre la configuración de la CLI de CodeQL en plataformas compatibles, consulta "Uso de la CLI de CodeQL" en la documentación de CodeQL.
• Para más información sobre CodeQL, consulta "Acerca de CodeQL" en la documentación de CodeQL y "Acerca del examen de código".

Los usuarios de las versiones 2.7.1 de la CLI de CodeQL y posteriores pueden incluir ayuda de consulta en archivos SARIF como Markdown y el texto de ayuda aparecerá en la interfaz de usuario de examen de código de GitHub AE. Los usuarios pueden incluir ayuda de consulta como un archivo Markdown con el mismo nombre que el archivo de consulta correspondiente. Por ejemplo, si el archivo de consulta es MyCustomQuery.ql, el nombre del archivo de ayuda de consulta sería MyCustomQuery.md. Para más información sobre la creación de la ayuda de consulta para consultas de CodeQL personalizadas, consulta la guía de estilo de ayuda de consulta.

• Los usuarios que no usan Acciones de GitHub para CI/CD y el examen de código deben especificar la adición de ayuda de consulta al ejecutar el comando codeql database analyze mediante la inclusión de la marca --sarif-add-query-help. Para más información, consulta "Análisis de bases de datos con la CLI de CodeQL" en la documentación de CodeQL.

Los usuarios pueden cancelar la suscripción a todos los repositorios que pertenecen a un usuario o organización determinado. Para más información, consulte "Administración de sus suscripciones".

Los propietarios de la organización pueden cancelar la suscripción a las notificaciones por correo electrónico cuando se agregan nuevas claves de implementación a repositorios propiedad de sus organizaciones. Para más información, vea "Configuración de notificaciones".

La línea de asunto de las notificaciones por correo electrónico para incidencias y solicitudes de incorporación de cambios incluye "(Issue #NUMBER)" o "(PR #NUMBER)" para ayudar a los usuarios a distinguir fácilmente entre los dos tipos de notificación.

El vínculo Ver en GitHub en la parte inferior de las notificaciones por correo electrónico ya no está oculto de manera predeterminada en Gmail.

Ahora los miembros de la organización pueden ver una lista de propietarios de empresa. Cada vez que un miembro de la organización encuentra un mensaje para ponerse en contacto con un propietario de la empresa, un vínculo dirigirá al usuario a la lista. La lista también es accesible mediante el objeto Organization de GraphQL API en el punto de conexión enterpriseOwners. Para obtener más información, vea "Visualización de los roles de las personas en una organización".

Los usuarios con acceso de administrador a un repositorio pueden cambiar el nombre de las ramas protegidas por reglas de protección de ramas. Para más información, consulta "Cambio de nombre de una rama" y "Administración de una regla de protección de rama".

En lugar de permitir que todos los usuarios, o ninguno, fuercen la inserción, los usuarios con acceso de administrador a un repositorio pueden elegir quién puede forzar la inserción en el repositorio. Para más información, consulta "Acerca de las ramas protegidas" y "Administración de una regla de protección de rama".

Los usuarios con acceso de administrador a un repositorio pueden exigir que todos los cambios en una rama protegida se realicen mediante una solicitud de incorporación de cambios, pero sin necesidad de revisiones. Para más información, consulta "Acerca de las ramas protegidas" y "Administración de una regla de protección de rama".

Los usuarios con acceso de administrador a un repositorio pueden permitir que usuarios y equipos específicos omitan los requisitos de solicitud de incorporación de cambios. Para más información, vea "Administración de una regla de protección de rama".

Los usuarios pueden utilizar prefijos de un solo carácter para vínculos automáticos personalizados. En los prefijos de vínculos automáticos también se permiten los caracteres ., -, _, +, =, :, / y #, además de caracteres alfanuméricos. Para más información, vea "Configuración de vínculos automáticos para hacer referencia a recursos externos".

Los usuarios pueden habilitar Notificar solo a los miembros de equipo solicitados independientemente de Habilitar la asignación automática en la configuración de revisión de código del equipo, lo que permite a los usuarios exigir la revisión del equipo, pero sin notificar siempre a todo el equipo innecesariamente. Para más información, consulta "Administración de la configuración de revisión del código para el equipo".

Se ha mejorado la interfaz de usuario de versiones, lo que proporciona claridad sobre lo que se incluye en una versión determinada y el reconocimiento de los colaboradores de la versión. Se ha mejorado la paginación y hay disponible una nueva funcionalidad de búsqueda.

Los usuarios pueden generar automáticamente notas de la versión que incluyan un resumen de todas las solicitudes de incorporación de cambios para una versión determinada. Para más información, vea "Notas de la versión generadas automáticamente".

Los usuarios pueden obtener una vista previa de las representaciones de archivos Markdown en gists. Al crear o editar un archivo gist con la extensión de archivo de Markdown (.md), en una pestaña Vista previa o Vista previa de los cambios se mostrará una representación de Markdown del contenido del archivo. Para obtener más información sobre los gists, consulta "Editar y compartir contenido con gists".

Los usuarios pueden optar por usar una fuente de ancho fijo en campos de Markdown, como en los comentarios sobre incidencias y solicitudes de incorporación de cambios. Para más información, consulta "Acerca de la escritura y el formato en GitHub".

Los usuarios pueden especificar el tema para el que se muestra una imagen en Markdown. Para más información, vea "Sintaxis básica de escritura y formato".

Los usuarios pueden crear rápidamente un vínculo de Markdown mientras editan texto en campos habilitados para Markdown, como los comentarios de incidencias o solicitudes de incorporación de cambios, si seleccionan texto y pegan una dirección URL.

Los vínculos HTML que los usuarios pegan en campos de Markdown se convierten automáticamente en vínculos de Markdown. Para pegar vínculos HTML como texto sin formato, presiona ⌘/ctrl + mayús + v.

Los idiomas que se escriben de derecha a izquierda se admiten de forma nativa en los archivos Markdown y comentarios de incidencias, solicitudes de incorporación de cambios y debates.

Los usuarios pueden establecer un tamaño de pestaña preferido. Todo el código de GitHub AE con pestañas se representará con el tamaño de pestaña preferido. Para más información, consulta "Administración de la preferencia de representación de tamaño de pestaña".

Los usuarios pueden administrar métodos abreviados de teclado con la nueva configuración de accesibilidad de GitHub AE y pueden optar por deshabilitar los métodos abreviados de teclas de carácter que solo usan caracteres individuales, como s, g c y . (la tecla de punto). Para más información, consulta "Administración de la configuración de accesibilidad".

Para garantizar que la aplicación prevista valide todos los cambios, ahora los usuarios pueden controlar qué aplicación de GitHub proporciona una comprobación de estado necesaria. Si, después, el estado lo proporciona otra aplicación, o bien un usuario mediante un estado de confirmación, se evitará la combinación. Las comprobaciones de estado necesarias existentes seguirán aceptando el estado de cualquier aplicación, pero solo se pueden actualizar para aceptar el estado de una aplicación específica. Las comprobaciones de estado necesarias recién agregadas tendrán como valor predeterminado la aplicación que más recientemente haya notificado el estado, pero puedes elegir otra diferente o permitir que cualquier aplicación proporcione el estado. Para más información, consulta "Acerca de las ramas protegidas" y "Edición de una regla de protección de rama".

Los propietarios y usuarios de la organización con acceso de administrador a un repositorio pueden desencadenar webhooks para escuchar los cambios en las reglas de protección de ramas. Para más información, vea "Eventos y cargas de webhook".

El examen del código de códigos y el examen de secretos ahora están disponibles con carácter general para GitHub AE. Para obtener más información, vea «Acerca del examen de código» y «Acerca del examen de secretos».

Los patrones personalizados para el examen de secretos ya están disponibles con carácter general. Para obtener más información, vea «Definición de patrones personalizados para el examen de secretos».

Ahora puedes encontrar todas las alertas de examen del código asociadas con la solicitud de incorporación de cambios con el nuevo filtro de solicitudes de incorporación de cambios en la página de alertas de examen del código. La página de comprobaciones de solicitudes de incorporación de cambios muestra las alertas introducidas en una solicitud de incorporación de cambios, pero no las alertas existentes en la rama de solicitudes de incorporación de cambios. El nuevo vínculo "Ver todas las alertas de la rama" en la página Comprobaciones lleva a la página de alertas de examen del código con el filtro específico de solicitudes de incorporación de cambios ya aplicado, de forma que puedes ver todas las alertas asociadas con tu solicitud de incorporación de cambios. Esto puede ser útil para administrar muchas alertas y ver información más detallada para alertas individuales. Para obtener más información, consulte "Administrar alertas de análisis de código para el repositorio".

GitHub Advanced Security ahora ofrece una vista a nivel de organización de los riesgos de seguridad de la aplicación detectados por el examen del código, Dependabot y el examen de secretos. La información general de seguridad muestra el estado de habilitación de las características de seguridad en cada repositorio, así como el número de alertas detectadas.

Además, la información general de la seguridad enumera todas las alertas del examen de secretos en el nivel de la organización. Vistas similares para Dependabot y alertas de examen del código llegarán en versiones futuras. Para obtener más información, consulte Acerca de la información general sobre seguridad.

El gráfico de dependencia ahora está disponible en GitHub AE. El gráfico de dependencia ayuda a comprender el software de código abierto del que depende al analizar los manifiestos de dependencia registrados en los repositorios. Para más información, vea "Acerca del gráfico de dependencias".

Las alertas de Dependabot ahora pueden informarte sobre vulnerabilidades en tus dependencias en GitHub AE. Puedes habilitar las alertas de Dependabot habilitando el gráfico de dependencias, habilitando GitHub Connect y sincronizando las vulnerabilidades de GitHub Advisory Database. Esta función está en versión beta y sujeta a cambios. Para más información, consulta "Acerca de las alertas de Dependabot".

Después de habilitar las alertas de Dependabot, los miembros de la organización recibirán notificaciones cada vez que se agregue una nueva vulnerabilidad que afecte a sus dependencias a GitHub Advisory Database o se agregue una dependencia vulnerable a su manifiesto. Los miembros pueden personalizar la configuración de las notificaciones. Para más información, consulta "Configuración de notificaciones para % data variables.product.prodname_dependabot_alerts %}".

Las organizaciones ahora pueden conceder permiso a los equipos para administrar alertas de seguridad y configuraciones en todos sus repositorios. El rol de "administrador de seguridad" se puede aplicar a cualquier equipo y concede a los miembros del equipo los siguientes permisos.

• Acceso de lectura a todos los repositorios de la organización
• Acceso de escritura a todas las alertas de seguridad de la organización
• Acceso a la pestaña de seguridad en el nivel de organización
• Acceso de escritura a la configuración de seguridad en el nivel de organización
• Acceso de escritura a la configuración de seguridad en el nivel de repositorio

Para obtener más información, consulte "Administración de los administradores de seguridad en la organización".

Ahora GitHub AE admite ejecutores autohospedados efímeros (de trabajo único) y un nuevo webhook workflow_job para facilitar el escalado automático de los ejecutores.

Los ejecutores efímeros son adecuados para los entornos autoadministrados en los que cada trabajo debe ejecutarse en una imagen limpia. Después de que se ejecuta un trabajo, GitHub AE cancela automáticamente el registro de los ejecutores efímeros, lo que permite realizar cualquier administración posterior al trabajo.

Puedes combinar ejecutores efímeros con el nuevo webhook workflow_job para escalar automáticamente ejecutores autohospedados en respuesta a solicitudes de trabajo desde Acciones de GitHub.

Para más información, consulta "Escalado automático con ejecutores autohospedados" y "Eventos y cargas de webhook".

Puedes reducir la duplicación en los flujos de trabajo mediante la composición para hacer referencia a otras acciones. Anteriormente, las acciones escritas en YAML solo podían usar scripts. Para más información, consulta "Creación de una acción compuesta".

Para la administración de ejecutores autohospedados en el nivel de empresa ya no es necesario usar tokens de acceso personal con el ámbito admin:enterprise. En su lugar, puedes usar el ámbito new manage_runners:enterprise para restringir los permisos en los tokens. Los tokens con este ámbito pueden autenticarse en muchos puntos de conexión de API REST para administrar los ejecutores autohospedados de la empresa.

Ahora puedes usar la API REST para interactuar mediante programación con el registro de auditoría. Si bien el reenvío del registro de auditoría ofrece la capacidad de retener y analizar datos con tu propio conjunto de herramientas y determinar patrones a lo largo del tiempo, la nueva API REST te ayudará a realizar un análisis limitado de eventos destacados que han ocurrido en la historia reciente. Para más información, vea "Revisión del registro de auditoría de la organización".

Ahora puedes establecer una fecha de expiración en tokens de acceso personal nuevos y existentes. GitHub AE te enviará un correo electrónico cuando sea el momento de renovar un token que esté a punto de caducar. Los tokens que han expirado se pueden regenerar, lo que proporciona un token duplicado con las mismas propiedades que el original. Al usar un token con la API de GitHub AE, verás un nuevo encabezado, GitHub-Authentication-Token-Expiration, que indica la fecha de expiración del token. Puedes usar esto en scripts, por ejemplo, para registrar un mensaje de advertencia a medida que se acerca la fecha de expiración. Para más información, consulta "Creación de un token de acceso personal" e "Introducción a la API REST".

Los propietarios de la organización ahora pueden exportar una lista de las personas con acceso a un repositorio en formato CSV. Para más información, consulta "Visualización de usuarios con acceso al repositorio".

Las nuevas configuraciones para administrar la asignación de la revisión del código ayudan a distribuir la revisión de las solicitudes de incorporación de cambios de un equipo entre los miembros del equipo para que las revisiones no sean responsabilidad de solo uno o dos miembros del equipo.

• Miembros secundarios del equipo: la asignación se limita solo a los miembros directos del equipo. Anteriormente, las solicitudes de revisión del equipo se podían asignar a miembros directos del equipo o miembros de equipos secundarios.
• Contar solicitudes existentes: continuar con la asignación automática aunque uno o más miembros del equipo ya estén solicitados. Anteriormente, un miembro del equipo que ya estaba solicitado se contaba como una de las solicitudes de revisión automática del equipo.
• Solicitud de revisión del equipo: mantener un equipo asignado para la revisión incluso si uno o más miembros se han asignado recientemente.

Para más información, consulta "Administración de la configuración de revisión del código para el equipo".

Hay dos temas nuevos disponibles para la UI web de GitHub AE.

• Un tema oscuro de alto contraste, con mayor contraste entre los elementos de primer plano y de fondo
• Daltónico claro y oscuro, que intercambian colores como el rojo y el verde por el naranja y el azul

Para más información, vea "Administración de la configuración de temas".

Ahora puedes usar la sintaxis de notas al pie en cualquier campo Markdown para hacer referencia a información pertinente sin interrumpir el flujo de su prosa. Las notas al pie se muestran como vínculos en superíndice. Haz clic en una nota al pie para saltar a la referencia, que se muestra en una nueva sección en la parte inferior del documento. Para más información, vea "Sintaxis básica de escritura y formato".

Ahora puedes alternar entre la vista de origen y la vista de Markdown representada a través de la UI web haciendo clic en el botón para "Mostrar la diferencia de origen" en la parte superior de cualquier archivo Markdown. Anteriormente, necesitabas usar la vista del último responsable para vincular a números de línea específicos en el origen de un archivo Markdown.

GitHub AE ahora genera una tabla de contenido automáticamente para los Wikis, con base en los encabezados.

GitHub Actions is a powerful, flexible solution for CI/CD and workflow automation. For more information, see "Entender las GitHub Actions."

Please note that when GitHub Actions is enabled during this upgrade, two organizations named "GitHub Actions" (@actions and @github) will appear in tu empresa. These organizations are required by GitHub Actions. Users named @ghost and @actions appear as the actors for creation of these organizations in the audit log.

GitHub Packages is a package hosting service, natively integrated with GitHub Actions, APIs, and webhooks. Create an end-to-end DevOps workflow that includes your code, continuous integration, and deployment solutions. During this beta, GitHub Packages is offered free of charge to GitHub AE customers.

GitHub Advanced Security is available in beta and includes both code scanning and secret scanning. During this beta, GitHub Advanced Security features are being offered free of charge to GitHub AE customers. Repository and organization administrators can opt-in to use GitHub Advanced Security in the Security and Analysis tab under settings.

Learn more about GitHub Advanced Security code scanning and secret scanning on GitHub AE.

Customers using SCIM (System for Cross-domain Identity Management) can now sync security groups in Azure Active Directory with GitHub teams. Once a team has been linked to a security group, membership will be automatically updated in GitHub AE when a user is added or removed from their assigned security group.

GitHub IP allow lists provide the ability to filter traffic from administrator-specified IP ranges, defined by CIDR notation. The allow list is defined at the enterprise or organization account level in Security > Settings. All traffic that attempts to reach resources within the enterprise account and organizations are filtered by the IP allow lists. This functionality is provided in addition to the ability to request network security group changes that filter traffic to the entirety of the GHAE tenant.

Organization owners can now disable publication of GitHub Pages sites from repositories in the organization. This will not unpublish existing sites.

Repositories that use GitHub Pages can now build and deploy from any branch.

When writing an issue or pull request, the list syntax for bullets, numbers, and tasks will now be autocompleted after you press return or enter.

You can now delete a directory in a repository from the repository page. When navigating to a directory, a new kebab button next to the "Add file" button gives the option to delete the directory.

It's now easier and faster to reference issues or pull requests, with search across multiple words after the "#".

Enterprise owners can now publish a mandatory message. The message is shown to all users and they must acknowledge it. This can be used to display important information, terms of service or policies.

The GitHub App single file path permission can now support up to ten files.

When configuring a GitHub App, the authorization callback URL is a required field. Now we will permit the integrator to specify multiple callback URLs. GitHub AE denies authorization if the callback URL from the request is not listed.

A new API endpoint enables the exchange of a user to server token for a user to server token scoped to specific repositories.

Events are now logged in the audit log on promoting a team member to be a team maintainer and on demoting a team maintainer to be a team member.

The OAuth device authorization flow is now supported. This allows any CLI client or developer tool to authenticate using a secondary system.

A user can no longer delete their account if SCIM provisioning is enabled.

Enterprise and organization owners can now set the default branch name for new repositories. Enterprise owners can also enforce their choice of default branch name across all organizations or allow individual organizations to choose their own.

Existing repositories are unaffected by these settings, and their default branch name will not be changed.

This change is one of many changes GitHub is making to support projects and maintainers that want to rename their default branch. To learn more, see github/renaming.

Users can no longer set a backup email address on their profile. Their email address is set through the IdP only.

You can no longer enable two-factor authentication after configuring authentication through your IdP.

GitHub AE can now connect to Azure Boards.

Version headers were missing from the APIs, and have now been set to "GitHub AE."

Links to documentation have been fixed.

Configuration of audit log forwarding within the enterprise's settings was failing.

Navigating to gists could result in a 500 error.

The Support email or URL was failing to save. It now saves after a period of a few minutes.

Organization level pull request templates were not being applied to all pull requests in the organization.