GitHub AE release notes

Les propriétaires d’entreprise peuvent rejoindre les organisations sur GitHub AE en tant que membre ou propriétaire à partir de la page Organisations du compte d’entreprise. Pour plus d’informations, consultez « Gestion de votre rôle dans une organisation appartenant à votre entreprise ».

Les rôles de dépôt personnalisés sont en disponibilité générale. Avec les rôles de dépôt personnalisés, les propriétaires d’organisation disposent désormais d’un contrôle plus précis sur les autorisations d’accès aux dépôts qu’ils peuvent accorder aux utilisateurs. Les rôles de dépôt personnalisés sont aussi totalement pris en charge par l’API REST. Pour plus d’informations, consultez « Gestion des rôles de dépôt personnalisés pour une organisation » et « Organisations » dans la documentation de l’API REST.

Les propriétaires d’entreprise peuvent empêcher les propriétaires d’organisation d’inviter des collaborateurs aux dépôts GitHub AE. Pour plus d’informations, consultez « Application d’une stratégie pour inviter des collaborateurs à des dépôts ».

Les utilisateurs peuvent choisir de recevoir un événement de webhook qui se déclenche lorsqu’une personne active ou désactive une fonctionnalité de sécurité ou d’analyse du code pour une organisation ou un dépôt. Pour plus d’informations, consultez la documentation suivante.

• « Événements et charges utiles de webhook » dans la documentation du webhook
• « Gestion des paramètres de sécurité et d’analyse pour votre organisation »
• « Gestion des fonctionnalités de sécurité et d’analyse de votre dépôt »

Les propriétaires d’entreprise et les utilisateurs peuvent voir les alertes d’analyse des secrets et les contournements de la protection des poussées de l’analyse des secrets dans les journaux d’audit de l’entreprise et de l’organisation, et via l’API REST. Pour plus d’informations, consultez la documentation suivante.

• « Protection des poussées (push) avec l’analyse des secrets »
• « Événements du journal d’audit pour votre entreprise »
• « Examen du journal d’audit de votre organisation »
• « Analyse de secrets » dans la documentation de l’API REST

Les propriétaires d’organisation peuvent à présent configurer deux nouvelles autorisations pour l’analyse des secrets lors de la gestion des rôles de dépôt personnalisés.

• Afficher des résultats d’analyse des secrets
• Ignorer ou rouvrir des résultats d’analyse des secrets

Pour plus d’informations, consultez « Gestion des rôles de dépôt personnalisés pour une organisation ».

Les utilisateurs peuvent procéder à une série test de modèles d’analyse de secrets personnalisés au niveau de l’entreprise, de l’organisation ou du dépôt, en fonction de leur accès. Les exécutions test permettent aux utilisateurs d’évaluer et d’explorer leurs modèles avant de les publier et de générer des alertes. Vous pouvez composer un modèle, puis utiliser Enregistrer et tester pour récupérer les résultats. Les analyses ne prennent généralement que quelques secondes, mais GitHub AE notifie les utilisateurs par e-mail une fois que les résultats des exécutions test sont prêts. Pour plus d’informations, consultez « À propos de l’analyse de secrets » et « Définition de modèles personnalisés pour l’analyse des secrets ».

Les utilisateurs peuvent activer l’analyse des secrets pour les dépôts archivés à l’aide de l’interface utilisateur ou de l’API. Pour plus d’informations, consultez « À propos de l’analyse des secrets », « À propos des dépôts archivés » et « Dépôts » dans la documentation de l’API REST.

L’analyse des secrets empêche la fuite des secrets dans l’éditeur web. Pour plus d’informations, consultez « Protection des poussées avec l’analyse des secrets ».

L’analyse du code détecte à présent un nombre plus élevé de CWE et l’analyse du code CodeQL prend complètement en charge les fonctionnalités de langage standard dans les mises en production du langage suivantes.

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

Pour plus d’informations, consultez le blog API GitHub Packages.

Les propriétaires d’organisation et les responsables de la sécurité peuvent afficher les alertes d’analyse du code sous l’onglet Sécurité d’une organisation. Pour plus d’informations, consultez « À propos de la vue d’ensemble de la sécurité ».

La page d’alerte de l’analyse du code affiche désormais toujours l’état de l’alerte et les informations de la branche par défaut. Il existe un nouveau panneau « Branches affectées » sur la barre latérale qui affiche l’état de l’alerte dans d’autres branches. Si l’alerte n’existe pas dans votre branche par défaut, la page d’alerte affiche l’état comme « Dans la branche » ou « dans le demande de tirage (pull request) » pour définir l’emplacement où l’alerte a été vue pour la dernière fois. Cette amélioration permet de mieux comprendre l’état des alertes introduites dans votre codebase. Pour plus d’informations, consultez « À propos des alertes d’analyse du code ». La page des listes d’alertes n’est pas modifiée et peut être filtrée par branch. Vous pouvez utiliser l’API d’analyse du code pour récupérer plus d’informations détaillées sur la branche en ce qui concerne les alertes. Pour plus d’informations, consultez « Analyse du code » dans la documentation de l’API REST.

L’analyse du code affiche à présent les détails de l’origine d’analyse d’une alerte. Si une alerte a plus d’une origine d’analyse, elle est affichée dans la barre latérale « Branches affectées » et dans la chronologie des alertes. Les utilisateurs peuvent passer la souris sur l’icône d’origine d’analyse dans la barre latérale « Branches affectées » pour voir l’état de l’alerte dans chaque origine d’analyse. Si une alerte n’a qu’une seule origine d’analyse, aucune information sur les origines d’analyse n’est affichée dans la page d’alerte. Ces améliorations permettent de mieux comprendre les alertes. En particulier, elles aident les utilisateurs à comprendre celles qui ont plusieurs origines d’analyse. Ceci est particulièrement utile pour les configurations avec plusieurs configurations d’analyse, tels que les monoréférentiels. Pour plus d’informations, consultez « À propos des alertes d’analyse du code ».

Les utilisateurs peuvent utiliser les paramètres sort et direction dans l’API REST lorsqu’ils récupèrent des alertes d’analyse des secrets, et les trier en fonction des champs created ou updated de l’alerte. Les nouveaux paramètres sont disponibles pour l’ensemble de votre déploiement GitHub AE, ou pour des organisations ou des dépôts individuels. Pour plus d’informations, consultez la documentation suivante.

• « Répertorier les alertes d’analyse des secrets pour une entreprise »
• « Répertorier les alertes d’analyse des secrets pour une organisation »
• « Répertorier les alertes d’analyse des secrets pour un dépôt »
• « Analyse de secrets » dans la documentation de l’API REST

Les utilisateurs peuvent choisir de recevoir un webhook qui se déclenche lorsqu’un secret est détecté dans un nouvel emplacement. L’événement webhook secret_scanning_alert_location inclut des détails de localisation, comme le SHA de commit, et l’alerte associée pour la détection. Un emplacement est créé pour chaque nouveau chemin de fichier contenant le secret détecté. Pour plus d’informations, consultez « Événements et charges utiles de webhook ».

Les utilisateurs peuvent éventuellement ajouter un commentaire lorsqu’ils rejettent une alerte d’analyse de code dans l’interface web ou via l’API REST. Les commentaires de rejet apparaissent dans la chronologie de l’événement. Les utilisateurs peuvent également ajouter ou récupérer un commentaire de rejet via l’API REST. Pour plus d’informations, consultez « Triage des alertes d’analyse du code dans les demandes de tirage (pull request) » et « Analyse du code » dans la documentation de l’API REST.

Les utilisateurs peuvent à présent récupérer des alertes d’analyse de code pour une organisation avec l’API REST. Ce nouveau point de terminaison d’API complète le point de terminaison existant pour les dépôts. Pour plus d’informations, consultez « Analyse du code » dans la documentation de l’API REST.

Le contenu du référentiel github/codeql-go a été déplacé vers le référentiel github/codeql, pour résider aux côtés de bibliothèques similaires pour tous les autres langages de programmation pris en charge par CodeQL. Les requêtes, les bibliothèques et l’extracteur CodeQL open source pour l’analyse des bases de code écrites en langage de programmation Go avec les outils d’analyse de code CodeQL de GitHub se trouvent désormais dans le nouvel emplacement. Pour plus d’informations, notamment des conseils sur la migration de vos workflows existants, consultez github/codeql-go#741.

Les propriétaires d’entreprise peuvent voir une vue d’ensemble des alertes Dependabot dans le déploiement GitHub AE, y compris une vue orientée dépôt des risques de sécurité des applications et une vue orienté alerte de toutes les alertes d’analyse des secrets et de Dependabot. Les vues sont en version bêta et sont susceptibles d’être modifiées. Pour plus d’informations, consultez « Affichage de la vue d’ensemble de la sécurité ».

Les propriétaires d’organisation et les responsables de la sécurité peuvent voir les alertes Dependabot sous l’onglet Sécurité d’une organisation. Pour plus d’informations, consultez « À propos de la vue d’ensemble de la sécurité ».

Les utilisateurs peuvent rouvrir une alerte Dependabot ignorée à l’aide de l’interface utilisateur web. Ceci n’affecte pas les demandes de tirage (pull request) ni les API GraphQL. Pour plus d’informations, consultez « À propos des alertes Dependabot ».

Les utilisateurs peuvent désormais voir les alertes corrigées à partir de Dependabot avec l’API GraphQL. Les utilisateurs peuvent également accéder et filtrer par état, ainsi que par identificateur numérique unique et filtrer par état sur l’objet de l’alerte de vulnérabilité. Les champs suivants existent maintenant pour une RepositoryVulnerabilityAlert.

• number
• fixed_at
• fix_reason
• state

Pour plus d’informations, consultez la documentation « Objets ».

Les propriétaires d’organisation et les responsables de la sécurité peuvent utiliser la vue d’ensemble de la sécurité d’une organisation pour afficher une vue orientée dépôt des risques de sécurité des applications ou une vue orientée alerte de toutes les alertes d’analyse du code, Dependabot et d’analyse des secrets pour tous les dépôts d’une organisation. Pour plus d’informations, consultez « À propos de la vue d’ensemble de la sécurité ».

GitHub Actions peut appliquer des examens de dépendance aux demandes de tirage des utilisateurs en analysant les dépendances, et avertit les utilisateurs des vulnérabilités de sécurité associées. L’action dependency-review-action est soutenue par un nouveau point de terminaison d’API qui différencie les dépendances entre deux révisions. Pour plus d’informations, consultez « À propos de la révision des dépendances ».

Le graphe des dépendances détecte les fichiers YAML des workflows GitHub Actions. GitHub AE affiche les fichiers de workflow dans la section Graphe des dépendances de l’onglet Insights. Les référentiels qui publient des actions seront également en mesure de voir le nombre de référentiels qui dépendent de cette action à partir du contrôle « Utiliser par » sur la page d’accueil de référentiel. Pour plus d’informations, consultez « À propos du graphe de dépendances ».

Le graphe des dépendances détecte les fichiers Cargo.toml et Cargo.lock pour Rust. Ces fichiers seront affichés dans la section Graphe de dépendances de l’onglet Insights. Les utilisateurs recevront des alertes et des mises à jour de Dependabot pour les vulnérabilités associées à leurs dépendances Rust. Les métadonnées des packages, y compris le mappage des packages aux référentiels, seront ajoutées à une date ultérieure. Pour plus d’informations, consultez « À propos du graphe de dépendances ».

Si GitHub Connect est activé pour GitHub AE, les utilisateurs peuvent contribuer à l’amélioration d’un avis de sécurité dans la Base de données GitHub Advisory. Pour contribuer, cliquez sur Suggérer des améliorations pour cette vulnérabilité en consultant les détails d’un avis. Pour plus d'informations, consultez les articles suivants.

• « Gestion de GitHub Connect »
• « Exploration des vulnérabilités de sécurité dans la base de données GitHub Advisory » dans la documentation GitHub Enterprise Cloud
• « À propos des avis de sécurité GitHub pour les dépôts » dans la documentation GitHub Enterprise Cloud
• « Modification des avis de sécurité dans la base de données GitHub Advisory » dans la documentation GitHub Enterprise Cloud

Les personnes qui gèrent les exécuteurs auto-hébergés ont maintenant un plus grand contrôle sur le moment où les exécuteurs effectuent des mises à jour logicielles. Si vous spécifiez l’indicateur --disableupdate à l’exécuteur, celui-ci ne tente pas d’effectuer une mise à jour logicielle automatique si une version plus récente du logiciel de l’exécuteur est disponible. Ceci permet de mettre à jour l’exécuteur auto-hébergé sur la base d’une planification personnalisée, ce qui est particulièrement pratique lorsqu’un exécuteur auto-hébergé est dans un conteneur. Pour la compatibilité avec le service GitHub Actions, le logiciel de l’exécuteur doit être mis à jour dans les 30 jours suivant la disponibilité de la version de l’exécuteur. Pour plus d’informations sur l’installation de la dernière version de l’exécuteur, consultez les instructions d’installation de la dernière version dans actions/runner.

Lors de l’utilisation de GitHub Actions, pour réduire le risque de fusionner une modification qui n’a pas été révisée par une autre personne dans une branche protégée, les propriétaires d’entreprise et les administrateurs de référentiel peuvent empêcher Actions de créer des demandes de tirage. Les propriétaires d’organisation pouvaient auparavant activer cette restriction. Pour plus d'informations, consultez les articles suivants.

• « Application de stratégies pour GitHub Actions dans votre entreprise »
• « Désactivation ou limitation de la fonctionnalité GitHub Actions pour votre organisation »
• « Gestion des paramètres de GitHub Actions pour un dépôt »

Les propriétaires d’organisation peuvent augmenter la sécurité des workflows CI/CD sur des exécuteurs auto-hébergés en choisissant les workflows pouvant avoir accès à un groupe d’exécuteurs. Précédemment, tous les workflows d’un référentiel, comme par exemple un étiqueteur de problèmes, pouvaient avoir accès aux exécuteurs auto-hébergés disponibles pour une organisation. Pour plus d’informations, consultez « Gestion de l’accès aux exécuteurs auto-hébergés à l’aide de groupes » et le blog GitHub.

Les propriétaires d’organisation peuvent décider si oui ou non GitHub Actions peut approuver les demandes de tirage. Cette fonctionnalité empêche un utilisateur utilisant GitHub Actions de répondre aux exigences de protection de branche « Approbations obligatoires » et de fusionner une modification non révisée par un autre utilisateur. Pour éviter l’arrêt de workflows existants, Autoriser les révisions de GitHub Actions à compter pour une approbation requise est activé par défaut. Les propriétaires des organisations peuvent désactiver la fonctionnalité dans les paramètres GitHub Actions de l’organisation. Pour plus d’informations, consultez « Désactivation ou limitation de GitHub Actions pour votre organisation ».

Les utilisateurs peuvent écrire un workflow unique déclenché par workflow_dispatch et workflow_call, et utiliser le contexte inputs pour accéder aux valeurs d’entrée. Auparavant, les entrées workflow_dispatch se trouvaient dans la charge utile de l’événement, ce qui compliquait le travail des auteurs de workflow qui souhaitaient écrire un workflow à la fois réutilisable et déclenché manuellement. Pour les workflows déclenchés par workflow_dispatch, les entrées sont toujours disponibles dans le contexte github.event.inputs afin de maintenir la compatibilité. Pour plus d’informations, consultez « Contextes ».

Les utilisateurs peuvent réexécuter seulement le ou les travaux ayant échoué dans une exécution de workflow GitHub Actions. Pour plus d’informations, consultez « Réexécution de workflows et de travaux ».

Pour résumer le résultat d’un travail, les utilisateurs peuvent générer du Markdown et publier le contenu sous forme de résumé de travail. Par exemple, après avoir exécuté des tests avec GitHub Actions, un résumé peut fournir une vue d’ensemble des tests réussis, échoués ou ignorés, ce qui peut réduire la nécessité d’examiner la sortie complète du journal. Pour plus d’informations, consultez « Commandes de workflow pour GitHub Actions ».

Pour diagnostiquer plus facilement les échecs d’exécution d’un travail lors d’une nouvelle exécution du workflow, les utilisateurs peuvent activer la journalisation de débogage, qui fournit des informations sur l’exécution et l’environnement d’un travail. Pour plus d’informations, consultez « Réexécution des workflows et des travaux » et « Utilisation des journaux d’exécution de workflow ».

Si vous gérez des exécuteurs auto-hébergés pour GitHub Actions, vous pouvez garantir un état cohérent sur l’exécuteur lui-même avant et après l’exécution d’un workflow en définissant des scripts à exécuter. En utilisant des scripts, vous n’avez plus besoin d’exiger que les utilisateurs intègrent manuellement ces étapes dans les workflows. Les scripts pré- et post-travail sont en version bêta et susceptibles d’être modifiés. Pour plus d’informations, consultez « Exécution de scripts avant ou après un travail ».

Les propriétaires d’entreprise peuvent configurer une stratégie pour contrôler si les noms d’utilisateur ou les noms complets des personnes s’affichent dans les dépôts internes. Pour plus d’informations, consultez « Application de stratégies de gestion des dépôts dans votre entreprise ».

Les propriétaires d’organisation peuvent épingler un référentiel au profil d’une organisation directement à partir du référentiel via le nouveau menu déroulant Épingler le référentiel.

Lors de la création d’une duplication, les utilisateurs peuvent personnaliser le nom de la duplication. Pour plus d’informations, consultez « Dupliquer (fork) un dépôt ».

Les utilisateurs peuvent supprimer une branche qui est associée à une demande de tirage ouverte. Pour plus d’informations, consultez « Création et suppression de branches dans votre dépôt ».

CODEOWNERS a reçu les améliorations suivantes.

• Les erreurs de syntaxe sont à présent exposées lors de l’affichage d’un fichier CODEOWNERS à partir de l’interface utilisateur web. Précédemment, lorsqu’une ligne d’un fichier CODEOWNERS avait une erreur de syntaxe, l’erreur pouvait être ignorée ou, dans certains cas, empêcher le chargement du fichier CODEOWNERS entier. GitHub Apps et Actions peuvent accéder à la même liste d’erreurs à l’aide des nouvelles API REST et GraphQL. Pour plus d’informations, consultez « Dépôts » dans la documentation de l’API REST, ou « Objets » dans la documentation de l’API GraphQL.
• Après la création d’une nouvelle demande de tirage ou la poussée de nouvelles modifications vers une demande de tirage brouillon, tous les propriétaires de code invités à une révision sont à présent listés dans la demande de tirage sous « Réviseurs ». Cette fonctionnalité vous offre une vue anticipée de la personne invitée à réviser, une fois la demande de tirage (pull request) marquée comme prête pour la révision.
• Les commentaires dans les fichiers CODEOWNERS s’affichent à présent à la fin de la ligne, et pas seulement sur des lignes dédiées.

Pour plus d’informations, consultez « À propos des propriétaires de code ».

Lorsqu’un utilisateur renomme ou déplace un fichier dans un nouveau répertoire, si au moins la moitié du contenu du fichier est identique, l’historique des validations indique que le fichier a été renommé, de façon similaire à git log --follow. Pour plus d’informations, consultez le blog API GitHub Packages.

Les utilisateurs peuvent exiger un déploiement réussi d’une branche avant que quiconque puisse fusionner la demande de tirage associée à la branche. Pour plus d’informations, consultez « À propos des branches protégées » et « Gestion d’une règle de protection de branche ».

Les administrateurs de dépôt peuvent désormais configurer des règles de protection des étiquettes pour protéger les étiquettes d’un dépôt. Une fois protégées par une règle de protection des étiquettes, les étiquettes correspondant à un modèle de nom spécifié peuvent être créées et supprimées uniquement par des utilisateurs avec un accès maintenance ou admin au dépôt. Pour plus d’informations, consultez « Configuration des règles de protection des étiquettes ».

Les utilisateurs peuvent ignorer les révisions dans la vue des responsabilités en créant un fichier .git-blame-ignore-revs à la racine d’un dépôt. Pour plus d’informations, consultez « Afficher un fichier ».

Les utilisateurs peuvent accorder des exceptions à GitHub Apps pour toute règle de protection des branches qui prend en charge les exceptions. Pour plus d’informations, consultez « À propos des applications » et « Gestion d’une règle de protection de branche ».

Pour les clés de signature GPG publiques qui sont expirées ou révoquées, GitHub AE vérifie les signatures de commit Git et affiche les commits comme vérifiés si l’utilisateur a effectué le commit alors que la clé était encore valide. Les utilisateurs peuvent également charger des clés GPG expirées ou révoquées. Pour plus d’informations, consultez « À propos de la vérification des signatures de commit ».

Afin d’affirmer qu’une validation est conforme aux règles et aux licences régissant un référentiel, les propriétaires d’organisation et les administrateurs de référentiel peuvent désormais demander aux développeurs de signer les validations effectués via l’interface web. Pour plus d’informations, consultez « Gestion de la stratégie de validation de commits pour votre organisation » et « Gestion de la stratégie de validation de commits pour votre dépôt ».

En utilisant l’arborescence des fichiers située dans l’onglet Fichiers modifiés d’une demande de tirage, les utilisateurs peuvent naviguer dans les fichiers modifiés, comprendre la taille et la portée des changements, et cibler les révisions. L’arborescence des fichiers apparaît si une demande de tirage modifie au moins deux fichiers, et si la fenêtre du navigateur est suffisamment large. Pour plus d’informations, consultez « Révision des changements proposés dans une demande de tirage » et « Filtrage des fichiers dans une demande de tirage ».

Les utilisateurs peuvent utiliser par défaut les titres des demandes de tirage comme message de validation pour toutes les fusions Squash. Pour plus d’informations, consultez « Configuration du squashing de commit pour les demandes de tirage ».

Le bouton Mettre à jour une branche de la page de demande de tirage permet aux utilisateurs de mettre à jour la branche d’une demande de tirage avec les dernières modifications de la branche de base. C’est utile pour vérifier que les modifications de la demande de tirage sont compatibles avec la version actuelle de la branche de base avant la fusion. Deux améliorations offrent d’autres moyens de garder une branche à jour.

• Lorsque la branche de rubrique d’une demande de tirage est obsolète par rapport à la branche de base, les utilisateurs peuvent mettre à jour la branche en rebasant sur la dernière version de la branche de base. Le rebasage applique les modifications de la branche de rubrique à la dernière version de la branche de base, ce qui aboutit à une branche avec un historique linéaire car aucun commit de fusion n’est créé. Pour mettre à jour en utilisant le rebasage, cliquez sur le menu déroulant à côté du bouton Mettre à jour la branche, cliquez sur Mettre à jour avec rebasage, puis sur Rebaser la branche. Avant, Mettre à jour la branche effectuait une fusion traditionnelle qui aboutissait toujours à un commit de fusion dans votre branche de demande de tirage. Cette option est encore disponible, mais les utilisateurs ont désormais le choix. Pour plus d’informations, consultez « Maintien de la synchronisation de votre demande de tirage avec la branche de base ».
• Un nouveau paramètre de dépôt permet d’avoir toujours à disposition le bouton Mettre à jour la branche lorsqu’une branche de rubrique d’une demande de tirage n’est pas à jour avec la branche de base. Avant, ce bouton n’était disponible que lorsque le paramètre de protection de branches Exiger que les branches soient à jour avant la fusion était activé. Les personnes avec un accès administrateur ou mainteneur peuvent gérer le paramètre Toujours suggérer la mise à jour des branches de demandes de tirage à partir de la section Demandes de tirage dans les paramètres du dépôt. Pour plus d’informations, consultez « Gestion des suggestions de mise à jour des branches de demande de tirage ».

En consultant les détails d’une version particulière, les utilisateurs peuvent voir la date de création de chaque ressource de la version. Pour plus d’informations, consultez Affichage des mises en production et étiquettes de votre référentiel. »

Lors de la création d’une version avec des notes de version générées automatiquement, les utilisateurs peuvent voir la balise identifiée comme la version précédente, puis choisir de sélectionner une balise différente à spécifier comme la version précédente. Pour plus d’informations, consultez « Notes de publication générées automatiquement ».

Les Gists n’affichent à présent que les 30 derniers commentaires lors du premier affichage. Les utilisateurs peuvent cliquer sur Charger les commentaires antérieurs... pour en voir plus. Ainsi, les Gists avec plusieurs commentaires peuvent s’afficher plus rapidement. Pour plus d’informations, consultez « Modification et partage de contenu avec des Gists ».

L’édition de Markdown dans l’interface web a été améliorée.

• Lorsqu’un utilisateur sélectionne du texte et colle une URL, le texte sélectionné devient un lien Markdown vers l’URL collée.
• Lorsqu’un utilisateur colle des cellules de tableur ou des tableaux HTML, le texte résultant sera rendu sous forme de tableau.
• Lorsqu’un utilisateur copie un texte contenant des liens, le texte collé inclura le lien sous forme de lien Markdown.

Pour plus d’informations, consultez « Syntaxe de base pour l’écriture et la mise en forme  ».

Lors de l’édition d’un fichier Markdown dans l’interface web, le fait de cliquer sur l’onglet Aperçu fera automatiquement défiler l’écran jusqu’à l’endroit de l’aperçu que vous étiez en train d’éditer. L’emplacement du défilement est basé sur la position du curseur avant de cliquer sur l’onglet Aperçu.

Un thème clair à contraste élevé, avec un contraste plus grand entre les éléments de premier plan et d’arrière-plan, est à présent disponible. Pour plus d’informations, consultez « Gestion de vos paramètres de thème ».

Les listes de référentiels possédées par un utilisateur ou une organisation ont à présent une option de filtre supplémentaire, « Modèles », facilitant la recherche des modèles de référentiels.

GitHub AE peut afficher plusieurs formats d’image courants, notamment PNG, JPG, GIF, PSD et SVG et offre plusieurs moyens de comparer les différences entre les versions. Lorsque vous révisez des images ajoutées ou modifiées dans une demande de tirage, des aperçus de ces images sont maintenant affichés par défaut. Avant, les utilisateurs auraient vu un message indiquant que les fichiers binaires ne pouvaient pas être affichés et ils auraient dû basculer sur l’option « Afficher un diff complet ». Pour plus d’informations, consultez « Travailler avec des fichiers non basés sur du code ».

Les pages de paramètres pour les utilisateurs, organisations, référentiels et équipes ont été re-conçues, regroupant les pages de paramètres similaires en sections pour une meilleure architecture et détectabilité des informations. Pour plus d’informations, consultez le journal des modifications de GitHub.

Les éléments interactifs de l’interface web, comme les liens et les boutons, affichent un contour visible lorsqu’ils sont ciblés par le clavier, afin d’aider les utilisateurs à trouver leur position actuelle sur une page. En outre, lorsqu’ils sont mis en évidence, les champs de formulaire ont un contour plus contrasté.

Le fait d’arrêter ou de passer le curseur sur une étiquette permet d’afficher une info-bulle avec la description de l’étiquette.

Si un utilisateur actualise la page lors de la création d’un nouveau problème ou d’une nouvelle demande de tirage, les personnes désignées, les réviseurs, les étiquettes et les projets seront tous conservés.

Pour utiliser le flux d’autorisations des appareils pour OAuth et GitHub Apps, les auteurs d’application doivent activer manuellement la fonctionnalité. Ce changement réduit la probabilité d’utiliser des applications dans des attaques par hameçonnage contre les utilisateurs GitHub AE en s’assurant que les intégrateurs sont informés des risques et font le choix conscient de prendre en charge ce formulaire d’authentification. Les utilisateurs qui ont ou gèrent une application OAuth ou GitHub et qui souhaitent utiliser le flux d’appareils peuvent l’activer pour une application via la page des paramètres de l’application. Les points de terminaison de l’API du flux d’appareils répond par le code d’état 400 aux applications qui ont activé cette fonctionnalité. Pour plus d’informations, consultez « Autorisation des applications OAuth ».

Les utilisateurs disposant d’un accès administrateur à un dépôt peuvent mieux comprendre qui a accès au dépôt, voir de quel niveau d’accès chaque utilisateur dispose, et gérer plus facilement l’accès au dépôt. Par exemple, les utilisateurs peuvent effectuer les tâches suivantes.

• Rechercher qui a accès au dépôt parmi tous les membres, équipes et collaborateurs.
• Voir quand les membres ont des attributions de rôles mixtes, qui leur sont accordées directement en tant qu’individus ou indirectement par le biais d’une équipe : un nouvel avertissement « rôles mixtes » affiche le rôle de niveau le plus élevé accordé à l’utilisateur si son accès est supérieur au rôle attribué.

Pour plus d’informations, consultez « Gestion des équipes et des personnes ayant accès à votre dépôt ».

Les propriétaires d’entreprise peuvent désormais afficher des liens supplémentaires vers les membres et collaborateurs de l’entreprise dans un pied de page personnalisé. Pour plus d’informations, consultez « Configuration de pieds de page personnalisés ».

Les utilisateurs peuvent réutiliser un workflow avec une seule ligne de configuration. Les workflows réutilisables économisent du temps et de la maintenance en éliminant la nécessité de copier et coller des définitions de workflows entre les dépôts. Les workflows réutilisables sont en version bêta et susceptibles de changer. Pour plus d’informations, consultez « Réutilisation de workflows ».

L’expérience de gestion mise à jour pour les exécuteurs auto-hébergés simplifie la gestion des groupes d’exécuteurs, et fournit une vue d’ensemble améliorée de vos exécuteurs. Pour plus d’informations, consultez « À propos des exécuteurs auto-hébergés » et « Gestion de l’accès aux exécuteurs auto-hébergés en utilisant des groupes ».

Dependabot partage désormais des secrets avec GitHub Actions lorsque Dependabot déclenche une exécution de workflow ; les utilisateurs peuvent ainsi désormais effectuer un tirage à partir de registres de packages privés dans des pipelines CI à l’aide des secrets de Dependabot. Pour plus d’informations, consultez « Gestion des secrets chiffrés pour Dependabot ».

Les utilisateurs peuvent utiliser une condition if pour empêcher l’exécution d’étapes spécifiques d’une action composite si une condition n’est pas remplie. Comme pour les étapes définies dans les workflows, vous pouvez utiliser n’importe quel contexte et n’importe quelle expression pris en charge pour créer un conditionnel. Pour plus d’informations sur les actions composites, consultez « Création d’une action composite ».

Les utilisateurs peuvent offrir une meilleure expérience aux utilisateurs d’un workflow en spécifiant des types d’entrée pour les workflows déclenchés manuellement. Les workflows prennent désormais en charge choice, boolean et environment. Pour plus d’informations, consultez « Syntaxe de workflow pour GitHub Actions ».

Le premier exécuteur correspondant disponible au niveau du dépôt, de l’organisation ou de l’entreprise exécute chaque travail dans tous les cas, ce qui signifie que les travaux sont envoyés aux exécuteurs auto-hébergés beaucoup plus rapidement, en particulier pour les organisations et les entreprises ayant de nombreux exécuteurs auto-hébergés. Avant, lors de l’exécution d’un travail qui nécessitait un exécuteur auto-hébergé, GitHub Actions recherchait des exécuteurs auto-hébergés dans l’ordre suivant : le dépôt, l’organisation, puis l’entreprise. Pour plus d’informations, consultez « Utilisation d’exécuteurs auto-hébergés dans un workflow ».

Les utilisateurs peuvent spécifier qu’une action JavaScript doit s’exécuter dans Node.js 16 en spécifiant runs.using comme node16. La prise en charge de Node.js 16 complète la prise en charge existante de Node.js 12. La version 2.285.0 ou ultérieure de GitHub Actions Runner doit être installée sur les exécuteurs. Pour plus d’informations, consultez « Syntaxe des métadonnées pour GitHub Actions » et le dépôt actions/runner.

Les utilisateurs peuvent ajouter, lister et supprimer des étiquettes pour les exécuteurs auto-hébergés à l’aide de l’API REST. Pour plus d’informations, consultez « Exécuteurs auto-hébergés » dans la documentation de l’API REST.

Les utilisateurs peuvent améliorer la sécurité des services et des outils créés avec Ruby à l’aide de l’analyse du code CodeQL. Pour toutes les versions courantes de Ruby jusqu’à la version 3.02 comprise, CodeQL peut détecter des problèmes courants tels que l’injection SQL, ReDoS, l’injection de commandes et d’arguments du système d’exploitation, l’expansion d’entités XML, le scripting inter-site (XSS) reflété, le XSS stocké, la désérialisation non sécurisée et les informations d’identification codées en dur. Pour activer l’analyse Ruby, les utilisateurs doivent mettre à jour un fichier de workflow d’analyse du code CodeQL existant. La prise en charge de Ruby pour CodeQL est en version bêta et susceptible de changer. Pour plus d’informations, consultez « Configuration de l’analyse du code » et la documentation CodeQL. Pour plus d’informations sur l’analyse du code avec CodeQL, consultez « À propos de l’analyse du code avec CodeQL ».

L’analyse Python de CodeQL prend en charge des frameworks supplémentaires, et peut détecter d’autres sources potentielles de données utilisateur non approuvées, les étapes à travers lesquelles ces données circulent, et les récepteurs potentiellement dangereux dans lesquels ces données peuvent se retrouver. Pour plus d’informations, consultez « Langages et frameworks pris en charge » dans la documentation CodeQL.

Les utilisateurs peuvent récupérer les détails de commit des secrets détectés dans les analyses de dépôt privé à l’aide de l’API REST. Le nouveau point de terminaison expose les détails de la première détection d’un secret au sein d’un fichier, y compris l’emplacement du secret et le SHA de commit. Pour plus d’informations, consultez « À propos de l’analyse des secrets » et « Analyse des secrets » dans la documentation de l’API REST.

L’API d’analyse du code inclut les améliorations suivantes.

• Les alertes incluent l’horodatage fixed_at, qui correspond à la première fois où l’alerte n’a pas été détectée dans une analyse. Les utilisateurs peuvent utiliser ces données pour mieux comprendre quand les alertes d’analyse du code sont corrigées.
• Les utilisateurs peuvent trier les résultats d’alerte les plus importants à l’aide de sort et direction sur created, updated ou number. Pour plus d’informations, consultez Analyse du code dans la documentation de l’API REST.
• Les alertes et la réponse du point de terminaison d’alerte incluent un en-tête Last-Modified. Pour plus d’informations, consultez Last-Modified dans la documentation Mozilla.
• Les réponses SARIF pour les analyses du code incluent relatedLocations, qui peut contenir des emplacements qui ne sont pas l’emplacement principal de l’alerte. Pour obtenir un exemple, consultez la spécification SARIF. Pour plus d’informations, consultez Analyse du code dans la documentation de l’API REST.
• L’objet de règle d’alerte de réponse webhook inclut des données help et tags. Pour plus d’informations, consultez « Événements et charges utiles de webhook ».

Les propriétaires d’organisation et les responsables de la sécurité peuvent récupérer les résultats d’analyse des secrets des dépôts privés au niveau de l’entreprise à l’aide de l’API REST. Pour plus d’informations, consultez « À propos de l’analyse des secrets » et « Analyse des secrets » dans la documentation de l’API REST.

Les utilisateurs peuvent ignorer les alertes Dependabot via l’API GraphQL. Pour plus d’informations, consultez « Mutations » dans la documentation de l’API GraphQL.

Le graphe des dépendances détecte les dépendances Python dans les dépôts qui utilisent le gestionnaire de package Poetry. Les dépendances sont détectées à partir des fichiers manifeste pyproject.toml et poetry.lock. Pour plus d’informations, consultez « À propos du graphe de dépendances ».

Les développeurs et les chercheurs en sécurité peuvent utiliser CodeQL pour créer des bases de données et analyser du code sur des machines équipées de puces Apple Silicon, telles que M1. L’interface CLI CodeQL et l’extension VS Code prennent toutes deux en charge Apple Silicon. Pour utiliser l’interface CLI CodeQL ou l’extension VS Code sur Apple Silicon, les utilisateurs doivent installer les outils de développement en ligne de commande Xcode et Rosetta 2. La prise en charge de CodeQL pour Apple Silicon est en version bêta et susceptible de changer.

• Pour plus d’informations sur la configuration de l’interface CLI CodeQL sur les plateformes prises en charge, consultez « Utilisation de l’interface CLI CodeQL » dans la documentation CodeQL.
• Pour plus d’informations sur CodeQL, consultez « À propos de CodeQL » dans la documentation CodeQL et « À propos de l’analyse du code ».

Les utilisateurs de l’interface CLI CodeQL version 2.7.1 et ultérieures peuvent inclure de l’aide sur les requêtes dans les fichiers SARIF en tant que Markdown, et le texte d’aide s’affichera dans l’interface utilisateur d’analyse du code de GitHub AE. Les utilisateurs peuvent inclure de l’aide sur les requêtes sous la forme d’un fichier Markdown portant le même nom que le fichier de requête correspondant. Par exemple, si votre fichier de requête est MyCustomQuery.ql, le nom du fichier d’aide de requête sera MyCustomQuery.md. Pour plus d’informations sur la création de l’aide aux requêtes pour les requêtes CodeQL personnalisées, consultez le guide de style d’aide aux requêtes.

• Les utilisateurs qui n’utilisent pas GitHub Actions pour CI/CD et l’analyse du code doivent spécifier l’ajout de l’aide aux requêtes lors de l’exécution de la commande codeql database analyze en incluant l’indicateur --sarif-add-query-help. Pour plus d’informations, consultez « Analyse des bases de données avec l’interface CLI CodeQL » dans la documentation CodeQL.

Les utilisateurs peuvent se désabonner de tous les dépôts appartenant à un utilisateur ou à une organisation donné(e). Pour en savoir plus, consultez « Gestion de vos abonnements ».

Les propriétaires d’organisation peuvent se désabonner des notifications par e-mail lorsque de nouvelles clés de déploiement sont ajoutées aux dépôts appartenant à leur organisation. Pour plus d’informations, consultez « Configuration des notifications ».

La ligne d’objet des notifications par e-mail pour les problèmes et les demandes de tirage inclut « (Problème #NUMÉRO) » ou « (PR #NUMÉRO) » pour aider les utilisateurs à faire facilement la distinction entre les deux types de notification.

Le lien Afficher sur GitHub en bas des notifications par e-mail n’est plus masqué par défaut dans Gmail.

Les membres de l’organisation peuvent désormais afficher la liste des propriétaires d’entreprise. Chaque fois qu’un membre de l’organisation reçoit une invite pour contacter un propriétaire d’entreprise, un lien dirige l’utilisateur vers la liste. La liste est également accessible à l’aide de l’objet Organization de l’API GraphQL au niveau du point de terminaison enterpriseOwners. Pour plus d’informations, consultez « Consultation des rôles des personnes dans une organisation ».

Les utilisateurs disposant d’un accès administrateur à un dépôt peuvent renommer les branches protégées par des règles de protection de branche. Pour plus d’informations, consultez « Renommer une branche » et « Gestion d’une règle de protection de branche ».

Au lieu d’autoriser ou d’interdire à tous les utilisateurs de forcer la poussée, les personnes disposant d’un accès administrateur à un dépôt peuvent choisir qui peut forcer la poussée vers le dépôt. Pour plus d’informations, consultez « À propos des branches protégées » et « Gestion d’une règle de protection de branche ».

Les utilisateurs disposant d’un accès administrateur à un dépôt peuvent exiger que toutes les modifications apportées à une branche protégée soient effectuées à l’aide d’une demande de tirage, mais sans nécessiter de révisions. Pour plus d’informations, consultez « À propos des branches protégées » et « Gestion d’une règle de protection de branche ».

Les utilisateurs disposant d’un accès administrateur à un dépôt peuvent autoriser des utilisateurs et des équipes spécifiques à contourner les exigences de demande de tirage. Pour plus d’informations, consultez « Gestion d’une règle de protection de branche ».

Les utilisateurs peuvent utiliser des préfixes à un caractère pour des liens automatiques personnalisés. Les préfixes de lien automatique autorisent aussi l’utilisation des caractères ., -, _, +, =, :, / et #, ainsi que les caractères alphanumériques. Pour plus d’informations, consultez « Configuration des liens automatiques pour référencer des ressources externes ».

Les utilisateurs peuvent activer Notifier uniquement les membres de l’équipe demandés indépendamment de l’option Activer l’attribution automatique dans les paramètres de révision de code de l’équipe, ce qui permet aux utilisateurs d’exiger l’équipe pour révision, mais sans toujours en informer inutilement l’ensemble de l’équipe. Pour plus d’informations, consultez « Gestion des paramètres de révision du code pour votre équipe ».

L’interface utilisateur des mises en production est améliorée, avec une clarification de ce qui est inclus dans une mise en production donnée et une reconnaissance des contributeurs à la mise en production. La pagination est améliorée, et une nouvelle fonctionnalité de recherche est disponible.

Les utilisateurs peuvent générer automatiquement des notes de publication qui incluent un récapitulatif de toutes les demandes de tirage pour une mise en production donnée. Pour plus d’informations, consultez « Notes de publication générées automatiquement ».

Les utilisateurs peuvent afficher un aperçu des rendus des fichiers Markdown dans les gists. Lorsque vous créez ou modifiez un fichier gist avec l’extension de fichier de Markdown, .md, un onglet Prévisualiser ou Prévisualiser les changements affiche un rendu Markdown du contenu du fichier. Pour plus d’informations sur les gists, consultez « Modification et partage de contenu avec des gists ».

Les utilisateurs peuvent choisir d’utiliser une police à largeur fixe dans les champs Markdown, comme les commentaires sur les problèmes et les demandes de tirage. Pour plus d’informations, consultez « À propos de l’écriture et de la mise en forme sur GitHub ».

Les utilisateurs peuvent spécifier le thème pour lequel une image est affichée dans Markdown. Pour plus d’informations, consultez « Syntaxe de base pour l’écriture et la mise en forme  ».

Les utilisateurs peuvent créer rapidement un lien Markdown tout en modifiant du texte dans des champs compatibles avec Markdown, tels que des commentaires de problème ou de demande de tirage, en sélectionnant du texte puis en collant une URL.

Les liens HTML que les utilisateurs collent dans les champs Markdown sont automatiquement convertis en liens Markdown. Pour coller des liens HTML en texte brut, appuyez sur⌘/ctrl + maj + v.

Les langues écrites de droite à gauche sont prises en charge de manière native dans les fichiers et commentaires Markdown dans les problèmes, demandes de tirage et discussions.

Les utilisateurs peuvent définir une taille d’onglet préférée. Tout le code sur GitHub AE avec des onglets s’affichera avec la taille d’onglet préférée. Pour plus d’informations, consultez « Gestion de votre préférence de rendu de taille d’onglet ».

Les utilisateurs peuvent gérer les raccourcis clavier avec les nouveaux paramètres d’accessibilité de GitHub AE, et choisir de désactiver les raccourcis de touches de caractères qui utilisent uniquement des caractères uniques, tels que s, g c et . (la touche de point). Pour plus d’informations, consultez « Gestion des paramètres d’accessibilité ».

Pour garantir que toutes les modifications sont validées par l’application prévue, les utilisateurs peuvent désormais contrôler l’application GitHub par laquelle une vérification d’état requise est fournie. Si une autre application vient à fournir un état, ou un utilisateur via un état de commit, la fusion est empêchée. Les vérifications d’état requises existantes continueront à accepter l’état de n’importe quelle application, mais peuvent être mises à jour de façon à accepter uniquement l’état d’une application spécifique. Les vérifications d’état requises nouvellement ajoutées seront par défaut celles de l’application qui a signalé l’état le plus récemment, mais vous pouvez choisir une autre application ou autoriser n’importe quelle application à fournir l’état. Pour plus d’informations, consultez « À propos des branches protégées » et « Modification d’une règle de protection de branche ».

Les propriétaires d’organisation et les utilisateurs disposant d’un accès administrateur à un dépôt peuvent déclencher des webhooks pour écouter les modifications apportées à des règles de protection de branche. Pour plus d’informations, consultez « Événements et charges utiles de webhook ».

L’analyse du code et l’analyse des secrets sont désormais en disponibilité générale pour GitHub AE. Pour plus d’informations, consultez « À propos de l’analyse du code » et « À propos de l’analyse des secrets ».

Les modèles personnalisés pour l’analyse des secrets est à présent en disponibilité générale. Pour plus d’informations, consultez « Définition de modèles personnalisés pour l’analyse des secrets ».

Vous pouvez à présent rechercher toutes les alertes d’analyse du code associées à une demande de tirage (pull request) avec le nouveau filtre de demande de tirage (pull request) sur la page des alertes d’analyse du code. La page des vérifications de demandes de tirage (pull request) affiche les alertes lancées dans une demande de tirage (pull request) sur une branche de demande de tirage (pull request). Le nouveau lien « Afficher toutes les alertes de branches » sur la page Vérifications vous fait accéder à la page des alertes d’analyse du code avec le filtre de demandes de tirage (pull request) spécifique déjà appliqué, de sorte d’afficher toutes les alertes associées à la demande de tirage (pull request). Ceci peut être utile pour gérer de nombreuses alertes et afficher des informations plus détaillées pour les alertes individuelles. Pour plus d’informations, consultez « Gestion des alertes d’analyse du code pour votre dépôt ».

GitHub Advanced Security offre à présent un affichage au niveau de l’entreprise sur les risques de sécurité de l’application détectés par analyse du code, Dependabot et l’analyse des secrets. La vue d’ensemble de la sécurité présente l’état d’activation des fonctionnalités de sécurité pour chaque référentiel ainsi que le nombre d’alertes détectées.

Par ailleurs, elle répertorie toutes les alertes d’analyse des secrets au niveau de l’organisation. Des affichages relatifs à Dependabot et aux alertes d’analyse du code sont en prévision dans des versions futures. Pour plus d’informations, consultez « À propos de la vue d’ensemble de la sécurité ».

Le graphe des dépendances est désormais disponible sur GitHub AE. Le graphe des dépendances vous aident à comprendre le logiciel en open source duquel vous dépendez en analysant les manifestes de dépendances enregistrés dans des référentiels. Pour plus d’informations, consultez « À propos du graphe de dépendances ».

Les alertes Dependabot peuvent à présent vous informer des vulnérabilités de vos dépendances sur GitHub AE. Pour activer les alertes Dependabot, activez le graphe des dépendances, GitHub Connect et synchronisez les vulnérabilités de la Base de données GitHub Advisory. Cette fonctionnalité est en version bêta et est sujette à modifications. Pour plus d’informations, consultez « À propos des alertes Dependabot ».

Une fois les alertes Dependabot désactivées, les membres de votre organisation reçoivent des notifications à chaque fois qu’une nouvelle vulnérabilité affectant leurs dépendances est ajoutée à la Base de données GitHub Advisory ou qu’une dépendance vulnérable est ajoutée à leur manifeste. Les membres peuvent personnaliser des paramètres de notification. Pour plus d’informations, consultez « Configuration des notifications pour % data variables.product.prodname_dependabot_alerts %} ».

Les organisations peuvent maintenant accorder aux équipes l’autorisation de gérer des alertes et des paramètres de sécurité sur tous leurs référentiels. Le rôle « Gestionnaire de sécurité » peut être appliqué à n’importe quelle équipe et accorde aux membres les autorisations suivantes :

• Accès en lecture sur tous les dépôts de l’organisation
• Accès en écriture sur toutes les alertes de sécurité de l’organisation
• Accès à l’onglet de sécurité au niveau de l’organisation
• Accès en écriture sur les paramètres de sécurité au niveau de l’organisation
• Accès en écriture sur les paramètres de sécurité au niveau du dépôt

Pour plus d’informations, consultez « Gestion des gestionnaires de sécurité dans votre organisation ».

GitHub AE prend désormais en charge les exécuteurs auto-hébergés éphémères (travail unique) et un nouveau webhook workflow_job afin de faciliter la mise à l’échelle automatique des exécuteurs.

Les exécuteurs éphémères conviennent aux environnements autogérés où chaque travail doit s’exécuter sur une image propre. Une fois une tâche exécutée, GitHub AE désenregistre automatiquement des exécuteurs éphémères, vous permettant ainsi d’effectuer toute gestion post-tâche.

Vous pouvez combiner des exécuteurs éphémères avec le nouveau webhook workflow_job pour mettre à l’échelle automatiquement les exécuteurs auto-hébergés en réponse aux demandes de travail de GitHub Actions.

Pour plus d’informations, consultez « Mise à l’échelle automatique avec des exécuteurs auto-hébergés » et « Événements et charges utiles de webhook ».

Vous pouvez réduire la duplication dans vos workflows à l’aide de la composition pour référencer d’autres actions. Les actions écrites en YAML ne pouvaient précédemment utiliser que des scripts. Pour plus d’informations, consultez « Création d’une action composite ».

La gestion des exécuteurs auto-hébergés au niveau de l’entreprise n’a plus besoin de jetons d’accès personnels avec l’étendue admin:enterprise. À la place, vous pouvez utiliser l’étendue new manage_runners:enterprise pour restreindre les autorisations sur vos jetons. Les jetons ayant cette étendue peuvent s’authentifier à plusieurs points de terminaison API REST pour gérer les exécuteurs auto-hébergés de votre entreprise.

Vous pouvez désormais utiliser l’API REST pour l’interface de programmation avec le journal d'audit. Bien que le transfert du journal d’audit vous permette de conserver et d’analyser les données avec votre propre boîte à outils et de déterminer des modèles au fil du temps, la nouvelle API REST peut vous aider à effectuer des analyses limitées sur les récents événements à noter. Pour plus d’informations, consultez « Examen du journal d’audit de votre organisation ».

Vous pouvez à présent définir une date d’expiration pour les jetons d’accès personnels nouveaux et existants. GitHub AE vous envoie un e-mail lorsqu’il est temps de renouveler un jeton sur le point d’expirer. Les jetons qui ont expiré peuvent être regénérés, vous recevez alors un double du jeton qui a les mêmes propriétés que celui d’origine. Lorsque vous utilisez un jeton avec l’API GitHub AE, un nouvel en-tête GitHub-Authentication-Token-Expiration est visible, indiquant la date d’expiration du jeton. Vous pouvez l’utiliser dans des scripts, par exemple pour consigner un message d’avertissement lorsque la date d’expiration approche. Pour plus d’informations, consultez « Création d’un jeton d’accès personnel » et « Bien démarrer avec l’API REST ».

Les propriétaires d’organisation peuvent à présent exporter une liste de personnes ayant accès à un référentiel au format CSV. Pour plus d’informations, consultez « Affichage des personnes ayant accès à votre dépôt ».

De nouveaux paramètres permettant de gérer l’affectation de la révision du code aident à la distribution d’une révision de demande de tirage (pull request) de l’équipe entre les membres de l’équipe, de sorte que les révisions ne soient pas responsable d’un seul ou de deux membres seuls de l’équipe.

• Membres enfants de l’équipe : limiter l’affectation aux seuls membres directs de l’équipe. Précédemment, les requêtes de révision de l’équipe pouvaient être attribuées aux membres directs de l’équipe ou aux membres des équipes enfants.
• Nombre de requêtes existantes : continuer l’attribution automatique même si un ou plusieurs membres de l’équipe ont déjà été invités à la révision. Précédemment, un membre de l’équipe déjà invité à la révision aurait été compté comme une des requêtes de révision automatiques de l’équipe.
• Requête de révision de l’équipe : garder une équipe attribuée à la révision même si un ou plusieurs des membres viennent d’être attribués.

Pour plus d’informations, consultez « Gestion des paramètres de révision du code pour votre équipe ».

Deux nouveaux thèmes sont disponibles pour votre interface utilisateur web GitHub AE.

• Un thème sombre à contraste élevé, avec un contraste supérieur entre les éléments de premier plan et ceux d'arrière-plan
• Daltoniens des couleurs froides et chaudes qui perçoivent le rouge et le vert orange et bleu

Pour plus d’informations, consultez « Gestion de vos paramètres de thème ».

Vous pouvez désormais utiliser la syntaxe des notes de bas de page dans tous les champs Markdown pour référencer des informations importantes sans interrompre le flux de votre prose. Les notes de bas de page sont affichées comme des liens exposants. Cliquez sur une note de bas de page pour accéder à la référence, affichée dans une nouvelle section, en bas du document. Pour plus d’informations, consultez « Syntaxe de base pour l’écriture et la mise en forme  ».

Vous pouvez à présent basculer entre l’affichage source et l’affichage Markdown rendu via l’interface utilisateur web en cliquant sur le bouton pour « Afficher la Diff source » en haut de tous les fichiers Markdown. Auparavant, vous deviez utiliser l’affichage du responsable pour être dirigé vers les numéros de ligne spécifiques dans la source du fichier Markdown.

GitHub AE génère désormais automatiquement une table des matières pour les Wikis, basée sur des titres.

GitHub Actions est une solution à la fois puissante et souple pour le CI/CD et l’automatisation des workflows. Pour plus d’informations, consultez «  ».

Veuillez noter que quand GitHub Actions est activé pendant cette mise à niveau, deux organisations appelées « GitHub Actions » (@actions et @github) apparaissent dans votre entreprise. Ces organisations sont requises par GitHub Actions. Les utilisateurs appelés @ghost et @actions apparaissent comme acteurs dans la création de ces organisations dans le journal d’audit.

GitHub Packages est un service d’hébergement de packages qui est intégré de manière native aux API et aux webhooks GitHub Actions. Créez un workflow DevOps de bout en bout comprenant votre code, l’intégration continue et des solutions de déploiement. Pendant cette version bêta, GitHub Packages est offert gratuitement aux clients GitHub AE.

GitHub Advanced Security est disponible en version bêta et comprend l’analyse du code et l’analyse des secrets. Pendant cette version bêta, les fonctionnalités de GitHub Advanced Security sont offertes gratuitement aux clients GitHub AE. Les administrateurs de dépôt et d’organisation peuvent choisir d’utiliser GitHub Advanced Security sous l’onglet Sécurité et analyse sous les paramètres.

Apprenez-en plus sur l’analyse du code de GitHub Advanced Security et l’analyse des secrets sur GitHub AE.

Les clients utilisant SCIM (System for Cross-domain Identity Management) peuvent maintenant synchroniser des groupes de sécurité dans Azure Active Directory avec des équipes GitHub. Une fois qu’une équipe est associée à un groupe de sécurité, l’appartenance est automatiquement mise à jour dans GitHub AE quand un utilisateur est ajouté ou supprimé de son groupe de sécurité affecté.

Les listes d’autorisation d’adresses IP de GitHub permettent de filtrer le trafic à partir de plages d’adresses IP spécifiées par l’administrateur, définies par la notation CIDR. La liste verte est définie au niveau du compte de l’entreprise ou de l’organisation dans Sécurité > Paramètres. Tout trafic qui tente d’atteindre des ressources dans le compte de l’entreprise et des organisation est filtré avec les listes vertes d’adresses IP. Cette fonctionnalité est fournie en plus de la capacité à demander des changements de groupe de sécurité réseau qui permettent de filtrer le trafic dans l’intégralité du locataire GHAE.

Les propriétaires d’organisation peuvent désormais désactiver la publication de sites GitHub Pages à partir de dépôts de l’organisation. Les sites existants restent publiés.

Les dépôts qui utilisent GitHub Pages peuvent désormais générer et déployer à partir de n’importe quelle branche.

Lorsque vous rédigez un problème ou une demande de tirage, la syntaxe de liste pour les puces, les nombres et les tâches s’autocomplète quand vous appuyez sur return ou enter.

Vous pouvez maintenant supprimer un répertoire d’un dépôt dans la page des dépôts. Lorsque vous accédez à un répertoire, un nouveau bouton kebab (trois puces verticales) à côté du bouton « Ajouter un fichier » donne l’option de supprimer le répertoire.

Il est désormais plus facile et plus rapide de référencer des problèmes ou des demandes de tirage, avec une recherche sur plusieurs mots après le « # ».

Les propriétaires d’entreprise peuvent maintenant publier un message obligatoire. Le message est montré à tous les utilisateurs, qui doivent en accuser réception. Il peut être utilisé pour afficher une information importante, les conditions d’utilisation d’un service ou des politiques.

L’autorisation de chemin de fichier unique GitHub App peut maintenant prendre en charge jusqu’à dix fichiers.

Lors de la configuration d’une GitHub App, l’URL de rappel d’autorisation est un champ obligatoire. À présent, nous allons autoriser l’intégrateur à spécifier plusieurs URL de rappel. GitHub AE refuse l’autorisation si l’URL de rappel de la requête n’est pas listée.

Un nouveau point de terminaison d’API permet l’échange d’un jeton utilisateur à serveur par un jeton utilisateur à serveur limité à des dépôts spécifiques.

Les événements sont maintenant consignés dans le journal d’audit sur la promotion d’un membre d’équipe en chargé de maintenance d’équipe et la rétrogradation d’un chargé de maintenance d’équipe en membre d’équipe.

Le flux d’autorisation de l’appareil OAuth est désormais pris en charge. Cela permet à tout client CLI ou outil de développement de s’authentifier avec un système secondaire.

Les utilisateurs ne peuvent plus supprimer leur compte si le provisionnement SCIM est activé.

Les propriétaires d’entreprise et d’organisation peuvent désormais définir le nom de branche par défaut pour les nouveaux dépôts. Les propriétaires d’entreprise peuvent aussi appliquer leur choix de nom de branche par défaut pour toutes les organisations ou autoriser des organisations individuelles à choisir le leur.

Les dépôts existants ne sont pas affectés par ces paramètres, leur branche par défaut ne sera pas renommée.

Ce changement fait partie des nombreux changements qu’apporte actuellement GitHub pour prendre en charge des projets et des chargés de maintenance qui veulent renommer leur branche par défaut. Pour en savoir plus, consultez github/renaming.

Les utilisateurs ne peuvent plus définir une adresse e-mail de secours sur leur profil. Leur adresse e-mail est définie par le biais du fournisseur d’identité uniquement.

Vous ne pouvez plus activer l’authentification à deux facteurs après avoir configuré l’authentification via votre fournisseur d’identité.

GitHub AE peut désormais se connecter à Azure Boards.

Les en-têtes de version étaient manquants dans les API et sont désormais définis sur « GitHub AE ».

Les liens vers la documentation ont été réparés.

La configuration du transfert du journal d’audit dans les paramètres de l’entreprise échouait.

La navigation vers gists pouvait entraîner une erreur 500.

Il était impossible d’enregistrer l’e-mail ou l’URL du support. Ils s’enregistrent maintenant au bout de quelques minutes.

Les modèles de demande de tirage de niveau organisation n’étaient pas appliqués à toutes les demandes de tirage de l’organisation.