Codeball

Qu’est-ce que Codeball ?

Codeball est un outil d’analyse automatique des Pull Request sur GitHub, développé par l’équipe Sturdy. Créé en 2020, il a été sélectionné pour le lot hivernal de Y Combinator en 2021. Il utilise des modèles d’apprentissage automatique pour attribuer une note comprise entre 0 et 1 aux contributions de code, et approuve, marque ou bloque les PR en fonction d’une seuil défini.

Son objectif n’est pas d’expliquer ligne par ligne tout le code comme un chatbot, mais plutôt de déterminer si une contribution est suffisamment sûre pour être rapidement examinée manuellement. L’équipe peut également marquer les modifications à faible ou moyenne fiabilité comme nécessitant un examen ou un examen prudent.

Statut actuel du fonctionnement

Au 21 août 2026, Codeball ne peut plus être présenté comme un service normal de revue de code par IA en fonctionnement. La page de Y Combinator le marque comme Inactive, et le site officiel du produit a été remplacé par un site intitulé AI BallCode, contenant des articles liés au jeu d’argent.

Le nom de domaine de l’API distante auquel se connecte par défaut Action open source ne peut pas être résolu pour le moment, ce qui empêche la création de tâches de revue Codeball normales pour les nouveaux workflows. GitHub Marketplace conserve encore l’entrée v2.6.0 ainsi que l’identifiant d’éditeur vérifié, ce qui ne prouve que l’Action a été publiée par un partenaire officiel, mais pas que le service de modèle est toujours en ligne.

Une phrase pour présenter

Codeball analysait autrefois les Pull Request via GitHub Action et approuvait automatiquement les modifications de sécurité présentant un niveau de confiance élevé, mais son entreprise, son site web officiel et son backend de modèles à distance sont désormais tous hors service en tant que produit fonctionnel, ne servant plus qu’à des fins de recherche historique et de nettoyage de migration.

Fonction centrale historique

Score de risque du pull request

Codeball attribue à chaque PR une note allant de 0 à 1, où une note plus élevée indique que le modèle a tendance à considérer que cette contribution est acceptable. Le seuil par défaut d’approbation est de 0,935 ; les scores inférieurs à 0,300 peuvent être marqués comme nécessitant un examen approfondi.

Le seuil peut être modifié dans le flux de travail, mais une baisse du seuil d’approbation augmente le risque de mauvaise allocation. Le score ne reflète que les jugements statistiques du modèle ancien et ne peut pas remplacer les tests, les scans de sécurité, la validation métier et l’approbation du propriétaire du code.

Approbation automatique des PR de sécurité

Lorsque le score du modèle atteint le seuil d’approbation, Action peut soumettre une revue d’approbation. Cette fonctionnalité nécessite que le dépôt ou l’organisation autorise GitHub Actions à créer et à valider des Pull Request.

• Les contributions considérées comme sûres par le modèle d’approbation automatique.
• Marquer les PR à haute confiance comme codeball:approved.
• Supprimer les anciennes étiquettes de risque en conflit avec le nouveau jugement.
• Prend en charge l’utilisation de comptes de robot dédiés pour respecter le processus CODEOWNERS.
• Il est possible de désactiver l’approbation automatique et de ne conserver que les résultats d’observation des étiquettes.

Étiquette de risque

Action peut ajouter trois types d’étiquettes à PR en fonction des scores, permettant aux mainteneurs de traiter en premier les modifications à haut risque. La fonction d’étiquetage est plus adaptée aux essais que l’approbation automatique, car elle ne modifie pas directement l’état d’examen requis pour la fusion.

• codeball:approved indique que le modèle a atteint le seuil de confiance élevé.
• codeball:needs-review indique qu’une vérification manuelle habituelle est nécessaire.
• codeball:needs-careful-review indique qu’une vérification approfondie est nécessaire.
• Chaque exécution permet de supprimer les étiquettes anciennes qui ne correspondent pas au score actuel.
• L’équipe peut activer ou désactiver séparément différentes étiquettes.

Blocage CI

L’option failJobsWhenReviewNeeded permet au flux de travail de revenir à un état d’échec lorsque le modèle n’a pas approuvé la contribution. La valeur par défaut est false, ce qui signifie que Codeball ne bloque pas automatiquement le CI uniquement en raison d’une faible note du modèle.

Définir les résultats du modèle comme une vérification de fusion obligatoire aggraverait l’impact des pannes de service. L’API à distance étant actuellement introuvable, le maintien d’une vérification obligatoire pourrait empêcher tout nouveau PR d’être accepté.

Filtrage des chemins et dépassement des brouillons

Les conditions de chemin natives de GitHub Actions permettent de limiter Codeball à l’analyse d’un service ou d’un répertoire spécifique, et les conditions de workflow peuvent également ignorer les PR en version brouillon. Cela permet de réduire le nombre de modifications non pertinentes déclenchant des revues.

Suggestions pour convertir les commentaires en code

codeSuggestionsFromComments a été utilisé comme fonction de test pour convertir les commentaires des PR en suggestions de code. Cette option est désactivée par défaut, et la documentation existante ne prouve pas non plus que cette capacité de test soit entrée dans une phase stable.

Application Codeball AI Writer

Codeball AI Writer est une application GitHub conçue pour permettre aux PR provenant de Fork d’obtenir également l’approbation et les droits d’étiquetage. Il peut fournir des identités d’écriture pour des dépôts publics ou privés, mais dépend lui aussi du service distant Codeball.

L’installation de l’application GitHub confère des droits sur le répertoire ; il ne faut pas continuer à lui faire confiance simplement parce que la page du Marketplace est toujours présente. Les anciens utilisateurs doivent vérifier si l’application est toujours installée et annuler les accès non plus nécessaires une fois le service désactivé.

Fonctionnement historique de Codeball

1. GitHub déclenche des workflows lors de la création d’un nouveau PR ou de la mise à jour d’un PR.
2. Action lit l’adresse du Pull Request et le token GitHub.
3. Le client envoie l’adresse PR, le token d’accès et la valeur seuil à l’API distante de Codeball.
4. Le serveur utilise un jeton pour lire les informations relatives aux contributions et créer des tâches de révision asynchrone.
5. Vérifier l’état de la tâche de polling d’action pour obtenir le niveau de confiance, le résultat de l’approbation et l’état des recommandations.
6. Ajouter ou supprimer des étiquettes en fonction de la configuration, et décider s’il convient de soumettre à l’examen d’approbation.
7. Si l’échec forcé est activé, un résultat non approuvé fera en sorte que le flux de travail revienne à un état différent de zéro.

Les documents anciens indiquent que le modèle prend en compte des centaines d’entrées telles que l’hash perçu des différences de code, l’expérience récente de l’auteur avec les fichiers concernés, la fréquence de modification des fichiers, ainsi que les retraits ou corrections historiques. Le backend du modèle n’est pas open source dans le dépôt Action, et il n’est actuellement pas possible de reproduire les notes originales.

Guide d’installation historique

1. Créer un répertoire pour les workflows GitHub Actions dans le dépôt.
2. Fichiers de configuration de flux de travail supplémentaires pour Codeball.
3. Définissez l’événement déclencheur sur Pull Request et ajoutez les événements de commentaires selon les besoins.
4. Utiliser codeball-action v2, publié par sturdy-dev, dans le travail.
5. D’abord, désactivez l’approbation automatique et les échecs CI, et n’activez que les étiquettes pour l’observation.
6. Définir les permissions de lecture du contenu, d’écriture d’Issues et d’écriture de Pull Requests pour le flux de travail.
7. Soumettre à la branche de test pour examiner les résultats des étiquettes pour les PR à différents niveaux de risque.
8. Après avoir vérifié la précision et le coût des erreurs de jugement, on décide alors s’il convient d’étendre l’automatisation.

Il s’agit de la méthode de configuration historique ; il n’est pas recommandé d’ajouter ce flux de travail pour le moment. L’API à distance ne peut pas être interprétée, et le site officiel a également changé. Une nouvelle installation ne permettra pas seulement de terminer l’examen, mais introduira également des dépendances obsolètes et un design de transmission de tokens inutile.

Guide pour une désactivation sécurisée et une migration

1. Rechercher les références à sturdy-dev/codeball-action dans les fichiers du flux de travail du entrepôt.
2. Vérifier si les règles de protection des branches définissent Codeball comme une vérification obligatoire.
3. Supprimez d’abord les vérifications obligatoires pour éviter que la suppression du flux de travail ne bloque la fusion.
4. Supprimez ou désactivez le flux de travail Codeball, et soumettez une PR de nettoyage distincte.
5. Désinstaller l’application Codeball AI Writer dans les paramètres du entrepôt et de l’organisation.
6. Supprimer CODEBALL_BOT_TOKEN dédié et autres secrets associés.
7. Révoquer les droits d’entrepôt et le Personal Access Token inutiles pour le compte de robot dédié.
8. Vérifiez si les journaux des workflows récents ont affiché des réponses anormales ou des informations sensibles.
9. Choisissez un processus de révision alternatif encore en maintenance et validez-le d’abord en mode commentaire uniquement.

Utilisateurs applicables à l’histoire

Codeball n’est pas actuellement adapté à son déploiement par de nouveaux utilisateurs. Les types d’utilisateurs suivants ne conviennent qu’à comprendre sa positionnement initial en tant que produit, ou à effectuer la migration et le nettoyage sécurisé de dépôts existants.

• Mainteneur de projet open source : espérait initialement contribuer rapidement au sein d’une communauté à faible risque.
• Équipe PR haute fréquence : utiliser des étiquettes pour concentrer les efforts humains sur les modifications suspectes.
• Équipe d’ingénierie de plateforme : intégrer le jugement du modèle dans la pipeline GitHub Actions.
• Entrepôt à multiples services : ne vérifie que les modifications des dossiers spécifiés selon le chemin.
• Personnel de la sécurité et DevOps : examiner les anciennes workflows, les permissions des applications et les tokens.
• Chercheur en revue de code par IA : analyse des premiers systèmes de notation des PR basés sur des caractéristiques statistiques.

Scénarios d'utilisation historiques

• Approbation automatique des documents, mises à jour de dépendances ou autres PR à faible risque.
• Ajoutez des étiquettes indiquant qu’une modification complexe nécessite un examen attentif.
• Convertir les faibles scores du modèle en échec de CI pour empêcher les fusionnements non vérifiés.
• Sautez la PR de brouillon et lancez-la une fois que l’auteur aura terminé ses préparatifs.
• Déclencher le modèle uniquement en cas de modification du répertoire de services spécifié.
• Utiliser un compte robot pour fournir une identité d’approbation aux contributions sur Fork.
• Collecter les scores des modèles et les résultats de l’examen manuel, afin d’évaluer la valeur de l’automatisation.

Avantage historique

• Il suffit d’une configuration GitHub Actions pour intégrer au processus PR existant.
• Les scores de 0 à 1 et les étiquettes en trois niveaux facilitent une adoption progressive.
• Les trois stratégies — approbation automatique, uniquement les étiquettes et échec du CI — peuvent être combinées indépendamment.
• Prend en charge le filtrage des chemins, l’omission des brouillons et des identités de robots personnalisées.
• Le code source du client Action est public, les entrées clés et les permissions peuvent être examinées.
• La valeur seuil par défaut vise une haute précision, et l’objectif de la conception est de réduire les approbations automatiques erronées.

Ces avantages dépendent du bon fonctionnement des services de notation à distance. Le fait que le client soit open source ne peut pas compenser l’indisponibilité des modèles, des données d’entraînement, du backend et de la situation opérationnelle ; par conséquent, les avantages liés au design historique ne doivent pas être considérés comme une capacité d’achat actuelle.

Restrictions d'utilisation et risques

• L’entreprise a été marquée comme Inactive, faute de preuves d’entretien continu et de support client.
• Le site officiel d’origine a été remplacé par un autre site contenant d’autres contenus, et des thèmes liés au jeu d’argent y apparaissent.
• Le nom de domaine API distant par défaut ne peut pas être résolu, l’action ne peut pas créer de tâche normale.
• La dernière mise à jour du dépôt Action remonte à avril 2023, et les dépendances ainsi que l’environnement de exécution sont désuets.
• Le fait qu’une entrée sur GitHub Marketplace existe ne signifie pas que le service est en ligne.
• Action enverra l’adresse PR et le token d’accès GitHub à l’API distante.
• La politique de confidentialité et les conditions d’utilisation originales ne peuvent pas être consultées actuellement sur le site du produit.
• Le modèle et le backend d’entraînement ne sont pas open source, il n’est donc pas possible de reconstituer le service de notation localement.
• L’approbation automatique d’une PR erronée peut introduire des défauts, des problèmes de sécurité ou des modifications malveillantes dans la branche principale.
• Une configuration de défaillance forcée transforme les pannes des services externes en blocages de fusion.
• Les robots spécialisés et l’application GitHub élargissent les droits d’édition, qui doivent être révoqués en temps opportun.
• La précision et l’ampleur de l’entraînement dans les anciennes publicités ne peuvent pas être considérées comme des garanties de performance actuelles.
• Le code du dépôt public utilise l’environnement d’exécution Node Action ancien, ce qui entraîne une compatibilité insuffisante à long terme.
• Ne connectez-vous pas au site d’origine, dont l’usage a été modifié, ni n’installez aucun fichier.

Prix et disponibilité

Les documents historiques de Codeball proposaient une version d’essai gratuite, et certains catalogues tiers ont également mentionné des informations relatives aux frais, mais il n’existe actuellement aucune page officielle vérifiable concernant les prix, les facturations ou les abonnements. Aucun ancien prix ne doit être considéré comme valable pour les forfaits actuels.

Le fait que l’action open source puisse être téléchargée gratuitement ne signifie pas que le service Codeball soit gratuit, ni que l’on puisse exécuter le produit complet par soi-même. En l’absence de modèles backend et d’implémentations API, le client ne peut servir que de code historique et d’exemples de flux de travail.

Plateformes de support et intégration

Permissions, vie privée et sécurité

Les permissions recommandées pour GitHub Actions incluent la lecture du contenu du dépôt, l’écriture d’Issues et l’écriture de Pull Requests. Si une approbation automatique est nécessaire, il faut également permettre à GitHub Actions de créer et d’approuver les PR ; en utilisant un bot dédié, il convient de conserver un Personal Access Token doté de droits d’écriture.

Le client open source montre que, lors de la création d’une tâche, l’adresse du PR ou des commentaires, le token d’accès GitHub ainsi que le seuil d’approbation sont envoyés à l’API distante. Comme l’API est défectueuse et que la politique de confidentialité actuelle n’est plus disponible, on ne peut plus supposer que les engagements concernant l’accès aux données, leur conservation et leur suppression des anciens services restent valables.

• Ajustez les vérifications nécessaires pour la protection des branches avant de supprimer le flux de travail Codeball.
• Supprimer CODEBALL_BOT_TOKEN du dépôt et de l’organisation.
• Annuler l’ancien Personal Access Token de l compte de robot dédié.
• Désinstallez Codeball AI Writer et vérifiez la portée des autorisations de son dépôt.
• Vérifier le journal d’historique du flux de travail pour s’assurer qu’il n’y a pas de fuite de jetons ou de réponses sensibles.
• Ne faites pas de l’approbation par une IA à distance le seul critère de qualité du code.
• Les outils de remplacement doivent d’abord fonctionner en mode commentaire uniquement ou en mode étiquetage uniquement.
• Les entrepôts privés doivent disposer de politiques vérifiables pour le traitement des données, leur suppression et l’entraînement des modèles.

API, GitHub et statut open source

Codeball dispose bien d’un dépôt GitHub officiel, sturdy-dev/codeball-action, qui expose le client GitHub Action, plusieurs sous-Actions, des tests et des paramètres de configuration. La licence du répertoire est Apache 2.0, et à la date de vérification, il comptait environ 324 « Star » et 35 « Fork ».

Cependant, le dépôt ne contient que le client de flux de travail et la logique des opérations GitHub ; les modèles d’évaluation, les pipelines d’entraînement ainsi que le backend API cloud ne sont pas rendus publics. Le produit ne peut pas être qualifié de totalement open source ; on peut plutôt dire que « le client Action est open source, tandis que les modèles et le backend des services ne le sont pas et sont désormais indisponibles ».

Informations de base

Indice de recommandation

Le score de recommandation est de 1,3 sur 5. Les scores, les étiquettes, l’approbation automatique et la conception de blocage CI de Codeball restent utiles pour comprendre les processus de revue de code d’IA aux premières étapes de la recherche, et le code source d’Action facilite également la compréhension des permissions GitHub et des appels à distance.

Mais l’entreprise est inactive, l’usage de son site officiel initial a changé, le nom de domaine API par défaut ne peut pas être résolu, et le dépôt n’a pas fait l’objet d’entretien réel depuis des années. Il n’est pas adapté à un nouveau déploiement, et il ne faut surtout pas continuer à accéder au code privé ni conserver les droits d’édition sur le dépôt.

Questions fréquentes

Codeball fonctionne-t-il encore ?

Il ne peut pas être considéré comme un service disponible. L’entrée Action reste sur GitHub Marketplace, mais le nom de domaine API distant nécessaire pour créer des tâches ne peut actuellement pas être résolu.

Pourquoi le site officiel de Codeball n’est-il pas un outil d’audit de code ?

Le nom de domaine d’origine affiche désormais un site contenant du contenu AI BallCode, ainsi que des articles liés au jeu, ce qui indique que le contenu et l’état de contrôle du nom de domaine ont changé. Ne vous connectez pas à ce site, n’en téléchargez rien et ne donnez aucune autorisation à son dépôt.

Codeball est-il gratuit ?

Il n’existe actuellement aucun prix officiel vérifiable ni point d’achat. Le code source d’Action est disponible gratuitement sous licence Apache 2.0, mais le backend des modèles à distance n’est pas accessible, ce qui ne signifie pas qu’il existe des services cloud gratuits utilisables.

Va-t-il approuver automatiquement le PR ?

Historiquement, c’était possible : une demande pouvait être soumise à un examen d’approbation lorsque la valeur dépassait le seuil par défaut de 0,935. Actuellement, le service d’évaluation à distance n’est pas disponible, il ne faut donc plus compter sur ce processus d’approbation automatique.

Quelles permissions Action nécessite-t-il ?

La configuration historique nécessite de lire le contenu du dépôt et d’écrire des Issues et des Pull Requests. L’approbation automatique exige également que le dépôt autorise GitHub Actions à créer et à approuver les PR.

Pourquoi supprimer l’ancien token ?

Le client enverra le token d’accès de GitHub à l’API Codeball distante ; la solution avec des robots dédiés peut également conserver des tokens à long terme. Une fois le service désactivé, il n’est plus nécessaire de conserver ces identifiants.

Codeball est-il open source ?

Seul le client GitHub Action est open source, sous licence Apache 2.0. Le modèle de notation, le pipeline d’entraînement et le backend du service ne sont pas open source ; par conséquent, le produit complet n’est pas une solution open source.

Peut-on déployer Codeball soi-même ?

On ne peut pas déployer un service complet uniquement à partir d’un entrepôt public. L’entrepôt ne contient ni le modèle de notation original ni le backend API ; le client a encore besoin d’une interface pour les tâches à distance.

Comment supprimer les anciens flux de travail ?

Commencez par supprimer la vérification obligatoire de Codeball dans la protection des branches, puis retirez les workflows, les applications et les Secrets. Enfin, annulez le token du bot et vérifiez que la nouvelle PR n’attend plus l’ancien état.

Que représente l’indication Verified sur GitHub ?

Cela indique que GitHub a vérifié manuellement que le créateur de l’Action était une organisation partenaire officielle, ce qui ne signifie pas que GitHub valide les résultats de l’IA, ni qu’il garantit que le service distant est toujours en ligne.

Peut-on modifier le code source de Codeball pour en faire un nouvel outil ?

Il est possible d’étudier ou de modifier le code client sous les conditions d’Apache 2.0, mais il faut mettre en place soi-même un nouveau backend d’évaluation, une conception des droits d’accès et une politique de données. On ne peut plus supposer que l’API ou le modèle d’origine sont disponibles.

Résumé

Codeball a autrefois proposé une approche claire pour l’audit de code par IA : calculer un niveau de confiance pour chaque PR, puis intégrer les jugements du modèle dans le processus d’équipe à l’aide d’étiquettes, d’approbations ou d’états CI. Action publique conserve encore ces exemples de conception et de configuration côté client.

Ce qui est vraiment important actuellement, c’est la gestion sécurisée après l’arrêt du service, et non la poursuite de l’installation. L’équipe doit supprimer les vérifications nécessaires, les flux de travail, l’application GitHub et les anciens tokens, et passer à un système de review qui est encore maintenu, dont les conditions de données sont claires et qui peut d’abord être testé en mode commentaire uniquement.