Skip to main content
Frecuentemente publicamos actualizaciones de nuestra documentación. Es posible que la traducción de esta página esté en curso. Para conocer la información más actual, visita la documentación en inglés. Si existe un problema con las traducciones en esta página, por favor infórmanos.

Enterprise Server 3.5 release notes

June 09, 2022

    Security fixes

  • Los paquetes se actualizaron a las últimas versiones de seguridad.

    Bug fixes

  • An internal script to validate hostnames in the GitHub Enterprise Server configuration file would return an error if the hostname string started with a "." (period character).

  • In HA configurations where the primary node's hostname was longer than 60 characters, MySQL would fail to be configured.

  • When GitHub Actions was enabled but TLS was disabled on GitHub Enterprise Server 3.4.1 and later, applying a configuration update would fail.

  • The --gateway argument was added to the ghe-setup-network command, to allow passing the gateway address when configuring network settings using the command line.

  • The GitHub Advanced Security billing API endpoints were not enabled and accessible.

  • Image attachments that were deleted would return a 500 Internal Server Error instead of a 404 Not Found error.

  • In environments configured with a repository cache server, the ghe-repl-status command incorrectly showed gists as being under-replicated.

  • The "Get a commit" and "Compare two commits" endpoints in the Commit API would return a 500 error if a file path in the diff contained an encoded and escaped unicode character.

  • The calculation of "maximum committers across entire instance" reported in the site admin dashboard was incorrect.

  • An incorrect database entry for repository replicas caused database corruption when performing a restore using Utilidades de respaldo del servidor de GitHub Enterprise.

  • A GitHub App would not be able to subscribe to the secret_scanning_alert_location webhook event on an installation.

  • The activity timeline for secret scanning alerts wasn't displayed.

  • Deleted repos were not purged after 90 days.

    Changes

  • Optimised the inclusion of metrics when generating a cluster support bundle.

  • In HA configurations where Elasticsearch reported a valid yellow status, changes introduced in a previous fix would block the ghe-repl-stop command and not allow replication to be stopped. Using ghe-repo-stop --force will now force Elasticsearch to stop when the service is in a normal or valid yellow status.

    Known issues

  • En una instancia recién configurada de GitHub Enterprise Server sin ningún usuario, un atacante podría crear el primer usuario adminsitrador.

  • Las reglas de cortafuegos personalizadas se eliminan durante el proceso de actualización.

  • Los archivos rastreados del LFS de Git que se cargaron mediante la interface web se agregaron incorrecta y directamente al repositorio.

  • Las propuestas no pudieron cerrarse si contenían un permalink a un blob en el mismo repositorio en donde la ruta de archvio del blob era más grande a 255 caracteres.

  • Cuando se habilita "Los usuarios pueden buscar en GitHub.com" con GitHub Connect, las propuestas en los repositorios privados e internos no se incluirán en los resultados de búsqueda de GitHub.com.

  • El registor de npm del Registro del paquete de GitHub ya no regresa un valor de tiempo en las respuestas de metadatos. Esto se hizo para permitir mejoras de rendimiento sustanciales. Seguimos teniendo todos los datos necesarios para devolver un valor de tiempo como parte de la respuesta de metadatos y terminaremos de devolver este valor ene l futuro una vez que hayamos resuelto los problemas de rendimiento existentes.

  • Los límites de recursos que son específicos para procesar ganchos de pre-recepción podrían ocasionar que fallen algunos ganchos de pre-recepción.

  • Actions services need to be restarted after restoring an appliance from a backup taken on a different host.

  • Deleted repositories will not be purged from disk automatically after the 90-day retention period ends. This issue is resolved in the 3.5.1 release. [Updated: 2022-06-10]

  • Management Console may appear stuck on the Starting screen after upgrading an under-provisioned instance to GitHub Enterprise Server 3.5. [Updated: 2022-06-20]

May 31, 2022

📣 Este no es el lanzamiento de parche más reciente de Enterprise Server. Por favor, utiliza el lanzamiento más reciente para las últimas correcciones de seguridad, rendimiento y errores.

For upgrade instructions, see "Upgrading GitHub Enterprise Server."

    Features

    IP exception list for validation testing after maintenance

  • Ahora puedes configurar una lista de direcciones IP permitidas que pueden acceder a los servicios de aplicación de tu instancia de GitHub Enterprise Server mientras que el modo de mantenimiento está habilitado. Los administradores que visitan la interfaz web de la instancia desde una dirección IP permitida pueden validar la funcionalidad de dicha instancia post-mantenimiento y antes de inhabilitar el modo de mantenimiento. Para obtener más información consulta la sección "Habilitar y programar el modo de mantenimiento".

  • Custom repository roles are generally available

  • Con los roles de repositorio personalizados, las organizaciones ahora tienen un control más granular sobre los permisos de acceso a los repositorios que pueden otorgar a los usuarios. Para obtener más información, consulta la sección "[Administrar los roles de repositorio personalizados para una organización] (/organizations/managing-peoples-access-to-your-organization-with-roles/managing-custom-repository-roles-for-an-organization)".

    Un organizador es quien crea el rol de repositorio personalizado y este está disponible en todos los repositorios de dicha organización. Se puede otorgar un nombre y descripción personalizados a cada rol. Este puede configurarse desde un conjunto de 40 permisos específicos. Una vez que se crea, los administradores de repositorio pueden asignar un rol personalizado a cualquier usuario, equipo o colaborador externo.

    Los roles de repositorio personalizados pueden crearse, verse, editarse y borrarse a través de la nueva pestaña de Roles de repositorio en los ajustes de una organización. Se puede crear un máximo de 3 roles personalizados dentro de una organización.

    Los roles de repositorio también son totalmente compatibles en las API de REST de GitHub Enterprise. La API de organizaciones se puede utilizar para listar todos los roles de repositorio personalizados en una organización y las API existentes para otorgar acceso a los repositorios para individuos y equipos tienen soporte extendido para los roles de repositorio personalizados. Para obtener más información, consulta la sección "Organizations" en la documentación de la API de REST.

  • GitHub Container registry in public beta

  • The GitHub Container registry (GHCR) is now available in GitHub Enterprise Server 3.5 as a public beta, offering developers the ability to publish, download, and manage containers. GitHub Packages container support implements the OCI standards for hosting Docker images. For more information, see "GitHub Container registry."

  • Dependabot updates are generally available

  • La versión del Dependabot y las actualizaciones de seguridad ahora están disponibles en general en GitHub Enterprise Sever 3.5. Todas las características y ecosistemas populares que funcionan en los repositorios de GitHub.com ahora pueden configurarse con tu instancia de GitHub Enterprise Server. El Dependabot en GitHub Enterprise Server requiere GitHub Actions y un conjunto de ejecutores auto-hospedados del Dependabot, contar con GitHub Connect habilitado y que un administrador habilite al Dependabot.

    Siguiendo con la versión beta pública del lanzamiento, tendremos compatibilidad para utilizar los ejecutores de GitHub Actions hospedados en una configuración de Kubernetes.

    Para obtener más información, consulta la sección "Configurar las alertas del Dependabot".

  • Server Statistics in public beta

  • Ahora puedes analizar la forma en la que trabaja tu equipo, entender el valor que obtienes de GitHub Enterprise Server y ayudarnos a mejorar nuestros productos si revisas los daos de uso de tu instancia y compartes estos datos agregados con GitHub. Puedes utilizar tus propias herramientas para analizar tu uso a lo largo del tiempo si descargas los datos en un archivo CSV o JSON o si accedes a ellos utilizando la API de REST. Para ver una lista de métricas agregadas que se recolectan, consulta la sección "Acerca de las estadísticas de servidor". Los datos de estadística de servidor no incluyen datos personales ni contenido de GitHub, tal como código, propuestas, comentarios o contenido de solicitudes de cambios. Para entender mejor el cómo almacenamos y aseguramos datos de estadísticas de servidor, consulta la sección "Seguridad de GitHub". Para obtener más información sobre las estadísticas de servidor, consulta la sección "Analizar la forma en la que trabaja tu equipo con las estadísticas de servidor". Esta característica está disponible en beta público.

  • GitHub Actions rate limiting is now configurable

  • Los administradores de sitio ahora pueden habilitar y configurar un limite de tasa para las GitHub Actions. Predeterminadamente, el límite de tasa se inhabilita. Cuando los jobs de los flujos de trabajo no se pueden asignar inmediatamente a un ejecutor disponible, esperarán en cola hasta que un ejecutor esté disponible. Sin embargo, si las GitHub Actions sufren una carga alta sostenida, la cola puede respaldarse más rápido de lo que puede drenarse y el rendimiento de la instancia de GitHub Enterprise Server podría degradarse. Para evitar esto, un administrador puede configurar un límite de tasa. Cuando dicho límite se exceda, las ejecuciones de flujo de trabajo adicionales fallarán de inmediato en vez de ponerse en cola. Una vez que la tasa se haya estabilizado debajo del umbral, las ejecuciones nuevas se pueden poner en cola nuevamente. Para obtener más información, consulta la sección "Configurar los límites de tasa".

  • OpenID Connect (OIDC) for secure deployments with GitHub Actions

  • Las GitHub Actions en GitHub Enterprise Server ahora son compatibles con OIDC para los despliegues seguros a los proveedores de servicios en la nube, lo cual utiliza tokens de vida corta que se rotan automáticamente para cada despliegue. OIDC habilita la siguiente funcionalidad.

    • Autenticación continua entre los proveedores de servicios en la nube y GitHub Enterprise Server sin la necesidad de almacenar ningún secreto de larga duración que se encuentre en la nube en tu instancia.
    • Los administradores de los servicios en la nube pueden confiar en los mecanismos de seguridad de un proveedor de servicios en la nube en particular para garantizar que los flujos de trabajo de GitHub Actions tienen un acceso mínimo a los recursos en la nube. No existe una duplicación de administración de secretos entre GitHub Enterprise Server y la nube.

    Para obtener más información, consulta la sección "Fortalecer la seguridad de tus despliegues".

  • Sharing GitHub Actions within your enterprise is generally available

  • La compatibilidad para las GitHub Actions en los repositorios internos ahora está disponible al público en general para las organizaciones de tu instancia de GitHub Enterprise Server. Puedes hacer innersourcing de automatización si compartes las acciones en los repositorios internos. Puedes administrar los ajustes de un repositorio o utilizar la API de REST para permitir el acceso a los flujos de trabajo en otros repositorios dentro de la organización o en cualquier organización de la instancia. Para obtener más información, consulta las secciones "Compartir las acciones y los flujos de trabajo con tu empresa", "Administrar los ajustes de las GitHub Actions para un repositorio" y "Permisos de las acciones" en la documentación de la API de REST.

  • Cache support for GitHub Actions on GitHub Enterprise Server is now generally available

  • Ahora puedes utilizar el almacenamiento de dependencias en caché para acelerar tus flujos de trabajo de GitHub Actions. Para almacenar las dependencias en caché para un job, puedes incluir la acción actions/cache para crear un caché con una llave única. Puedes compartir cachés en todos los flujos de trabajo del mismo repositorio. Estos flujos de trabajo pueden restablecer el caché y ejecutarse más rápido.

    Los usuarios de las acciones también utilizan nuestras API de caché para:

    -Definir la política empresarial para el rango de tamaño de caché permitido para cada repositorio. -Consultar el uso del caché de cada repositorio y monitorear si el tamaño total de todos los cachés está llegando al límite superior. -Incrementar el tamaño máximo del caché para un repositorio dentro de los límites empresariales permitidos, con base en los requisitos de caché del repositorio. -Monitorear el uso del caché agregado a nivel organizacional o empresarial.

    El almacenamiento externo de blobs que se configura con tu cuenta empresarial ahora se compartirá entre los artefactos de flujo de trabajo, bitácoras y también con los cachés. Para obtener más información, consulta la sección "Almacenar las dependencias en caché para acelerar los flujos de trabajo".

  • Automatically sign commits made in the web UI

  • Ahora puedes configurar GitHub Enterprise Server para que firme automáticamente las confirmaciones que se hacen en la interfaz web, tal como las de editar un archivo o fusionar una solicitud de cambios. Las confirmaciones firmadas aumentan la seguridad de que los cambios vengan de fuentes confiables. Esta característica permite que el ajuste de protección de rama Requerir confirmaciones firmadas bloquee las confirmaciones sin firmar para que no ingresen a un repositorio, mientras que permite la entrada de confirmaciones firmadas; incluso aquellas que se hacen en la interfaz web. Para obtener más información, consulta la sección "Configurar el firmado de las confirmaciones web".

  • Sync license usage any time

  • Para los clientes que sincronizan el uso de licencias entre GitHub Enterprise Server y GitHub Enterprise Cloud automáticamente utilizando GitHub Connect, ahora tienen la capacidad de sincronizar su uso de licencia independientemente de la sincronización semanal automática. Esta característica también reporta el estado del job de sincronización. Para obtener más información, consulta la sección "Sincronizar el uso de licencias entre GitHub Enterprise Server y GitHub Enterprise Cloud".

  • Reusable workflows for GitHub Actions are generally available

  • Los flujos de trabajo reutilizables ahora están disponibles en general. Los flujos de trabajo reutilizables te ayudan a reducir la duplicación permitiéndote reutilizar un flujo de trabajo completo como si fuera una acción. Con el lanzamiento de la disponibilidad general, ahora hay varias mejoras disponibles para GitHub Enterprise Server. Para obtener más información, consulta la sección "Reutilizar los flujos de trabajo".

    • Puedes utilizar las salidas para pasar datos de los flujos de trabajo reutilizables a otros jobs en el flujo de trabajo llamante.
    • Puedes pasar secretos de ambiente a los flujos de trabajo reutilizables.
    • La bitácora de auditoría incluye información sobre qué flujos de trabajo reutilizables se utilizan.
    • Los flujos de trabajo reutilizables en el mismo repositorio que el llamante se pueden referenciar con tan solo la ruta y el nombre de archivo (PATH/FILENAME). El flujo de trabajo llamado será de la misma confirmación que el llamante.
  • Self-hosted runners for GitHub Actions can now disable automatic updates

  • Ahora tienes más control sobre qué ejecutores auto-hospedados realizan actualizaciones de software. Si especificas el marcador --disableupdate para el ejecutor, entonces este no intentará realizar una actualización automática de software si está disponible una versión más nueva del ejecutor. Esto te permite actualizar al ejecutor auto-hospedado en tus propios horarios y conviene especialmente si tu ejecutor auto-hospedado está en un contenedor.

    Para ver la compatibilidad con el servicio de GitHub Actions, necesitarás actualizar a tu ejecutor manualmente en los 30 días posteriores de que una versión nueva del ejecutor se encuentre disponible, Para ver las instrucciones de cómo instalar la versión más actual del ejecutor, consulta las instrucciones de instalación para el lanzamiento más reciente en el repositorio del ejecutor.

  • Secure self-hosted runners for GitHub Actions by limiting workflows

  • Los propietarios de las organizaciones ahora pueden incrementar la seguridad de los flujos de trabajo de IC/DC en los ejecutores auto-hospedados si eligen cuáles de ellos pueden acceder a un grupo de ejecutores. Anteriormente, cualquier flujo de trabajo en un repositorio, tal como un etiquetador de propuestas, podía acceder a los ejecutores auto-hospedados disponibles en una organización. Para obtener más información, consulta la sección "Administrar el acceso a los ejecutores auto-hospedados utilizando grupos y el Blog de GitHub.

  • Prevent GitHub Actions from approving pull requests

  • Ahora puedes controlar si las GitHub Actions pueden aprobar solicitudes de cambio. Esta característica proporciona protección para que un usuario que utiliza GitHub Actions no satisfaga el requisito de protección de rama de "Aprobaciones requeridas" y fusione un cambio que no revisó otro usuario. Para prevenir que se dañen los flujos de trabajo existentes, la opción Permitir que las revisiones de GitHub Actions cuenten en las aprobaciones requeridas está habilitada predeterminadamente. Los propietarios de organización pueden inhabilitar la característica en los ajustes de GitHub Actions de la organización. Para obtener más información, consulta la sección "Inhabilitar o limitar las GitHub Actions para tu organización".

  • Re-run failed or individual GitHub Actions jobs

  • You can now re-run only failed jobs or an individual job in a GitHub Actions workflow run. For more information, see "Re-running workflows and jobs."

  • Dependency graph supports GitHub Actions

  • The dependency graph now detects YAML files for GitHub Actions workflows. GitHub Enterprise Server will display the workflow files within the Insights tab's dependency graph section. Repositories that publish actions will also be able to see the number of repositories that depend on that action from the "Used By" control on the repository homepage. For more information, see "About the dependency graph."

  • Security overview for enterprises in public beta

  • GitHub Advanced Security customers can now view an overview of security alerts at the enterprise level. The new Security tab at the enterprise level provides a repository-centric view of application security risks, as well as an alert-centric view of all secret scanning alerts. For more information, see "About the security overview."

  • Security view for organizations is generally available

  • The overview of security alerts at the organization level is now generally available. GitHub Advanced Security customers can use the security overview to view a repository-centric view of application security risks, or an alert-centric view of all code scanning, Dependabot, and secret scanning alerts for all repositories in an organization. For more information, see "About the security overview."

  • Code scanning detects more security issues, supports new language versions

  • Code scanning now detects a larger number of CWEs, and CodeQL code scanning fully supports the standard language features in the following language releases.

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

    For more information, see the GitHub Blog.

  • View code scanning alerts across an organization

  • GitHub Advanced Security customers can now view code scanning alerts in an organization's Security tab. This view is available to organization owners and members of teams with the security manager role. For more information, see "About the security overview."

  • Users can now retrieve code scanning alerts for an organization on your GitHub Enterprise Server instance via the REST API. This new API endpoint supplements the existing endpoint for repositories. For more information, see Code Scanning in the REST API documentation.

  • Secret scanning available as a push protection

  • GitHub Enterprise Server can now block any pushes where a token is detected with high confidence. Developers can bypass the block by providing details of why the secret needs to be committed via a web UI. For more information, see "Protecting pushes with secret scanning."

  • Dry runs for custom patterns with secret scanning

  • Los clientes de la GitHub Advanced Security ahora pueden simular patrones personalizados del escaneo de secretos a nivel del repositorio o la organización. Las simulaciones permiten que las personas con acceso administrativo o de propietario revisen y perfeccionen sus patrones antes de publicarlos y generar alertas. Puedes redactar un patrón y luego utilizar Guardar y simular para recuperar los resultados. Los escaneos tardan solo unos segundos habitualmente, pero GitHub Enterprise Server también notificará a los propietarios de las organizaciones o administradores de repositorio por correo electrónico cuando estén listos los resultados de la simulación. Para obtener más información, consulta las secciones "Acerca del escaneo de secretos" y "Definir patrones personalizados para el escaneo de secretos".

  • Secret scanning custom pattern events now in the audit log

  • La bitácora de auditoría ahora incluye los eventos asociados con los patrones personalizados del escaneo de secretos. Estos datos ayudan a que lis clientes de GitHub Advanced Security entiendan las acciones que se toman en los patrones personalizados de su repository, organization o enterprise para las auditorías de seguridad y cumplimiento. Para obtener más información, consulta la sección "Revisar la bitácora de auditoría para tu organización" o "Revisar las bitácoras de auditoría para tu empresa".

  • Configure permissions for secret scanning with custom repository roles

  • You can now configure two new permissions for secret scanning when managing custom repository roles.

    • View secret scanning results
    • Dismiss or reopen secret scanning results

    For more information, see "Managing custom repository roles for an organization."

  • Secret scanning now supports archived repositories

  • GitHub Advanced Security customers can now enable secret scanning for archived repositories via the UI and API. For more information, see "About secret scanning," "About archived repositories," and "Repositories" in the REST API documentation.

  • Secret scanning webhooks for alert locations

  • GitHub Advanced Security customers using secret scanning can now opt to receive a webhook each time a secret is detected in a new location. The secret_scanning_alert_location webhook event includes location details, like the commit SHA, and the associated alert for the detection. A location is created for every new file path containing the detected secret. For more information, see "Webhook events and payloads."

  • View Dependabot alerts across an organization

  • GitHub Advanced Security customers can now view Dependabot alerts in in an organization's Security tab. This view is available to organization owners and members of teams with the security manager role. For more information, see "About the security overview."

  • Configure permissions for Dependabot alerts with custom repository roles

  • You can now configure two new permissions for Dependabot alerts when managing custom repository roles.

    • View Dependabot alerts
    • Dismiss or reopen Dependabot alerts

    For more information, see "Managing custom repository roles for an organization."

  • Reopen dismissed Dependabot alerts

  • You can now reopen dismissed Dependabot alerts through the UI page for a closed alert. This does not affect Dependabot pull requests or the GraphQL API. For more information, see "About Dependabot alerts."

  • Pub support for Dependabot version updates is in public beta

  • Los usuarios de las actualizaciones de versión del Dependabot ahora pueden actualizar proactivamente las dependencias para los proyectos de Flutter o Dart que utilizan el administrador de paquetes Pub.

    Para probar las actualizaciones de versión en tu propio repositorio de Dart o de Flutter, agrega el siguiente archivo de configuración en .github/dependabot.yaml. Nota los marcadores package-ecosystem: "pub" y enable-beta-ecosystems: true.

    version: 2
    enable-beta-ecosystems: true
    updates:
      - package-ecosystem: "pub"
        directory: "/"
        schedule:
          interval: "weekly"
    
  • See pull request associated with a repository's Dependabot alerts via GraphQL API

  • El nuevo objeto de GraphQL DependabotUpdate te permite ver la información sobre lo que le pasa a las actualizaciones de seguridad de tu repositorio. Cuando GitHub Enterprise Server detecta que una dependencia de tu repositorio está vulnerable, el Dependabot intentará abrir la solicitud de cambios para actualizar la dependencia a una versión no vulnerable. Ahora puedes ver la solicitud de cambios que corrige la vulnerabilidad. En algunos casos, el Dependabot no puede abrir una solicitud de cambios. Anteriormente, el mensaje de error que generaba el Dependabot solo se podía ver en la sección de "Alertas del Dependabot" en la pestaña de Seguridad. Ahora, si el Dependabot se encuentra con un error al intentar abrir la solicitud de cambios de una alerta de seguridad, puedes determinar la razón de esto utilizando la API de GraphQL. Para obtener más información, consulta la sección "Objects" en la documentación de la API de GraphQL.

  • Access more information about Dependabot alerts via GraphQL API

  • You can now view fixed alerts from Dependabot with the GraphQL API. You can also access and filter by state, as well as by unique numeric identifier, and you can filter by state on the vulnerability alert object. The following fields now exist for a RepositoryVulnerabilityAlert.

    • number
    • fixed_at
    • fix_reason
    • state

    For more information, see "Objects" in the GraphQL API documentation.

  • Git events in the enterprise audit log

  • Los siguientes eventos relacionados con Git ahora pueden aparecer en la bitácora de auditoría empresarial. Si habilitas la característica y configuras un periodo de retención de bitácora de auditoría, los eventos nuevos estarán disponibles para su búsqueda a través de la IU y la API o para exportar en JSON o en CSV.

    • git.clone
    • git.fetch
    • git.push

    Debido a la gran cantidad de eventos de Git registrados, te recomendamos que monitorees el almacenamiento de archivos de tu instancia y revises tus configuraciones de alertas relacionadas. Para obtener más información, consulta las secciones "Eventos de bitácoras de auditoría para tu empresa" y "Monitorear el almacenamiento".

  • Improvements to CODEOWNERS

  • Este lanzamiento incluye mejoras para los CODEOWNERS.

    • Los errores de sintaxis ahora se extienden cuando se ve un archivo de CODEOWNERS desde la web. anteriormente, cuando una línea en un archivo de CODEOWNERS tenía un error de sintaxis, este se ignoraba o, en algunos casos, ocasionaba que no cargara el archivo completo de CODEOWNERS. Las GitHub Apps y las acciones pueden acceder a la misma lista de errores utilizando API nuevas de REST y de GraphQL. Para obtener más información, consulta la sección de "Repositories" en la documentación de la API de REST u "Objects" en la documentación de la API de GraphQL.
    • Después de que alguien cree una solicitud de cambios nueva o suba cambios nuevos a un borrador de solicitud de cambios, cualquier propietario de código que se requiera para revisión ahora estará listado en la solicitud de cambios debajo de "Revisores". Esta característica te proporciona una vista inicial de quién se solicita para revisión una vez que la solicitud de cambios se marque como lista para revisión. -Los comentarios en los archivos de CODEOWNERS ahora pueden aparecer al final de una línea, no solo en las líneas dedicadas.

    Para obtener más información, consulta la sección "Acerca de los propietarios de código".

  • More ways to keep a pull request's topic branch up to date

  • El botón de Actualizar rama en la página de solicitud de cambios te permite actualizar la rama de esta con los últimos cambios de la rama base. Esto es útil para verificar que tus cambios sean compatibles con la versión actual de la rama base antes de fusionar. Dos mejoras ahora te proporcionan más opciones para mantener tu rama actualizada.

    • Cuando la rama de tema de tu solicitud de cambios está desactualizada con la rama base, ahora tienes la opción de actualizarla si rebasas en la última versión de la rama base. El rebase aplica los cambios de tu rama en la versión más reciente de la rama base, lo cuál da como resultado una rama con un historial linear, ya que no se crea ninguna confirmación de fusión. Para actualizar por rebase, haz clic en el menú desplegable junto al botón de Actualizar rama, luego en Actualizar con rebase y luego en *rebasar rama, Anteriormente, el botón de Actualizar rama** realizaba una fusión tradicional que siempre daba como resultado una confirmación de fusión en la rama de tu solicitud de cambios. Esta opción aún sigue disponible, pero ahora tú tienes la elección. para obtener más información, consulta la sección "Mantener tu solicitud de cambios sincronizada con la rama base".

    • Un nuevo ajuste de repositorio permite que el botón de Actualizar rama siempre esté disponible cuando la rama de tema de una solicitud de cambios no está actualizada con la rama base. Anteriormente, este botón solo estaba disponible cuando el ajuste de protección de rama Siempre sugerir la actualización de las ramas de las solicitudes de cambio estaba habilitado. Las personas con acceso de mantenedor o administrativo pueden administrar el ajuste de Siempre sugerir actualizar las ramas de las solicitudes de cambio de la sección Solicitudes de cambio en los ajustes de repositorio. Para obtener más información, consulta la sección "Administrar las sugerencias para actualizar las ramas de las solicitudes de cambios".

  • Configure custom HTTP headers for GitHub Pages sites

  • You can now configure custom HTTP headers that apply to all GitHub Pages sites served from your GitHub Enterprise Server instance. For more information, see "Configuring GitHub Pages for your enterprise."

  • Ignore commits in blame view

  • It's now possible to ignore revisions in the blame view by creating a .git-blame-ignore-revs file in the root of your repository. For more information, see "Viewing a file."

  • Light high contrast theme is generally available

  • A light high contrast theme, with greater contrast between foreground and background elements, is now generally available. For more information, see "Managing your theme settings."

  • Reglas de protección de etiquetas

  • Repository owners can now configure tag protection rules to protect a repository's tags. Once protected by a tag protection rule, tags matching a specified name pattern can only be created and deleted by users with the Maintain or Admin role in the repository. For more information, see "Configuring tag protection rules."

    Bug fixes

  • It is now possible for GitHub Apps to upload release assets.

    Changes

  • Minimum requirements for root storage and memory increased for GitHub Enterprise Server 2.10 and 3.0, and are now enforced as of 3.5.0.

    • In version 2.10, the minimum requirement for root storage increased from 80 GB to 200 GB. As of 3.5.0, system preflight checks will fail if the root storage is smaller than 80 GB.
    • In version 3.0, the minimum requirement for memory increased to from 16 GB to 32 GB. As of 3.5.0, system preflight checks will fail if the system has less than 28 GB of memory.

    For more information, see the minimum requirements for each supported deployment platform in "Setting up a GitHub Enterprise Server instance." [Updated: 2022-06-20]

  • Para utilizar el flujo de autorización de dispositivos para las OAuth y GitHub Apps, debes habilitar la característica manualmente. Este cambio reduce la probabilidad de que se utilicen las apps en ataques de phishing contra los usuarios de GitHub Enterprise Server al asegurarse de que los integradores están consientes de los riesgos y toman decisiones conscientes para apoyar esta forma de autenticación. Si eres propietario o administras una OAuth App o GitHub App y quieres utilizar el flujo de dispositivos, puedes habilitarlo para tu app a través de la página de ajustes de la misma. Las terminales de la API de flujo de dispositivos responderán con el código de estado 400 a las apps que no hayan habilitado esta característica. Para obtener más información consulta la sección "Autorizar las OAuth Apps".

  • La página de alerta del escaneo de código ahora siempre muestra el estado de la alerta y la información de la rama predeterminada. Hay un panel nuevo de "Ramas afectadas" en la barra lateral, en donde puedes ver el estado de la alerta en otras ramas. Si la alerta no existe en tu rama predeterminada, la página de la alerta mostrará el estado de "In branch" o de "In pull request" para la ubicación en donde se haya visto dicha alerta por última vez. Esta mejora facilita entender el estado de las alertas que se hayan introducido en tu base de código. Para obtener más información, consulta la sección "Acerca de las alertas del escaneo de código".

    La página de lista de alertas no se cambió y se puede filtrar por branch. Puedes utilizar la API de escaneo de código para recuperar una información de rama más detallada para las alertas. Para obtener más información, consulta la sección "Escaneo de Código" en la documentación de la API de REST.

  • El escaneo de 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, este se muestra en la barra lateral de "Ramas afectadas" y en la línea de tiempo de la alerta. Puedes pasar el mouse sobre el icono de origen del análisis si se muestra en la página de alertas. Estas mejoras facilitarán el entendimiento de tus alertas. Particularmente, te ayudarán a entender aquellas que tengan orígenes de análisis múltiples. Esto es especialmente útil para los ajustes con configuraciones de análisis múltiples, tales como los monorepositorios. Para obtener más información, consulta la sección "Acerca de las alertas del escaneo de código".

  • Lists of repositories owned by a user or organization now have an additional filter option, "Templates", making it easier to find template repositories.

  • GitHub Enterprise Server puede mostrar varios formatos de imagen comunes, incluyendo PNG, JPG, GIF, PSD y SVG y proporciona varias formas de comparar las diferencias entre las versiones. Ahora, cuando revises las imágenes que se agregaron o cambiaron en una solicitud de cambios, las vistas previas de ellas se muestran predeterminadamente. Anteriormente, se veía un mensaje indicando que los archivos binarios no se podían mostrar y necesitabas alternar la opción "Mostrar el diff enriquecido". Para obtener más información, consulta la sección "Trabajar con archivos que no sean de código".

  • Los gists nuevos ahora se crean con un nombre de rama predeterminado ya sea de main o del nombre de la rama predeterminada alterna en tus ajustes de usuario. Esto empata con cómo se crean otros repositorios en GitHub Enterprise Server. Para obtener más información, consulta las secciones "Acerca de las ramas" y "Administrar el nombre de rama predeterminada de tus repositorios".

  • Gists now only show the 30 most recent comments when first displayed. You can click Load earlier comments... to view more. This allows gists that have many comments to appear more quickly. For more information, see "Editing and sharing content with gists."

  • Settings pages for users, organizations, repositories, and teams have been redesigned, grouping similar settings pages into sections for improved information architecture and discoverability. For more information, see the GitHub changelog.

  • Focusing or hovering over a label now displays the label description in a tooltip.

  • Creating and removing repository invitations, whether done through the API or web interface, are now subject to rate limits that may be enabled on your GitHub Enterprise Server instance. For more information about rate limits, see "Configuring rate limits."

  • MinIO has announced the removal of the MinIO Gateways starting June 1st, 2022. While MinIO Gateway for NAS continues to be one of the supported storage providers for Github Actions and Github Packages, we recommend moving to MinIO LTS support to avail support and bug fixes from MinIO. For more information about rate limits, see "Scheduled removal of MinIO Gateway for GCS, Azure, HDFS in the minio/minio repository."

    Deprecations

    Change to the format of authentication tokens affects GitHub Connect

  • GitHub Connect ya no funcionará después del 3 de junio para las instancias que ejecuten GitHub Enterprise Server 3.1 o anterior, debido al cambio en el formato de los tokens de autenticación de GitHub. Para seguir utilizando GitHub Connect, mejora a GitHub Enterprise Server 3.2 o posterior. Para obtener más información, consulta el Blog de GitHub. [Actualizado: 2022-06-14]

  • CodeQL runner deprecated in favor of CodeQL CLI

  • El ejecutor de CodeQL es obsoleto para favorecer al CLI de CodeQL. GitHub Enterprise Server 3.4 y posterior ya no incluyen al ejecutor de CodeQL. Esta obsoletización solo afecta a los usuarios que utilizan el escaneo de código de CodeQL en sistemas de IC/DC de terceros. No se afecta a los usuarios de GitHub Actions. GitHub recomienda fuertemente que los clientes se migren al CLI de CodeQL, lo que es un reemplazo completo de características para el ejecutor de CodeQL y tiene muchas características adicionales. Para obtener más información, consulta la sección "Migrarse del ejecutor de CodeQL al CLI de CodeQL".

  • Theme picker for GitHub Pages has been removed

  • El selector de tema de GitHub Pages se eliminó de los ajustes de las páginas. Para obtener más información sobre la configuración de temas para GitHub Pages, consulta la sección "Agregar un tema a tu sitio de GitHub pages utilizando Jekyll".

    Known issues

  • En una instancia recién configurada de GitHub Enterprise Server sin ningún usuario, un atacante podría crear el primer usuario adminsitrador.

  • Las reglas de cortafuegos personalizadas se eliminan durante el proceso de actualización.

  • Los archivos rastreados del LFS de Git que se cargaron mediante la interface web se agregaron incorrecta y directamente al repositorio.

  • Las propuestas no pudieron cerrarse si contenían un permalink a un blob en el mismo repositorio en donde la ruta de archvio del blob era más grande a 255 caracteres.

  • Cuando se habilita "Los usuarios pueden buscar en GitHub.com" con GitHub Connect, las propuestas en los repositorios privados e internos no se incluirán en los resultados de búsqueda de GitHub.com.

  • El registor de npm del Registro del paquete de GitHub ya no regresa un valor de tiempo en las respuestas de metadatos. Esto se hizo para permitir mejoras de rendimiento sustanciales. Seguimos teniendo todos los datos necesarios para devolver un valor de tiempo como parte de la respuesta de metadatos y terminaremos de devolver este valor ene l futuro una vez que hayamos resuelto los problemas de rendimiento existentes.

  • Los límites de recursos que son específicos para procesar ganchos de pre-recepción podrían ocasionar que fallen algunos ganchos de pre-recepción.

  • Actions services need to be restarted after restoring an appliance from a backup taken on a different host.

  • Deleted repositories will not be purged from disk automatically after the 90-day retention period ends. [Updated: 2022-06-08]

  • Management Console may appear stuck on the Starting screen after upgrading an under-provisioned instance to GitHub Enterprise Server 3.5. [Updated: 2022-06-20]