Skip to main content
Publicamos actualizaciones para la documentación con frecuencia y es posible que aún se esté traduciendo esta página. Para obtener la información más reciente, consulta la documentación en inglés.
GitHub AE es una versión limitada en este momento.

GitHub AE release notes

GitHub AE 3.6

GitHub comenzó a implementar estos cambios en empresas en February 16, 2023.

3.6.0: Features

  • Experiencia de administrador

  • 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".

  • Administración de identidades y acceso

  • 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.

  • Directivas

  • 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".

  • Seguridad avanzada de GitHub

  • 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.

  • 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.

  • 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.

  • 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.

  • Dependabot

  • 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.

  • Seguridad de código

  • 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.

  • Acciones de GitHub

  • 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.

  • 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".

  • Experiencia de la comunidad

  • 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".

  • Las organizaciones

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

  • Repositorios

  • 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".

  • Confirmaciones

  • 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".

  • Solicitudes de incorporación de cambios

  • 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".
  • Versiones

  • 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".

  • Gist

  • 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".

  • Markdown

  • 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.

  • Accesibilidad

  • 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".

3.6.0: Changes

  • 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".

3.6.0: Deprecations

GitHub AE 3.4

GitHub comenzó a implementar estos cambios en empresas en Invalid Date.

3.4.0: Features

  • Administración de identidad y acceso

  • 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".

  • Administración

  • 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".

  • Acciones de GitHub

  • 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.

  • Seguridad avanzada de GitHub

  • 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.

  • Dependabot

  • 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.

  • Seguridad de código

  • 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.

  • 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.
  • Notificaciones

  • 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.

  • Las organizaciones

  • 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".

  • Repositorios

  • 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".

  • Solicitudes de incorporación de cambios

  • 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".

  • Versiones

  • 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".

  • Gists

  • 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".

  • Markdown

  • 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.

  • Experiencia del desarrollador

  • 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".

  • Accesibilidad

  • 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".

  • Aplicaciones de GitHub

  • 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".

  • webhooks

  • 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".

3.4.0: Changes

  • Cuando se invita a los usuarios a un repositorio privado, al ir a la dirección URL del repositorio privado se mostrará un mensaje para unirse al repositorio en lugar de un error 404.

  • Las invitaciones a repositorios privados aparecen en las notificaciones.

  • Cuando un usuario escribe @ en la interfaz de usuario web para mencionar a un usuario, la lista clasifica a los participantes en incidencias, solicitudes de incorporación de cambios y discusiones en una posición más alta para que sea más probable que primero se muestre la persona a la que busca un usuario.

  • Para evitar que el código potencialmente malintencionado se ejecute en un flujo de trabajo con privilegios, se aplican los cambios siguientes a flujos de trabajo de Acciones de GitHub desencadenados por Dependabot.

    • Las ejecuciones de flujo de trabajo desencadenadas para los eventos create, deployment y deployment_status siempre recibirán un token de solo lectura y ningún secreto. - Las ejecuciones de flujo de trabajo desencadenadas para el evento pull_request_target en las solicitudes de incorporación de cambios en las que Dependabot ha creado la referencia base siempre recibirá un token de solo lectura y ningún secreto. - Las ejecuciones de flujo de trabajo en eventos push y pull_request desencadenados por Dependabot respetan el valor permissions especificado en los flujos de trabajo. Los permisos de token predeterminados seguirán siendo de solo lectura.
  • El valor para ocultar los cambios de espacio en blanco en la pestaña Archivos modificados de una solicitud de incorporación de cambios se conserva para cada solicitud de incorporación de cambios.

  • La API "Actualizar una rama de solicitud de incorporación de cambios" para aplicaciones de GitHub ahora exige que el usuario o la aplicación que realiza la llamada tengan acceso de escritura al repositorio principal. Si el autor de la llamada no tiene acceso de escritura, la API devolverá una respuesta 403 Forbidden. Para más información, consulta "Extracciones" en la documentación de la API REST.

GitHub AE 3.3

GitHub comenzó a implementar estos cambios en empresas en Invalid Date.

3.3.0: Features

  • Las características de GitHub Advanced Security están disponibles con carácter general

  • 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».

  • Visualización de todas las alertas de examen del código para una solicitud de incorporación de cambios

  • 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".

  • Información general de la seguridad para las organizaciones

  • 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.

    Captura de pantalla de la información general sobre seguridad

  • Gráfico de dependencias

  • 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".

  • Alertas de Dependabot

  • 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 %}".

  • Rol de administrador de seguridad para organizaciones

  • 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".

  • Ejecutores efímeros y webhooks de escalado automático para Acciones de GitHub

  • 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".

  • Acciones compuestas para Acciones de GitHub

  • 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".

  • Nuevo ámbito de token para la administración de ejecutores autohospedados

  • 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.

  • Registro de auditoría accesible a través de la API REST

  • 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".

  • Fechas de expiración de los tokens de acceso personal

  • 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".

  • Exportación de una lista de personas con acceso a un repositorio

  • 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".

  • Administración mejorada de las asignaciones de revisión del código

  • 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".

  • Nuevos temas

  • 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".

  • Mejoras en Markdown

  • 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.

3.3.0: Changes

  • Rendimiento

  • Las cargas de página y los trabajos ahora son significativamente más rápidos para los repositorios con muchas referencias de Git.

  • Administración

  • Se mejora el proceso de suplantación de usuarios. Ahora, las sesiones de suplantación requieren una justificación para la suplantación, las acciones se registran en un registro de auditoría a medida que las realiza el usuario suplantado y el usuario que se suplanta recibirá una notificación por correo electrónico informándole de que un administrador de empresa lo ha suplantado. Para más información, consulta "Suplantación de un usuario".

  • Acciones de GitHub

  • Para mitigar los ataques internos de tipo "Man in the middle" cuando se usan acciones resueltas mediante GitHub Connect a GitHub.com desde GitHub AE, GitHub AE retira el espacio de nombres de acciones (OWNER/NAME) en uso. Retirar el espacio de nombres evita que se cree ese espacio de nombres en la empresa y garantiza que todos los flujos de trabajo que hacen referencia a la acción lo descargarán desde GitHub.com. Para obtener más información, consulta "Habilitación del acceso automático a las acciones de GitHub.com mediante GitHub Connect".

  • El registro de auditoría ahora incluye eventos adicionales para Acciones de GitHub. GitHub AE ahora registra las entradas del registro de auditoría para los siguientes eventos.

    • Se registra o se quita un ejecutor autohospedado.
    • Se agrega un ejecutor autohospedado a un grupo de ejecutores, o bien se quita de un grupo de ejecutores.
    • Se crea o se quita un grupo de ejecutores.
    • Se crea o se completa una ejecución de flujo de trabajo.
    • Se prepara un trabajo de flujo de trabajo. Es importante destacar que este registro incluye la lista de secretos que se proporcionaron al ejecutor.

    Para obtener más información, consulte Fortalecimiento de seguridad para GitHub Actions.

  • Seguridad avanzada de GitHub

  • Ahora el examen de código asignará alertas identificadas en los flujos de trabajo on:push para que aparezcan en las solicitudes de incorporación de cambios, cuando sea posible. Las alertas que se muestran en la solicitud de incorporación de cambios son aquellas que se identifican comparando el análisis existente del encabezado de la rama con el análisis de la rama de destino con la que se está realizando la combinación. Ten en cuenta que si no se utiliza la confirmación de combinación de la solicitud de incorporación de cambios, las alertas pueden ser menos precisas en comparación con el enfoque que utiliza activadores on:pull_request. Para obtener más información, consulte "Acerca del análisis de código con CodeQL".

    Otros sistemas de CI/CD pueden configurarse exclusivamente para desencadenar una canalización cuando el código se inserta en una rama, o incluso exclusivamente para cada confirmación. Cuando se desencadena una canalización de análisis como esta y los resultados se cargan en la API de SARIF, el examen del código también intentará hacer coincidir los resultados del análisis con una solicitud de incorporación de cambios abierta. Si se encuentra una solicitud de incorporación de cambios abierta, los resultados se publicarán como se describe anteriormente. Para obtener más información, consulte "Carga de un archivo SARIF en GitHub".

  • GitHub AE ahora detecta secretos de proveedores adicionales. Para más información, consulta "Patrones de examen de secretos".

  • Solicitudes de incorporación de cambios

  • La escala de tiempo y la barra lateral Revisores que se encuentran en la página de solicitudes de incorporación de cambios ahora indican si una solicitud de revisión se ha asignado automáticamente a uno o más miembros del equipo porque ese equipo usa la asignación de revisión del código.

    Captura de pantalla del indicador para la asignación automática de la revisión de código

  • Ahora puedes filtrar las búsquedas de solicitudes de incorporación de cambios para incluir solamente las que se te solicita que revises directamente si seleccionas En espera de revisión. Para más información, vea "Búsqueda de incidencias y solicitudes de incorporación de cambios".

  • Si se especifica el nombre exacto de una rama cuando se usa el menú selector de ramas, el resultado ahora aparece en la parte superior de la lista de ramas coincidentes. Anteriormente, las coincidencias exactas de nombres de ramas podían aparecer al final de la lista.

  • Al ver una rama que tiene una solicitud de incorporación de cambios abierta correspondiente, GitHub AE ahora se vincula directamente a la solicitud de incorporación de cambios. Anteriormente, habría un aviso para contribuir mediante la comparación de ramas o para abrir una nueva solicitud de incorporación de cambios.

  • Ahora puedes hacer clic en un botón para copiar todo el contenido sin procesar de un archivo en el Portapapeles. Anteriormente, tenías que abrir el archivo sin procesar, seleccionar todo y luego copiar. Para copiar el contenido de un archivo, tienes que ir al archivo y hacer clic en la barra de herramientas. Ten en cuenta que esta característica actualmente solo está disponible en algunos exploradores.

  • Ahora se muestra una advertencia al visualizar un archivo que contiene texto Unicode bidireccional. El texto Unicode bidireccional puede interpretarse o compilarse de forma diferente a la que aparece en la interfaz de usuario. Por ejemplo, los caracteres Unicode bidireccionales ocultos pueden utilizarse para intercambiar segmentos de texto en un archivo. Para más información sobre cómo reemplazar estos caracteres, consulta el registro de cambios de GitHub.

  • Repositorios

  • GitHub AE ahora incluye compatibilidad mejorada con archivos CITATION.cff. CITATION.cff son archivos de texto sin formato con información de cita legible para máquinas y usuarios. GitHub AE analiza esta información en formatos cómodos, como APA y BibTeX que otros usuarios pueden copiar. Para más información, consulta "Acerca de los archivos CITATION".

  • Ahora puedes agregar, eliminar o ver vínculos automáticos a través del punto de conexión de vínculos automáticos de la API de repositorios. Para más información, consulta "Referencias y direcciones URL autovinculadas" "Repositorios" en la documentación de la API REST.

  • Versiones

  • El componente de selección de etiquetas para las versiones de GitHub ahora es un menú desplegable en lugar de un campo de texto. Para más información, vea "Administración de las versiones en un repositorio".

  • Markdown

  • Al arrastrar y colocar archivos, como imágenes y vídeos, en un editor Markdown, GitHub AE ahora usa la ubicación del puntero del mouse en lugar de la ubicación del cursor al colocar el archivo.

  • API DE REST

  • Las versiones preliminares de la API REST ahora se han graduado y son una parte oficial de la API. Los encabezados en versión preliminar ya no son necesarios para los puntos de conexión de la API REST, pero seguirán funcionando según lo previsto si continúas especificando una versión preliminar escalonada en el encabezado Accept de una solicitud.

GitHub AE 3.2

GitHub comenzó a implementar estos cambios en empresas en June 12, 2021.

3.2.0: Features

  • Administración

  • Los clientes con suscripciones activas o de prueba de GitHub AE ahora pueden aprovisionar recursos de GitHub AE desde Azure Portal. Tu suscripción de Azure debe tener una marca de característica para acceder a recursos de GitHub AE en el portal. Ponte en contacto con el administrador de tu cuenta o Equipo de ventas de GitHub para validar la elegibilidad de tu suscripción de Azure. Para obtener más información, vea «Implementación de GitHub AE».

  • Acciones de GitHub

  • Acciones de GitHub ya está disponible con carácter general para GitHub AE. Acciones de GitHub es una solución potente y flexible para integración continua y entrega continua y automatización del flujo de trabajo. Para obtener más información, vea «Entender las GitHub Actions».

  • Los ejecutores autohospedados son el tipo predeterminado del sistema de ejecución en GitHub AE, y ahora están generalmente disponibles para Acciones de GitHub. Con los ejecutores autohospedados, puedes administrar tus propios equipos o contenedores para la ejecución de trabajos de Acciones de GitHub. Para más información, consulta "Acerca de los ejecutores autohospedados" y "Agrega ejecutores auto-hospedados".

  • Los entornos, las reglas de protección de entornos y los secretos de entornos ahora están disponibles con carácter general para Acciones de GitHub en GitHub AE. Para obtener más información, vea «Utilizar ambientes para el despliegue».

  • Acciones de GitHub ahora puede generar un gráfico visual del flujo de trabajo en cada ejecución. Con la visualización del flujo de trabajo, puedes conseguir lo siguiente.

    • Ver y comprender flujos de trabajo complejos.
    • Realizar el seguimiento del progreso de los flujos de trabajo en tiempo real.
    • Solucionar problemas de ejecuciones rápidamente accediendo de manera fácil a los metadatos de registros y trabajos.
    • Supervisar el progreso de los trabajos de implementación y acceder fácilmente a los objetivos de implementación.

    Para más información, vea "Uso del gráfico de visualizaciones".

  • Acciones de GitHub ahora te permite controlar los permisos concedidos al secreto GITHUB_TOKEN. GITHUB_TOKEN es un secreto generado automáticamente que te permite realizar llamadas autenticadas a la API de GitHub AE en las ejecuciones de flujos de trabajo. Acciones de GitHub genera un token nuevo para cada trabajo y el token caduca cuando finaliza el trabajo. El token tiene permisos write para varios puntos de conexión de API, excepto en el caso de solicitudes de incorporación de cambios de bifurcaciones, que siempre son read. Estos nuevos valores te permiten seguir un principio de privilegios mínimos en los flujos de trabajo. Para obtener más información, vea "Autenticación en un flujo de trabajo".

  • Ahora en Acciones de GitHub se admite la omisión de los flujos de trabajo push y pull_request mediante la búsqueda de ciertas palabras clave comunes en el mensaje de confirmación.

  • La CLI de GitHub 1.9 y posteriores te permite trabajan con Acciones de GitHub desde tu terminal. Para obtener más información, consulta the GitHub Blog.

  • Análisis de código

  • El análisis de código ahora está en versión beta para GitHub AE. Para más información, vea "Acerca del análisis de código".

  • Análisis de secretos

  • Ahora puedes especificar tus propios patrones para el análisis de secretos con la versión beta de los patrones personalizados en GitHub AE. Puedes especificar patrones para repositorios, organizaciones y toda tu empresa. Al especificar un patrón nuevo, el análisis de secretos busca en el historial completo de un repositorio de Git, y también en las confirmaciones nuevas. Para más información, vea "Definición de patrones personalizados para el análisis de secretos".

  • GitHub Connect

  • GitHub Connect ahora está en versión beta para GitHub AE. GitHub Connect trae la potencia de la mayor comunidad de código abierto del mundo a tu empresa. Puedes permitir que los usuarios vean los resultados de búsqueda de GitHub.com en GitHub AE, mostrar recuentos de contribución de GitHub AE en GitHub.com y utilizar Acciones de GitHub desde GitHub.com. Para más información, consulta "Administración de conexiones entre las cuentas de empresa".

  • GitHub Packages

  • Ahora puedes eliminar cualquier paquete o versión de un paquete de GitHub Packages desde la IU de la web de GitHub AE. También puedes deshacer la eliminación de un paquete o versión de paquete en un plazo de 30 días. Para más información, consulta "Eliminación y restauración de un paquete".

  • El registro npm para GitHub Packages y GitHub.com ya no devuelve un valor de tiempo en las respuestas de metadatos, lo que proporciona mejoras de rendimiento considerables. GitHub seguirá devolviendo el valor de tiempo en el futuro.

  • Registro de auditoría

  • Los eventos para las solicitudes de incorporación de cambios y las revisiones de solicitudes de incorporación de cambios ahora se incluyen en el registro de auditoría para empresas y organizaciones. Estos eventos ayudan a los administradores a supervisar mejor la actividad de las solicitudes de incorporación de cambios y a garantizar que se satisfagan los requisitos de seguridad y cumplimiento. Los eventos se pueden ver desde la interfaz de usuario web, se pueden exportar en formato CSV o JSON, o bien acceder a ellos mediante la API REST. También puedes buscar eventos de solicitudes de incorporación de cambios concretas en el registro de auditoría.

  • Ahora se incluyen eventos adicionales para Acciones de GitHub en el registro de auditoría para empresas y organizaciones.

    • Se elimina o se vuelve a ejecutar un flujo de trabajo.
    • Se actualiza la versión de un ejecutor autohospedado.
  • Authentication

  • GitHub AE ahora es oficialmente compatible con Okta para el inicio de sesión único (SSO) de SAML y el aprovisionamiento de usuarios con SCIM. También puede asignar grupos en Okta a equipos en GitHub AE. Para más información, consulta "Configuración de la autenticación y el aprovisionamiento para la empresa mediante Okta" y "Asignación de grupos de Okta a equipos".

  • Se ha cambiado el formato de los tokens de autenticación para GitHub AE. El cambio afecta al formato de los tokens de acceso personal y los tokens de acceso para aplicaciones de OAuth, así como los de usuario a servidor, servidor a servidor y actualización para aplicaciones de GitHub. GitHub recomienda actualizar los tokens existentes lo antes posible para mejorar la seguridad y permitir que el examen de secretos los detecte. Para más información, consulta "Acerca de la autenticación en GitHub" y "Acerca del examen de secretos".

  • Ahora puedes autenticar conexiones de SSH a GitHub AE mediante una clave de seguridad FIDO2 con la adición de la clave de SSH sk-ecdsa-sha2-nistp256@openssh.com a tu cuenta. Las claves de seguridad de SSH almacenan material de claves secretas en un dispositivo de hardware independiente que necesita verificación, como un toque, para funcionar. Almacenar la clave en hardware independiente y requerir una interacción física en tu clave de SSH ofrece seguridad adicional. Dado que la clave se almacena en el hardware y no es extraíble, la clave no se puede leer o robar mediante software que se ejecute en un equipo. La interacción física previene el uso no autorizado de la clave, dado que la clave de seguridad no funciona hasta que se interactúa físicamente con ella. Para obtener más información, consulta "Generación de una nueva clave SSH y adición a ssh-agent".

  • Ahora en las versiones 2.0.452 y posteriores de Git Credential Manager (GCM) Core se proporciona compatibilidad con el almacenamiento seguro de credenciales y la autenticación multifactor para GitHub AE. GCM Core con compatibilidad con GitHub AE se incluye en las versiones 2.32 y posteriores de Git para Windows. GCM Core no se incluye con Git para macOS o Linux, pero se puede instalar por separado. Para más información, consulta la última versión y las instrucciones de instalación en el repositorio microsoft/Git-Credential-Manager-Core.

  • Notificaciones

  • Ahora puedes configurar sobre qué eventos quieres que se te notifique en GitHub AE. Desde cualquier repositorio, selecciona el menú desplegable Inspeccionar y, luego, haz clic en Personalizado. Para más información, vea "Configuración de notificaciones".

  • Propuestas y solicitudes de extracción

  • Con la versión más reciente de Octicons, ahora los estados de las incidencias y las solicitudes de incorporación de cambios se distinguen visualmente mejor para que puedas examinar los estados con más facilidad. Para obtener más información, consulta the GitHub Blog.

  • Ahora puedes ver todos los comentarios de revisión de las solicitudes de incorporación de cambios en la pestaña Archivos de una solicitud de incorporación de cambios si seleccionas el menú desplegable Conversaciones. También puedes requerir que todos los comentarios de revisión de las solicitudes de incorporación de cambios se resuelvan antes de que cualquier persona combine la solicitud de incorporación de cambios. Para más información, consulta "Acerca de las revisiones de solicitudes de incorporación de cambios" y "Acerca de las ramas protegidas". Para más información sobre la administración de la configuración de protección de ramas con la API, consulta "Ramas" en la documentación de la API REST y "Mutaciones" en la documentación de GraphQL API.

  • Ahora puedes cargar archivos de vídeo en cualquier parte en la que escribes Markdown en GitHub AE. Puedes compartir demostraciones, mostrar pasos de reproducción y mucho más en los comentarios de incidencias y solicitudes de incorporación de cambios, además de en archivos Markdown dentro de los repositorios, como los archivos LÉAME. Para más información, consulta "Adjuntar archivos".

  • GitHub AE ahora muestra un diálogo de confirmación cuando solicitas una revisión de un equipo con más de 100 miembros, lo cual te permite prevenir las notificaciones innecesarias para los equipos grandes.

  • Cuando una incidencia o solicitud de incorporación de cambios tiene menos de 30 usuarios asignados posibles, el control de usuarios asignados enumerará todos los usuarios potenciales en lugar de un conjunto limitado de sugerencias. Este comportamiento ayuda a la gente en pequeñas organizaciones a encontrar rápidamente al usuario correcto. Para más información sobre cómo asignar usuarios a incidencias y solicitudes de incorporación de cambios, consulta "Asignación de incidencias y solicitudes de incorporación de cambios a otros usuarios de GitHub".

  • Ahora puedes incluir múltiples palabras después del símbolo # en un comentario de una incidencia o solicitud de incorporación de cambios para restringir aún más tu búsqueda. Para descartar las sugerencias, presiona Esc.

  • Para evitar la combinación de cambios inesperados después de habilitar la combinación automática para una solicitud de incorporación de cambios, ahora la combinación automática se deshabilita cuando un usuario inserta nuevos cambios sin acceso de escritura al repositorio. Los usuarios sin acceso de escritura todavía pueden actualizar la solicitud de incorporación de cambios con cambios de la rama base cuando la combinación automática está habilitada. Para evitar que un usuario malintencionado utilice un conflicto de combinación para introducir cambios inesperados en la solicitud de incorporación de cambios, GitHub AE deshabilitará la combinación automática de la solicitud de incorporación de cambios si la actualización provoca un conflicto de combinación. Para más información sobre la combinación automática, consulta "Combinación automática de una solicitud de incorporación de cambios".

  • Ahora los usuarios con permisos de acceso pueden administrar el valor "Permitir combinación automática" en el nivel del repositorio. Este valor, activado de manera predeterminada, controla si la combinación automática está disponible en las solicitudes de incorporación de cambios en el repositorio. Anteriormente, solo los usuarios con acceso de administrador podían administrar este valor. Además, esta configuración ahora se puede controlar mediante las API REST "Crear un repositorio" y "Actualizar un repositorio". Para más información, consulta "Administración de la fusión mediante combinación automática para las solicitudes de incorporación de cambios en el repositorio".

  • La selección de usuarios asignados para incidencias y solicitudes de incorporación de cambios ahora admite la búsqueda de escritura anticipada para que puedas encontrar usuarios en tu organización más rápidamente. Adicionalmente, las clasificaciones de los resultados de la búsqueda se han actualizado para preferir las coincidencias al inicio del nombre de usuario de una persona o nombre de perfil.

  • Repositorios

  • Cuando ves el historial de confirmación de un archivo, ahora puedes hacer clic en para verlo en la hora especificada en el historial del repositorio.

  • Ahora puedes usar la interfaz de usuario web para sincronizar una rama desactualizada de una bifurcación con la rama ascendente de la bifurcación. Si no hay conflictos de combinación entre las ramas, GitHub AE actualiza tu rama mediante el avance rápido o la combinación desde otra ascendente. Si hay conflictos, GitHub AE te solicitará que abras la solicitud de incorporación de cambios para resolver los conflictos. Para obtener más información, vea "Sincronizar una bifurcación".

  • Ahora puedes clasificar los repositorios por recuento de estrellas en un perfil de usuario u organización.

  • El punto de conexión "comparación de dos confirmaciones" de lA API de REST de los repositorios, que devuelve una lista de confirmaciones accesibles desde una confirmación o rama, pero inaccesibles desde otra, ahora admite la paginación. Ahora la API también puede devolver los resultados de las comparaciones entre 250 confirmaciones. Para más información, consulta la documentación de la API REST "Confirmaciones" y "Recorrido con paginación".

  • Al definir un submódulo en tu empresa con una ruta de acceso relativa, ahora se puede hacer clic en el submódulo en la interfaz de usuario web. Al hacer clic en el submódulo en la interfaz de usuario web accederás al repositorio vinculado. Anteriormente, solo se podía hacer clic en submódulos con URL absolutas. Se admiten rutas de acceso relativas para repositorios con el mismo propietario que siguen el patrón ../REPOSITORY, o bien rutas de acceso relativas para los repositorios con un propietario diferente que sigan el patrón ../OWNER/REPOSITORY. Para más información sobre el uso de submódulos, consulta Uso de submódulos en the GitHub Blog.

  • Al precalcular las sumas de comprobación, la cantidad de tiempo en el que un repositorio está bajo llave se reduce drásticamente, lo cual permite que más operaciones de escritura tengan éxito inmediatamente y mejora el desempeño de mono-repositorio.

  • Versiones

  • Ahora puedes reaccionar con emojis a todas las versiones en GitHub AE. Para más información, consulta "Acerca de las versiones".

  • Temas

  • Los temas oscuro y oscuro atenuado ya están disponibles para la interfaz de usuario web. GitHub AE comparará las preferencias del sistema cuando no hayas establecido preferencias de tema en GitHub AE. También puedes personalizar los temas activos durante el día y la noche. Para más información, vea "Administración de la configuración de temas".

  • Markdown

  • Ahora los archivos Markdown en tus repositorios generarán de forma automática una tabla de contenido en el encabezado cuando haya dos o más títulos. La tabla de contenido es interactiva y está vinculada a la sección correspondiente. Se admiten los seis niveles de títulos de Markdown. Para más información, vea "Acerca de los archivos Léame".

  • El marcado code ahora se admite en los títulos de incidencias y solicitudes de incorporación de cambios. El texto dentro de comillas invertidas (`) se mostrará en una fuente de ancho fijo en cualquier parte en donde aparezca la propuesta o solicitud de cambios en la interfaz de usuario web de GitHub AE.

  • Al editar el Markdown en archivos, incidencias, solicitudes de incorporación de cambios o comentarios, ahora puedes usar una función rápida del teclado para insertar un bloque de código. El método abreviado de teclado comando + E en Mac, o bien Ctrl + E en otros dispositivos. Para más información, vea "Sintaxis básica de escritura y formato".

  • Puedes anexar ?plain=1 a la URL de cualquier archivo Markdown para mostrarlo sin representarlo y con números de línea. Puedes utilizar la vita sin formato para enlazar otros usuarios a líneas concretas. Por ejemplo, al anexar ?plain=1#L52 se resaltará la línea 52 de un archivo Markdown de texto sin formato. Para más información, "Creación de un vínculo permanente a un fragmento de código".

  • Aplicaciones de GitHub

  • Las solicitudes de API para crear un token de acceso de instalación ahora respetan las listas de admisión de IP de la empresa u organización. Cualquier solicitud de API realizada con un token de acceso de instalación para una aplicación de GitHub instalada en tu organización ya respeta las listas de admisión de IP. Actualmente, esta característica no tiene en cuenta ninguna regla de grupo de seguridad de red (NSG) de Azure que el Soporte técnico de GitHub haya configurado para tu empresa. Para más información, consulta "Restricción del tráfico de red a la empresa", "Administración de direcciones IP permitidas para la organización" y "Aplicaciones" en la documentación de la API REST.

  • webhooks

  • Ahora puedes reenviar o verificar el estado de los webhooks con programación mediante la API de REST. Para más información, consulta "Repositorios", "Organizaciones" y "Aplicaciones" en la documentación de la API REST.

GitHub AE 3.1

GitHub comenzó a implementar estos cambios en empresas en March 03, 2021.

3.1.0: Features

  • GitHub Actions beta

  • 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 beta

  • 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 beta

  • 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.

  • Manage teams from your identity provider (IdP)

  • 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.

  • IP allow lists beta

  • 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.

3.1.0: Changes

  • Developer Changes

  • 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 "#".

  • Administration changes

  • 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.

  • Default branch renaming

  • 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.

3.1.0: Bug fixes

  • Bug fixes

  • 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.

3.1.0: Known issues

  • Known issues

  • Geographic location data is not shown in the audit log. Location information can otherwise be discerned from the IP address associated with each event.

  • The link to GitHub Packages from a repository page shows an incorrect search page when that repository does not have any packages.