Announcement
Cette page est également disponible en English, Deutsch, Español, Italiano, 日本語 et Português.
Threads crée désormais des issues GitHub
Envoyez vos constats FinOps depuis Insights et CloudFlow directement dans les dépôts où vos ingénieurs travaillent déjà. Disponible dès maintenant pour tous les clients Cloud Intelligence™.
La plupart du temps, le gaspillage cloud ne survit pas à sa première rencontre avec un backlog. Un insight signale une base de données inactive depuis 60 jours. Quelqu'un en fait une capture d'écran, la colle dans un chat, et l'affaire en reste là — parce que l'équipe responsable de la base planifie sa semaine dans GitHub Issues et que personne n'a voulu ouvrir un ticket dans un outil qu'il ne consulte jamais. Threads existe précisément pour fluidifier cette transmission, mais jusqu'à présent, seuls Jira et Linear étaient pris en charge. Si votre travail d'engineering se passe dans GitHub, la dernière étape restait du copier-coller. Ce n'est plus le cas : Threads peut désormais créer et suivre des issues GitHub.
Ce que vous y gagnez
Une fois l'application GitHub Cloud Intelligence Threads installée sur votre organisation ou votre compte personnel, GitHub Issues apparaît comme destination partout où des threads peuvent être créés. Depuis un insight, vous choisissez un dépôt, vérifiez le titre et la description préremplis, ajoutez éventuellement des labels et des assignés, et l'issue est créée. Dans CloudFlow, le nœud Threads dispose des mêmes champs (dépôt, titre, description en Markdown, labels, assignés) : un flux qui détecte une anomalie peut donc ouvrir l'issue de lui-même, chiffres à l'appui.
La page Integrations et l'en-tête Threads indiquent désormais quels outils parmi Jira, Linear et GitHub sont connectés : vous voyez d'un coup d'œil où un thread peut être envoyé avant même de le créer.
Cloud Intelligence™ continue de suivre l'issue après sa création. L'état, les labels, les assignés et le jalon sont lus depuis GitHub, et un bouton Manage in GitHub vous conduit directement à l'issue. Les modifications effectuées côté GitHub apparaissent dans la console. Si quelqu'un transfère l'issue vers un autre dépôt accessible à l'application, le thread suit. La console n'ajoute pas les issues aux GitHub Projects ; si votre équipe planifie dans un Project, activez son workflow d'ajout automatique intégré pour le dépôt concerné.
La configuration est volontairement sans surprise. L'application demande deux permissions au niveau des dépôts : Issues (lecture et écriture) et Metadata (lecture seule). Au moment de l'installation, vous décidez si elle peut accéder à tous les dépôts ou seulement à certains, un choix modifiable plus tard dans GitHub. L'installation est effectuée par un propriétaire de l'organisation ; si un membre la lance, GitHub transmet une demande d'approbation aux propriétaires et la console affiche Awaiting approval jusqu'à ce que l'un d'eux accepte. Désinstaller l'application déconnecte tout, et la console marque les threads GitHub existants comme indisponibles en quelques secondes.
Pour commencer
- Connectez GitHub depuis Integrations et installez l'application Cloud Intelligence Threads sur les dépôts de votre choix.
- Ouvrez un insight et créez un thread en choisissant GitHub Issues comme destination.
- Ou ajoutez une action Create a thread à un flux avec le nœud Threads et sélectionnez un dépôt.
GitHub Issues est disponible pour tout compte doté de la permission Thread Manager. Si vous utilisez déjà Threads avec Jira ou Linear, rien ne change : GitHub vient s'y ajouter. Les retours qui nous intéressent le plus viennent des équipes qui transmettent de vrais insights vers de vrais dépôts : quels champs manquent, ce que le corps de l'issue devrait contenir, et si le statut du thread a bien suivi l'avancement du travail.
