Skip to main content
Nous publions des mises à jour fréquentes de notre documentation, et la traduction de cette page peut encore être en cours. Pour obtenir les informations les plus actuelles, consultez la documentation anglaise.
GitHub AE est actuellement en version limitée.

GitHub AE release notes

GitHub AE 3.6

GitHub a commencé à déployer ces changements pour les entreprises le Invalid Date.

3.6.0: Features

  • Expérience de l’administrateur

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

  • Gestion de l’identité et de l’accès

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

  • Stratégies

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

  • Sécurité avancée GitHub

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

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

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

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

  • Dependabot

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

  • Sécurité du code

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

  • GitHub Actions

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

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

  • Expérience communautaire

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

  • Organisations

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

  • Référentiels

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

  • Commits

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

  • Demandes de tirage

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

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

  • Gist

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

  • Markdown

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

  • Accessibilité

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

3.6.0: Changes

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

3.6.0: Deprecations

GitHub AE 3.4

GitHub a commencé à déployer ces changements pour les entreprises le October 25, 2022.

3.4.0: Features

  • Gestion de la sécurité et des accès

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

  • Administration

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

  • GitHub Actions

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

  • Sécurité avancée GitHub

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

  • Dependabot

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

  • Sécurité du code

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

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

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

  • Organisations

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

  • Référentiels

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

  • Demandes de tirage

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

  • Versions

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

  • Gists

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

  • Markdown

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

  • Expérience développeur

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

  • Accessibilité

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

  • Applications GitHub

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

  • Webhooks

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

3.4.0: Changes

  • Lorsque les utilisateurs sont invités à accéder à un dépôt privé, l’accès à l’URL du dépôt privé entraîne l’affichage d’une invite à rejoindre le dépôt au lieu d’une erreur 404.

  • Les invitations à des dépôts privés apparaissent dans les notifications.

  • Lorsqu’un utilisateur tape @ dans l’interface utilisateur web pour mentionner un utilisateur, la liste classe les participants dans les problèmes, les demandes de tirage et les discussions plus haut afin qu’il soit plus probable que la personne qu’un utilisateur recherche soit listée en premier.

  • Pour empêcher l’exécution de code potentiellement malveillant dans un workflow privilégié, les changements suivants s’appliquent aux workflows GitHub Actions déclenchés par Dependabot.

    • Les exécutions de workflow déclenchées pour les événements create, deployment et deployment_status reçoivent toujours un jeton en lecture seule et aucun secret. - Les exécutions de workflow déclenchées pour l’événement pull_request_target sur les demandes de tirage où la référence de base a été créée par Dependabot reçoivent toujours un jeton en lecture seule et aucun secret. - Les exécutions de workflow sur les événements push et pull_request déclenchés par Dependabot respectent les permissions spécifiées dans vos workflows. Les autorisations de jeton par défaut resteront en lecture seule.
  • Le paramètre permettant de masquer les modifications d’espace blanc sous l’onglet Fichiers modifiés d’une demande de tirage est conservé pour chaque demande de tirage.

  • L’API « Mettre à jour une branche de demande de tirage » pour GitHub Apps nécessite désormais que l’utilisateur ou l’application appelant(e) dispose d’un accès en écriture au dépôt principal. Si l’appelant n’a pas d’accès en écriture, l’API retourne une réponse 403 Forbidden. Pour plus d’informations, consultez « Tirages » dans la documentation de l’API REST.

GitHub AE 3.3

GitHub a commencé à déployer ces changements pour les entreprises le Invalid Date.

3.3.0: Features

  • Les fonctionnalités de GitHub Advanced Security sont en disponibilité générale

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

  • Afficher toutes les alertes d’analyse du code pour une demande de tirage (pull request)

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

  • Vue d’ensemble de la sécurité des organisations

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

    Capture d’écran de la vue d’ensemble de la sécurité

  • Graphe de dépendances

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

  • Alertes Dependabot

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

  • Rôle de Gestionnaire de sécurité pour les organisations

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

  • Exécuteurs éphémères et webhooks en mise à l’échelle automatique pour GitHub Actions

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

  • Actions composites pour GitHub Actions

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

  • Nouvelle étendue de jetons pour la gestion des exécuteurs auto-hébergés

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

  • Journal d'audit accessible via l’API REST

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

  • Dates d’expiration de vos jetons d'accès personnels

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

  • Exporter une liste des personnes ayant accès à un référentiel

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

  • Gestion approuvée des affectations de révision du code

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

  • Nouveaux thèmes

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

  • Améliorations Markdown

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

3.3.0: Changes

  • Performances

  • Les travaux et les charges de page sont maintenant bien plus rapides pour les référentiels qui ont plusieurs références Git.

  • Administration

  • Le processus d’emprunt d’identité de l’utilisateur a été amélioré. Une session d’emprunt d’identité a maintenant besoin d’une justification pour l’emprunt d’identité, les actions sont enregistrées dans le journal d’audit quand elles sont exécutées avec un utilisateur impersonné et l’utilisateur impersonné reçoit un e-mail de notification pour le prévenir que son identité a été empruntée par un propriétaire de l’entreprise. Pour plus d’informations, consultez « Emprunt d’identité d’un utilisateur ».

  • GitHub Actions

  • Pour limiter les attaques de l’intercepteur lors de l’utilisation des actions résolues par le biais de GitHub Connect vers GitHub.com à partir de GitHub AE, GitHub AE met l’espace de noms des actions (OWNER/NAME) utilisé hors service. La mise hors service de l’espace de noms permet d’éviter que l’espace de noms soit créé dans votre entreprise et garantit que tous les workflows faisant référence à l’action le téléchargent à partir de GitHub.com. Pour plus d’informations, consultez « Activer l’accès automatique aux actions GitHub.com à l’aide de GitHub Connect ».

  • Le journal d'audit inclut désormais des événements supplémentaires pour GitHub Actions. GitHub AE enregistre désormais des entrées du journal d’audit pour les événements suivants.

    • Un exécuteur auto-hébergé est inscrit ou supprimé.
    • Un exécuteur autohébergé est ajouté à un groupe d’exécuteurs ou supprimé d’un groupe d’exécuteurs.
    • Un groupe d’exécuteurs est créé ou supprimé.
    • Une exécution de workflow est créée ou effectuée.
    • Un travail de workflow est préparé. Notez que ce journal comprend la liste des secrets fournis à l’exécuteur.

    Pour plus d’informations, consultez « Renforcement de la sécurité pour GitHub Actions ».

  • Sécurité avancée GitHub

  • L’analyse du code mappe désormais les alertes identifiées dans les workflows on:push afin qu’elles s’affichent sur les demandes de tirage, dans la mesure du possible. Les alertes affichées dans la demande de tirage (pull request) sont celles qui sont identifiées en comparant l’analyse existante de la tête de la branche à l’analyse de la branche cible à fusionner. Notez que si le commit de fusion de la demande de tirage n’est pas utilisé, les alertes peuvent être moins précises lors de la comparaison avec l’approche qui utilise des déclencheurs on:pull_request. Pour plus d’informations, consultez « À propos de l’analyse du code avec CodeQL ».

    Certains autres systèmes CI/CD peuvent être configurés exclusivement pour déclencher un pipeline quand le code est envoyé dans une branche ou même exclusivement pour chaque validation. Chaque fois que ce type de pipeline d’analyse est déclenché et que les résultats sont chargés dans l’API SARIF, l’analyse de code essaie également de faire correspondre les résultats d’analyse à une demande de tirage ouverte. Si une demande de tirage ouverte est trouvée, les résultats sont publiés comme décrit plus haut. Pour plus d’informations, consultez « Chargement d’un fichier SARIF sur GitHub ».

  • GitHub AE détecte à présent des secrets de fournisseurs supplémentaires. Pour plus d’informations, consultez « Modèles d’analyse des secrets ».

  • Demandes de tirage

  • La chronologie et la barre latérale des réviseurs dans la page des demandes de tirage indiquent maintenant si une demande de révision a été automatiquement attribuée à un ou plusieurs membres de l’équipe, étant donné que cette équipe utilise l’affectation de la révision du code.

    Capture d’écran de l’indicateur pour l’attribution automatique de révision du code

  • Vous pouvez maintenant filtrer les recherches de demandes de tirage pour obtenir seulement les demandes de tirage que vous avez été directement invité à réviser en choisissant En attente de votre révision. Pour plus d’informations, consultez « Recherche de problèmes et de demandes de tirage ».

  • Si vous spécifiez le nom exact d’une branche quand vous utilisez le menu de sélection de branche, le résultat s’affiche maintenant en haut de la liste des branches correspondantes. Auparavant, les correspondances de nom de branche exactes pouvaient s’afficher en bas de la liste.

  • Quand une branche est associée à une demande de tirage ouverte, GitHub AE renvoie désormais directement à la demande de tirage. Auparavant, vous étiez invité à contribuer en utilisant une comparaison de branches ou à ouvrir une nouvelle demande de tirage.

  • Vous pouvez maintenant cliquer sur un bouton pour copier tout le contenu brut d’un fichier dans le Presse-papiers. Auparavant, vous deviez ouvrir le fichier brut, sélectionner tout le contenu, puis le copier. Pour copier le contenu d’un fichier, accédez au fichier et cliquez sur dans la barre d’outils. Notez que cette fonctionnalité est actuellement disponible seulement dans certains navigateurs.

  • Un avertissement est maintenant affiché quand un fichier contient du texte Unicode bidirectionnel. Le texte Unicode bidirectionnel peut être interprété ou compilé différemment comparé à la façon dont il s’affiche dans une interface utilisateur. Par exemple, les caractères Unicode bidirectionnels masqués peuvent être utilisés pour échanger des segments de texte dans un fichier. Pour plus d’informations sur le remplacement de ces caractères, consultez le Journal des modifications GitHub.

  • Référentiels

  • GitHub AE inclut désormais une prise en charge améliorée des fichiers CITATION.cff. Les fichiers CITATION.cff sont des fichiers de texte brut avec des informations de citation lisibles par l’homme et par machine. GitHub AE analyse ces informations dans des formats pratiques tels que APA et BibTeX qui peuvent être copiés par d’autres personnes. Pour plus d’informations, consultez « À propos des fichiers CITATION ».

  • Vous pouvez désormais ajouter, supprimer ou afficher des liens automatiques via le point de terminaison des liens automatiques de l’API des référentiels. Pour plus d’informations, consultez « Références et URL automatiquement liées » et « Dépôts » dans la documentation de l’API REST.

  • Versions

  • Le composant de sélection des étiquettes pour les mises en production GitHub est à présent un menu déroulant plutôt qu’un champ de texte. Pour plus d’informations, consultez « Gestion des mises en production dans un dépôt ».

  • Markdown

  • Quand vous faites un glisser-déposer de fichiers, comme des images et des vidéos dans un éditeur Markdown, GitHub AE utilise désormais la position du pointeur de la souris au lieu de celle du curseur au moment du placement du fichier.

  • API REST

  • La plupart des préversions de l’API REST ont désormais passé les tests et font officiellement partie de l’API. Les en-têtes de préversion ne sont plus nécessaires dans la plupart des points de terminaison de l’API REST, mais fonctionnent encore comme prévu si vous spécifiez une préversion approuvée dans l’en-tête Accept d’une requête.

GitHub AE 3.2

GitHub a commencé à déployer ces changements pour les entreprises le June 12, 2021.

3.2.0: Features

  • Administration

  • Les clients qui ont des abonnements actifs ou d’essai à GitHub AE peuvent maintenant provisionner des ressources GitHub AE à partir du portail Azure. Votre abonnement Azure doit présenter des indicateurs de fonctionnalité pour accéder aux ressources GitHub AE dans le portail. Contactez votre responsable de compte ou votre L’équipe commerciale GitHub pour valider l’éligibilité de votre abonnement Azure. Pour plus d’informations, consultez « Déploiement de GitHub AE ».

  • GitHub Actions

  • GitHub Actions est maintenant en disponibilité générale pour GitHub AE. GitHub Actions est une solution à la fois puissante et souple pour le CI/CD et l’automatisation des workflows. Pour plus d’informations, consultez «  ».

  • Les exécuteurs auto-hébergés constituent le type par défaut du système d’exécuteurs dans GitHub AE et sont maintenant en disponibilité générale pour GitHub Actions. Avec les exécuteurs auto-hébergés, vous pouvez gérer vos propres machines ou conteneurs pour l’exécution de travaux GitHub Actions. Pour plus d’informations, consultez « À propos des exécuteurs auto-hébergés » et « Ajout d’exécuteurs auto-hébergés ».

  • Les environnements, les règles de protection d’environnement et les secrets d’environnement sont maintenant en disponibilité générale pour GitHub Actions dans GitHub AE. Pour plus d’informations, consultez « Utilisation d’environnements pour le déploiement ».

  • GitHub Actions peut maintenant générer un graphe visuel de votre workflow à chaque exécution. Avec la visualisation du workflow, vous pouvez :

    • Visualiser et comprendre les workflows complexes.
    • Suivre l’avancement des workflows en temps réel.
    • Résoudre rapidement les problèmes en accédant facilement aux journaux et aux métadonnées des travaux.
    • Superviser la progression des travaux de déploiement et accéder facilement aux cibles de déploiement.

    Pour plus d’informations, consultez « Utilisation du graphe de visualisation ».

  • GitHub Actions vous permet désormais de contrôler les autorisations accordées au secret GITHUB_TOKEN. GITHUB_TOKEN est un secret généré automatiquement qui vous permet de passer des appels authentifiés à l’API pour GitHub AE dans vos exécutions de workflow. GitHub Actions génère un nouveau jeton pour chaque travail et fait expirer le jeton une fois le travail terminé. Le jeton dispose d’autorisations write sur un certain nombre de points de terminaison d’API, sauf dans le cas de demandes de tirage provenant de duplications, qui sont toujours read. Ces nouveaux paramètres vous permettent de suivre un principe de privilège minimum dans vos workflows. Pour plus d’informations, consultez « Authentification dans un workflow ».

  • GitHub Actions permet désormais d’ignorer les workflows push et pull_request en recherchant certains mots-clés communs dans votre message de commit.

  • GitHub CLI 1.9 et ultérieur vous permet d’utiliser GitHub Actions dans votre terminal. Pour plus d’informations, consultez the GitHub Blog.

  • Analyse du code

  • L’analyse du code est maintenant en version bêta pour GitHub AE. Pour plus d’informations, consultez « À propos de l’analyse du code ».

  • Analyse de secrets

  • Vous pouvez maintenant spécifier vos propres modèles pour l’analyse des secrets avec la version bêta des modèles personnalisés dans GitHub AE. Vous pouvez spécifier des modèles pour des dépôts, des organisations et votre entreprise toute entière. Quand vous spécifiez un nouveau modèle, l’analyse des secrets recherche le modèle dans l’historique Git complet d’un dépôt, mais aussi dans les nouveaux commits. Pour plus d’informations, consultez « Définition de modèles personnalisés pour l’analyse des secrets ».

  • GitHub Connect

  • GitHub Connect est maintenant disponible en version bêta pour GitHub AE. GitHub Connect apporte la puissance de la plus grande communauté open source au monde dans votre entreprise. Vous pouvez autoriser les utilisateurs à voir les résultats de recherche sur le GitHub.com dans GitHub AE, à afficher le nombre de contributions de GitHub AE sur le GitHub.com et à utiliser GitHub Actions sur le GitHub.com. Pour plus d’informations, consultez « Gestion des connexions entre vos comptes d’entreprise ».

  • GitHub Packages

  • Vous pouvez maintenant supprimer des packages ou versions de package GitHub Packages de l’interface utilisateur web de GitHub AE. Vous pouvez aussi annuler la suppression d’un package ou d’une version de package dans un délai de 30 jours. Pour plus d’informations, consultez « Suppression et restauration d’un package ».

  • Le registre npm pour GitHub Packages et GitHub.com ne retourne plus de valeur de temps dans les réponses de métadonnées, ce qui procure des améliorations substantielles des performances. GitHub continuera à retourner la valeur de temps à l’avenir.

  • Journalisation d’audit

  • Les événements pour les demandes de tirage et les révisions de demande de tirage sont désormais inclus dans le journal d’audit pour les entreprises et les organisations. Ces événements permettent aux administrateurs de mieux superviser l’activité des demandes de tirage et de veiller à ce que les exigences de sécurité et de conformité soient satisfaites. Les événements peuvent être consultés dans l’interface utilisateur web, exportés au format CSV ou JSON et accessibles via l’API REST. Vous pouvez aussi rechercher des événements de demande de tirage spécifiques dans le journal d’audit.

  • Des événements supplémentaires pour GitHub Actions sont désormais inclus dans le journal d’audit pour les entreprises et les organisations.

    • Un workflow est supprimé ou réexécuté.
    • La version d’un exécuteur auto-hébergé est mise à jour.
  • Authentification

  • GitHub AE prend désormais en charge officiellement Okta pour l’authentification unique (SSO) SAML et le provisionnement utilisateur avec SCIM. Vous pouvez également associer des groupes dans Okta à des équipes dans GitHub AE. Pour plus d’informations, consultez « Configuration de l’authentification et du provisionnement pour votre entreprise à l’aide d’Okta » et « Mappage de groupes Okta à des équipes ».

  • Le format des jetons d’authentification de GitHub AE a changé. Le changement affecte le format des jetons d’accès personnels et des jetons d’accès pour les applications OAuth, ainsi que des jetons d’utilisateur à serveur, de serveur à serveur et d’actualisation pour les applications GitHub. GitHub recommande de mettre à jour les jetons existants dès que possible, afin d’améliorer la sécurité et de permettre à l’analyse des secrets de détecter les jetons. Pour plus d’informations, consultez « À propos de l’authentification auprès de GitHub » et « À propos de l’analyse des secrets ».

  • Vous pouvez désormais authentifier les connexions SSH à GitHub AE avec une clé de sécurité FIDO2 en ajoutant une clé SSH sk-ecdsa-sha2-nistp256@openssh.com à votre compte. Les clés de sécurité SSH stockent les informations de clé secrète sur un appareil matériel séparé qui nécessite une vérification, par exemple un appui, pour fonctionner. Le stockage de la clé sur un appareil séparé et l’interaction physique obligatoire pour votre clé SSH permet de renforcer la sécurité. Dans la mesure où la clé est stockée sur du matériel et est non extractible, elle ne peut pas être lue ou volée par un logiciel exécuté sur l’ordinateur. L’interaction physique empêche l’utilisation non autorisée de la clé puisque la clé de sécurité ne fonctionne pas tant que vous n’avez pas physiquement interagi avec elle. Pour plus d’informations, consultez « Génération d’une nouvelle clé SSH et ajout de celle-ci à ssh-agent ».

  • Les versions 2.0.452 et ultérieures de Git Credential Manager (GCM) Core offrent désormais une prise en charge de l’authentification multifacteur et du stockage d’informations d’identification sécurisé pour GitHub AE. GCM Core avec prise en charge de GitHub AE est fourni avec Git pour Windows version 2.32 et ultérieures. GCM Core n’est pas fourni avec Git pour macOS ou Linux, mais peut-être installé séparément. Pour plus d’informations, consultez la dernière version et les instructions d’installation dans le dépôt microsoft/Git-Credential-Manager-Core.

  • Notifications

  • Vous pouvez désormais configurer les événements pour lesquels vous voudriez être notifié dans GitHub AE. À partir de n’importe quel dépôt, sélectionnez le menu déroulant Suivre, puis cliquez sur Personnalisé. Pour plus d’informations, consultez « Configuration des notifications ».

  • Problèmes et demandes de tirage

  • Dans la dernière version d’Octicons, l’état des problèmes et des demandes de tirage se voit maintenant beaucoup mieux, ce qui vous permet de le repérer plus facilement. Pour plus d’informations, consultez the GitHub Blog.

  • Vous pouvez maintenant voir tous les commentaires de révisions de demande de tirage sous l’onglet Fichiers de chaque demande de tirage en sélectionnant le menu déroulant Conversations. Vous pouvez également demander à ce que tous les commentaires de révision des demandes de tirage soient résolus avant que quiconque ne fusionne les demandes de tirage. Pour plus d’informations, consultez « À propos des révisions de demande de tirage » et « À propos des branches protégées ». Pour plus d’informations sur la gestion des paramètres de protection des branches avec l’API, consultez « Branches » dans la documentation de l’API REST et « Mutations » dans la documentation de l’API GraphQL.

  • Vous pouvez désormais charger des fichiers vidéo partout où vous écrivez en Markdown dans GitHub AE. Partagez des démos, indiquez des étapes de reproduction et plus encore dans les commentaires sur les problèmes et les demandes de tirage, mais aussi dans les fichiers Markdown dans les dépôts, comme les fichiers README. Pour plus d’informations, consultez « Attachement de fichiers ».

  • GitHub AE affiche désormais une boîte de dialogue de confirmation quand vous demandez une révision par une équipe de plus de 100 membres, ce qui vous permet d’éviter les notifications superflues pour les grandes équipes.

  • Quand un problème ou une demande de tirage a moins de 30 destinataires possibles, le contrôle des destinataires liste tous les utilisateurs potentiels plutôt qu’un ensemble limité de suggestions. Ce comportement permet aux membres de petites organisations de trouver rapidement le bon utilisateur. Pour plus d’informations sur l’affectation d’utilisateurs aux problèmes et demandes de tirage, consultez « Affectation de problèmes et de demandes de tirage à d’autres utilisateurs GitHub ».

  • Vous pouvez désormais inclure plusieurs mots après le # dans un commentaire de problème ou de demande de tirage afin d’affiner votre recherche. Pour rejeter les suggestions, appuyez sur Échap.

  • Pour empêcher la fusion de modifications inattendues après avoir activé la fusion automatique pour une demande de tirage, la fusion automatique est désormais désactivée automatiquement quand de nouvelles modifications sont poussées par un utilisateur sans accès en écriture au dépôt. Les utilisateurs sans accès en écriture peuvent quand même mettre à jour la demande de tirage avec les modifications de la branche de base quand la fusion automatique est activée. Pour empêcher un utilisateur malveillant de se servir d’un conflit de fusion pour introduire des modifications inattendues à la demande de tirage, GitHub AE désactive la fusion automatique pour la demande de tirage si la mise à jour entraîne un conflit de fusion. Pour plus d’informations sur la fusion automatique, consultez « Fusion automatique d’une demande de tirage ».

  • Les personnes avec un accès en maintenance peuvent désormais gérer le paramètre « Autoriser la fusion automatique » au niveau du dépôt. Désactivé par défaut, ce paramètre détermine si la fusion automatique est disponible pour les demandes de tirage présentes dans le dépôt. Avant, seules les personnes avec un accès d’administration pouvaient gérer ce paramètre. En outre, ce paramètre peut désormais être contrôlé à l’aide des API REST « Créer un dépôt » et « Mettre à jour un dépôt ». Pour plus d’informations, consultez « Gestion de la fusion automatique pour les demandes de tirage dans votre dépôt ».

  • La sélection de destinataires pour les problèmes et les demandes de tirage prend désormais en charge la recherche avec autocomplétion, ce qui vous permet de trouver plus rapidement les utilisateurs de votre organisation. De plus, les classements des résultats de recherche ont été mis à jour pour préférer les correspondances en début de nom d’utilisateur ou de nom de profil d’une personne.

  • Référentiels

  • Lors de la consultation de l’historique des commits d’un fichier, vous pouvez désormais cliquer sur pour afficher le fichier de l’heure spécifiée dans l’historique du dépôt.

  • Vous pouvez maintenant utiliser l’interface utilisateur web pour synchroniser une branche obsolète d’une duplication (fork) avec la branche en amont de la duplication. En l’absence de conflits de fusion entre les branches, GitHub AE met à jour votre branche par transfert rapide (« fast-forwarding ») ou par fusion depuis la branche en amont. En présence de conflits, GitHub AE vous invite à ouvrir une demande de tirage pour les résoudre. Pour plus d’informations, consultez « Synchronisation d’une duplication ».

  • Vous pouvez maintenant trier les dépôts sur un utilisateur ou un profil d’organisation par nombre d’étoiles.

  • Le point de terminaison « comparer deux commits » de l’API REST Dépôts, qui retourne une liste des commits accessibles depuis un commit ou une branche, mais non accessibles depuis d’autres, prend désormais en charge la pagination. L’API peut désormais aussi retourner les résultats de comparaisons de plus de 250 commits. Pour plus d’informations, consultez la documentation de l’API REST « Commits » et « Traversée avec pagination ».

  • Quand vous définissez un sous-module dans votre entreprise avec un chemin relatif, vous pouvez désormais cliquer sur ce sous-module dans l’interface utilisateur web. Le fait de cliquer sur le sous-module dans l’interface utilisateur web vous dirige vers le dépôt associé. Avant, vous ne pouviez cliquer que sur les sous-modules assortis d’URL absolues. Les chemins relatifs pour les dépôts avec le même propriétaire qui suivent le modèle ../REPOSITORY ou les chemins relatifs pour les dépôts avec un propriétaire différent qui suivent le modèle ../OWNER/REPOSITORY sont pris en charge. Pour plus d’informations sur l’utilisation de sous-modules, consultez Utilisation de sous-modules sur the GitHub Blog.

  • Grâce au précalcul des sommes de contrôle, le temps pendant lequel un dépôt est sous verrou a été considérablement réduit, ce qui permet à un plus grand nombre d’opérations d’écriture de réussir tout de suite et d’améliorer les performances du monodépôt.

  • Versions

  • Vous pouvez maintenant réagir avec un emoji à toutes les mises en production dans GitHub AE. Pour plus d’informations, consultez « À propos des mises en production ».

  • Thèmes

  • Les thèmes sombre et grisé sont désormais disponibles pour l’interface utilisateur web. GitHub AE s’aligne sur vos préférences système si vous n’avez pas de préférences de thème dans GitHub AE. Vous pouvez aussi personnaliser les thèmes qui sont actifs jour et nuit. Pour plus d’informations, consultez « Gestion de vos paramètres de thème ».

  • Markdown

  • Désormais, les fichiers Markdown de vos dépôts génèrent automatiquement un sommaire dans l’en-tête quand le fichier a plusieurs titres. La table des matières est interactive et dirige vers la section correspondante. Les six niveaux de titre Markdown sont tous pris en charge. Pour plus d’informations, consultez « À propos des fichiers README ».

  • Le balisage code est maintenant pris en charge dans les titres des problèmes et des demandes de tirage. Le texte entre accents graves (`) apparaît dans une police à largeur fixe partout où le problème ou la demande de tirage apparaît dans l’interface utilisateur web pour GitHub AE.

  • Lorsque vous modifiez le code Markdown dans les fichiers, les problèmes, les demandes de tirage et les commentaires, vous pouvez désormais utiliser un raccourci clavier pour insérer un bloc de code. Le raccourci clavier est command + E sur un Mac ou ctrl + E sur d’autres appareils. Pour plus d’informations, consultez « Syntaxe de base pour l’écriture et la mise en forme  ».

  • Vous pouvez ajouter ?plain=1 à l’URL d’un fichier Markdown pour afficher le fichier sans rendu et avec des numéros de ligne. Vous pouvez utiliser la vue brute pour lier d’autres utilisateurs à des lignes spécifiques. Par exemple, l’ajout de ?plain=1#L52 met en évidence la ligne 52 d’un fichier Markdown en texte brut. Pour plus d’informations, consultez « Création d’un lien permanent vers un extrait de code ».

  • Applications GitHub

  • Les demandes d’API pour créer un jeton d’accès d’installation respectent maintenant les listes vertes d’adresses IP d’une entreprise ou organisation. Toute demande d’API créée avec un jeton d’accès d’installation pour une application GitHub installée dans votre organisation respecte déjà les listes vertes d’adresses IP. Cette fonctionnalité ne tient actuellement pas compte des règles de groupe sécurité réseau (NSG) Azure que GitHub Support a configurées pour votre entreprise. Pour plus d’informations, consultez « Restriction du trafic réseau vers votre entreprise », « Gestion des adresses IP autorisées pour votre organisation » et « Applications » dans la documentation de l’API REST.

  • Webhooks

  • Vous pouvez désormais renvoyer ou vérifier programmatiquement l’état des webhooks via l’API REST. Pour plus d’informations, consultez « Dépôts », « Organisations » et « Applications » dans la documentation de l’API REST.

GitHub AE 3.1

GitHub a commencé à déployer ces changements pour les entreprises le March 03, 2021.

3.1.0: Features

  • GitHub Actions version bêta

  • 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 version bêta

  • 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 version bêta

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

  • Gérer les équipes de votre fournisseur d’identité (IdP)

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

  • Listes vertes d’adresses IP version bêta

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

3.1.0: Changes

  • Changements pour les développeurs

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

  • Changements au niveau de l’administration

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

  • Renommage des branches par défaut

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

3.1.0: Bug fixes

  • Résolution des bogues

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

3.1.0: Known issues

  • Problèmes connus

  • Les données de localisation géographique ne s’affichent pas dans le journal d’audit. Les informations géographiques peuvent sinon être trouvées à partir de l’adresse IP associée à chaque événement.

  • Le lien vers GitHub Packages dans une page de dépôt affiche une page de recherche incorrecte quand le dépôt n’a aucun package.