Incident en cours sur GitHub

 (githubstatus.com)
1 points par GN⁺ 1 일 전 | 1 commentaires | Partager sur WhatsApp
  • Une dégradation des performances des Pull Requests est en cours, et il est possible que toutes les pull requests indexées ne soient pas visibles sur les pages /pulls et /repo/pulls
  • Le cluster Elasticsearch ne contient pas actuellement tous les documents indexés, mais les données des pull requests elles-mêmes n’ont pas été perdues et sont réindexées lors de leur mise à jour
  • Le réindexage des index restants est en cours, ainsi qu’une accélération du full reindex afin de restaurer l’ensemble des résultats, avec priorité à l’exactitude et à l’évitement d’impacts supplémentaires
  • Dans le tableau d’état des composants, seules les Pull Requests sont indiquées en état dégradé ; Git Operations, Webhooks, API Requests, Issues, Actions, Packages, Pages, Copilot, Codespaces et Copilot AI Model Providers sont en état Operational
  • L’historique récent publie également plusieurs incidents et mesures de rétablissement, comme une dégradation de la recherche, des échecs de jobs Actions, des échecs de démarrage de sessions d’agent Copilot, une régression de la merge queue, des lenteurs sur Projects et des échecs de connexion à Codespaces

État actuel de l’incident

  • Une dégradation des performances est en cours sur les Pull Requests, publiée sous l’entrée Incomplete pull request results in repositories
  • Sur les pages /pulls et /repo/pulls, toutes les pull requests indexées peuvent ne pas être visibles
    • Le cluster Elasticsearch ne contient pas actuellement tous les documents indexés
    • Les données des pull requests elles-mêmes n’ont pas été perdues
    • Lorsqu’une pull request est mise à jour, elle est réindexée
    • Une accélération du full reindex est également en cours pour restaurer l’ensemble des résultats
  • Les index Elasticsearch restants sont en cours de réindexage, avec priorité à l’exactitude et en évitant tout impact supplémentaire
    • Une approche prudente est maintenue pour backfill les données en toute sécurité

État des composants

  • Dans le tableau d’état actuel, seules les Pull Requests sont affichées en Degraded Performance
  • Les autres composants principaux sont en état Operational
    • Git Operations
    • Webhooks
    • API Requests
    • Issues
    • Actions
    • Packages
    • Pages
    • Copilot
    • Codespaces
    • Copilot AI Model Providers
  • Le taux de disponibilité sur les 90 derniers jours est également fourni
    • Pull Requests : 99.58% uptime
    • API Requests : 99.95% uptime
    • Packages : 99.97% uptime
    • Copilot AI Model Providers : 100.0% uptime

Pages d’état régionales et canaux d’abonnement

Historique récent des incidents

  • 28 avril : incident sur certains services GitHub

    • L’entrée Disruption with some GitHub services est résolue
    • Des retards au démarrage et des échecs se sont produits sur des jobs Ubuntu hébergés par Actions
      • Certaines exécutions ubuntu-latest et ubuntu-24.04 ont été retardées ou ont échoué
      • Environ 5% des jobs ont été touchés à un moment, puis ce chiffre est descendu à moins de 2%, puis à moins de 1%
    • Le problème qui empêchait l’exécution d’Actions a été atténué, puis le fonctionnement normal a été rétabli

  • 27 avril : dégradation de la recherche GitHub

    • L’entrée GitHub search is degraded est résolue
    • Des problèmes de connexion à Elasticsearch et une charge supplémentaire ont provoqué des échecs de recherche ainsi que des problèmes sur plusieurs sous-services
      • Issues, Pull Requests, Packages et Actions ont été touchés
      • Des échecs de workflow run, des échecs de chargement de projects et des timeouts de recherche se sont produits
    • Après blocage de la cause de la charge supplémentaire, des signes de reprise sont apparus, puis le suivi est passé en phase de stabilisation

  • 27 avril : incident sur les sessions Codex de Copilot Cloud Agent

    • L’entrée Disruption with some GitHub services est résolue
    • Des échecs de démarrage de sessions d’agent Codex se sont produits dans Copilot Cloud Agent
      • Le démarrage échouait depuis tous les points d’entrée, notamment l’assignation d’issues et les mentions @copilot en commentaire
      • 0.5% de l’ensemble des tâches Copilot Cloud Agent ont été touchées, soit environ 2,000 jobs en échec
      • Les autres sessions d’agent de Copilot n’ont pas été affectées
    • La cause était un model resolution mismatch qui sélectionnait à l’exécution un modèle incompatible pour les sessions d’agent Codex
    • Une mesure d’atténuation a été déployée pour choisir un modèle par défaut stable pour les sessions d’agent Codex

Cas majeurs avec publication de la cause racine

  • Régression de la merge queue des Pull Requests

    • Incident with Pull Requests est résolu
    • Lors de l’utilisation du mode squash merge dans la merge queue, si un merge group contenait plus d’une PR, un mauvais merge commit pouvait être créé
      • Lors des fusions suivantes, des changements d’anciennes PR ainsi que des changements d’anciens commits pouvaient être annulés
      • 2,092 pull requests ont été touchées pendant la période d’impact
    • Les PR fusionnées hors merge queue, ainsi que certains groupes utilisant merge ou rebase, n’ont pas été affectés
    • La cause était l’application d’un nouveau chemin de code ajustant le calcul de la merge base avec un feature flag gating incomplet
    • Le changement de code a été annulé et un déploiement forcé a été effectué sur l’ensemble de l’environnement, tandis qu’une procédure de restauration a été transmise séparément aux administrateurs des dépôts concernés
    • La couverture des tests de correction des fusions est ensuite en cours d’extension pour inclure aussi les groupes squash multi-PR

  • Impossible de démarrer des agents Claude et Codex depuis le web

    • Disruption with users unable to start Claude and Codex agent task from the web est résolu
    • Il était impossible de démarrer une nouvelle tâche d’agent avec Claude ou Codex depuis github.com
    • La cause était une modification du code de routage des requêtes de création de tâche dans Copilot mission control
    • Les tâches d’agent en cours et les autres fonctionnalités d’agent Copilot n’ont pas été affectées
    • Le changement en cause a été annulé pour rétablir le service, et un monitoring supplémentaire ainsi que des tests d’intégration sont en cours d’ajout sur le chemin de création des tâches

  • Omission du traitement des mentions @ dans Copilot

    • Disruption with some GitHub services est résolu
    • Les mentions @copilot dans les commentaires de pull request ne déclenchaient pas l’exécution de l’agent de code Copilot
      • Environ 23,000 invocations, soit 0.5% de l’ensemble des commentaires de pull request et d’issue, n’ont pas été traitées
      • La création, la consultation et les réponses aux commentaires elles-mêmes n’ont pas été affectées
    • La cause était une serialization error qui empêchait la publication des événements vers le downstream consumer
    • Après le déploiement d’un correctif restaurant la publication des événements, le traitement normal a repris, et des vérifications du schéma d’événement ainsi que des améliorations de monitoring sont en cours

  • Interruption de Copilot Chat et de Cloud Agent

    • Disruption with Copilot chat and Copilot Coding Agent est résolu
    • Des erreurs se sont produites sur Copilot Chat et Copilot Cloud Agent sur github.com, les rendant indisponibles pendant cette période
    • Copilot Memory, en préversion, était également indisponible dans les sessions d’agent
    • La cause était un problème de connexion à la base de données provoqué par un changement de configuration de l’infrastructure
    • github.com a été rétabli en premier, puis les déploiements dans les autres régions ont été restaurés progressivement

  • Lenteurs du service Projects

    • Disruption with projects service est résolu
    • Projects pouvait ne pas se synchroniser ou refléter les changements avec retard
      • Le délai de prise en compte des changements a pu atteindre environ 45 minutes
    • La cause était une serialization error qui a provoqué des échecs d’événements et une forte hausse des resynchronisations, surchargeant la couche de traitement des événements
    • L’atténuation a consisté à accélérer le traitement des changements entrants, puis le service a été rétabli au fur et à mesure de la résorption du backlog

  • Dégradation de la configuration par défaut du code scanning et de Code Quality

    • Partial degradation for code scanning default setup and for code quality est résolu
    • Sur les nouvelles pull requests, code scanning default setup et les analyses Code Quality ne se déclenchaient pas
    • Un problème où les nouvelles issues n’apparaissaient pas sur le project board s’est également produit
    • La cause était une serialization error empêchant le déclenchement correct du code scanning, de l’analyse de qualité de code et des mises à jour du project board
    • La publication des événements code scanning et code quality a été rétablie, et la partie project board a été restaurée avec des changements de code supplémentaires et un reindex
    • Pour les PR non traitées avant ou pendant l’incident, un nouveau push est nécessaire pour redéclencher l’analyse

Autres incidents récents

  • Disruption with some GitHub services
    • L’expérience web de GitHub.com a été dégradée, et environ 1.5% des requêtes web se sont terminées en erreur
    • À certains moments, environ 10% du trafic web a été ralenti ou a échoué
    • La cause était la saturation de capacité d’un composant de cache dans une région de datacenter
    • Le trafic a été redirigé vers une région non affectée et un déploiement récent a été annulé pour rétablir le service
  • Incident with Codespaces
    • La connexion à GitHub Codespaces via l’éditeur VS Code a échoué
    • Environ 40% des tâches de démarrage de codespace ont échoué
    • Les connexions SSH n’ont pas été affectées
    • La cause était une panne du service de téléchargement upstream, empêchant le téléchargement de VS Code Server nécessaire au démarrage
    • Une solution de contournement utilisant un chemin de téléchargement alternatif lorsque l’endpoint par défaut est dégradé a permis d’atténuer le problème
  • Disruption with some GitHub services
    • L’accès à la page Copilot Insights de GitHub Enterprise Cloud renvoyait des erreurs 500
    • Environ 709 utilisateurs ont été touchés, pour une durée d’impact totale d’environ 5 heures et 10 minutes
    • La cause était un échec d’authentification dans le metrics pipeline ainsi qu’un changement de tenant credential
    • Des outils de diagnostic, un monitoring plus fin et un renforcement de l’alerting sont en cours

À lire aussi

1 commentaires

 
GN⁺ 1 일 전
Avis Hacker News

  • Le fait que ça échoue silencieusement est encore plus problématique en ce moment
    Par exemple, il y a des dizaines de PR, mais l’interface affiche "There aren’t any open pull requests.", ce qui induit clairement les gens en erreur

    • La semaine dernière, utiliser la merge queue a même supprimé trunk par erreur, et là aussi ça a échoué silencieusement
    • De notre côté, on plaisante presque en se félicitant, puisque ça donne enfin l’impression qu’on a terminé toutes les PR
    • Même quand la liste des PR s’affiche, il arrive qu’elle ne montre pas toutes les PR de la catégorie consultée, ce qui est vraiment vicieux

  • Ça me parle énormément
    Il y a quelques mois, $PARENT_CONGLOMERATE a imposé une migration vers GitHub à toute l’organisation au nom de la synergie et de l’efficacité, et maintenant c’est au tour de $DAYJOB de quitter son GitLab self-hosted
    J’ai déjà plusieurs griefs
    La politique IT autour des comptes GH est incohérente : impossible d’utiliser un compte existant, qu’il soit personnel ou créé autrefois séparément pour $DAYJOB, il faut recréer un nouveau compte conforme aux règles IT
    On n’utilise pas de monorepo, donc on s’appuyait beaucoup sur les groups, et GitHub n’a pas d’équivalent direct, ce qui oblige à réorganiser manuellement les namespaces de projet
    Et en plus, voilà maintenant la disponibilité de GitHub
    Les échéances de lancement de notre équipe sont sensibles au chiffre d’affaires, donc un retard d’un ou deux jours peut suffire à faire la différence sur l’atteinte des objectifs mensuels
    Dans un autre contexte, on aurait sans doute mis en place à l’avance un miroir du code critique pour les revenus, mais ça ne vaut pas le risque de bricoler un contournement aussi improvisé
    J’aimerais pouvoir rejeter la faute sur The Synergy Mandate dans un futur postmortem, mais je sais très bien que ça n’arrivera pas
    J’espère seulement qu’on continuera à atteindre les objectifs de revenus et qu’aucun produit ne se fera sabrer pour sous-performance
    En l’écrivant, je réalise encore plus à quel point ce travail a changé depuis mon arrivée

  • J’ai envie de le redire à tous les projets OSS
    Synchroniser le code entre plusieurs forge avec une simple tâche CI est extrêmement facile, et recevoir les notifications mail d’une deuxième forge n’ajoute pratiquement aucune charge
    Il faut au minimum laisser ouverte la possibilité de contribuer en dehors de GitHub, et au final ce sera mieux pour tout l’écosystème

    • La synchronisation du code elle-même est simple et triviale, et la tâche CI ne résout en fait que cette partie
      Pour la plupart des projets, même ça n’est peut-être pas absolument indispensable
      Le plus difficile, c’est tout ce qu’il y a autour du code
      Les tickets et les PR, y compris l’historique des éléments fermés
      Tous les liens qui référencent le projet
      La configuration CI
      Pour les gros projets, la gestion des droits de commit
      Et si nécessaire, jusqu’aux règles de push/commit/branch
      Tout cela est très pénible à migrer projet par projet, et une partie peut se perdre
      Mais le plus gros problème, c’est de perdre la plateforme par défaut pour découvrir du logiciel
      J’attends toujours une sorte de fediverse du logiciel
    • La synchronisation est triviale, mais le vrai cœur du sujet, c’est la CI
      GitHub Actions reste encore la meilleure option, et ni la FSF ni les autres labs OSS n’ont réussi à fournir une CI correcte aux mainteneurs open source
      En plus, la charge CI est devenue bien plus lourde qu’avant
    • Monter sa propre instance GitLab peut aussi être une bonne solution

  • Je commence à penser qu’il faut sérieusement pousser les alternatives
    Ça commence à avoir un impact réel sur notre activité, et rien ne laisse penser que ça va s’améliorer

    • Si vous voulez une UI proche de GitHub, utilisez Forgejo ou Gitea
      Il faut accepter la contrainte de la structure org/repo
      Si vous voulez une expérience similaire mais un peu différente, GitLab convient mieux
      Si vous préférez quelque chose de plus proche du monde kernel — hébergement et structure de dépôts flexibles, authentification utilisateur via ssh key, UI web simple — alors gitolite avec cgit, ou gitweb, fera l’affaire
    • Ça fait des années qu’on self-host Gitea avec Drone/Woodpecker, et ça marche très bien
      Que ce soit Gitea ou Forgejo, tant que les fonctionnalités conviennent, c’est largement suffisant
      Je passe parfois dans les discussions sur les pannes de GitHub pour en rire un peu : au total, notre instance Gitea n’a eu que quelques minutes d’indisponibilité sur les dernières années, et c’était à chaque fois des mises à niveau planifiées en pleine nuit
    • Je suis surpris que GitLab n’attire pas davantage l’attention
      Ce n’est pas une copie conforme, mais c’est suffisamment proche ; je dirais qu’on est plus dans la différence entre une pomme et une poire qu’entre une orange et une pomme
    • Je pensais la même chose
      Cela dit, GitHub est vraiment une plateforme collante : une fois qu’on a installé actions et toutes sortes d’intégrations, il devient difficile d’en partir
      Mais à ce rythme, la fréquence des pannes devient franchement absurde
    • On self-host maintenant Git et la CI avec Forgejo, et ça tourne de manière très satisfaisante

  • Ça n’a pas l’air d’être limité à GitHub : on dirait une panne plus large : https://downdetector.com

    • Le dénominateur commun semble très probablement être Azure

  • Encore une fin de journée avec un y dans le mot day, donc ça veut dire qu’il y a bien une panne GitHub

  • Codeberg.org a aussi des problèmes en ce moment

    https://status.codeberg.org/status/codeberg

    https://social.anoxinon.de/@codebergstatus/11647770704799298...

  • Si vous n’aimez ni voir GitHub tomber, ni que l’IA vole votre code, essayez sourcehut
    Ça me convient très bien, et j’aimerais vraiment voir la plateforme prospérer davantage

    • J’ai tellement aimé l’expérience d’exploration de nouveaux dépôts que j’ai tout déplacé vers Codeberg, et la plupart des projets qui m’intéressent y sont aussi
    • Je ne vois pas bien ce que sourcehut a de différent
      Au fond, ce n’est pas juste un autre service centralisé ?

  • Celle-ci semble durer particulièrement longtemps
    Ça m’a fait penser à une blague du genre : l’équipe chargée de la correction est bloquée par une limite de session Claude et ne peut rien faire avant la fin du cooldown, tandis que la seule personne capable de corriger ça sans IA est absente pour une opération
    Je me demande aussi ce qui se passera quand toute la génération qui savait réparer ça sans IA sera partie à la retraite

  • À chaque fois que GitHub tombe, quelques personnes de plus migrent vers des alternatives éthiques, et la dépendance de la communauté FOSS à un SPOF chez Microsoft s’affaiblit un peu

    https://sfconservancy.org/GiveUpGitHub/

    • Je suis d’accord avec l’idée générale, mais il y avait clairement un avantage au volet social du fait que tant de projets se trouvent sur GitHub
      La collaboration était facile, et aujourd’hui la friction augmente pour toutes sortes de raisons
      Les issues servent de plus en plus au spam, et on commence à voir apparaître des activités encore plus malveillantes
    • SPOF signifie Single Point of Failure