GitHub

Disponibilité actuelle

GitHub n’est enregistré dans le runtime que lorsqu’une connexion valide existe pour l’utilisateur courant. Sans connexion, les tools GitHub ne sont pas exposés.

Dans Settings → Connectors, l’interface affiche l’un des états suivants : Checking, Connected ou Not connected.

Lorsqu’il est connecté, OrbitWake affiche les dépôts autorisés visibles par l’installation GitHub ainsi que la dernière activité runtime disponible.

Connecter GitHub

Le bouton Connect GitHub démarre un flux en deux parties :

Protection du flux de connexion

Les états d’installation et d’OAuth sont stockés dans des cookies httpOnly, sameSite=lax et sécurisés en production.

Ils expirent après 10 minutes et sont consommés une seule fois. Leur comparaison utilise une vérification temporellement sûre.

Les valeurs sont chiffrées avant stockage dans le cookie. Un state absent, incorrect ou déjà consommé invalide le callback.

Stockage des credentials

OrbitWake conserve l’ID d’installation, le token d’accès et, lorsqu’ils existent, les informations de refresh dans une enveloppe chiffrée.

Le chiffrement serveur utilise AES-256-GCM avec des données associées liées au workspace et à l’utilisateur. Le modèle n’a pas besoin de recevoir ces credentials pour exécuter une action du connecteur.

Lors du chargement de la connexion, OrbitWake valide le credential avant de créer le client GitHub runtime.

Expiration et refresh

Si un token possède une date d’expiration et qu’il lui reste plus de 60 secondes, OrbitWake le réutilise.

Lorsque l’expiration approche, le runtime tente un refresh si un refresh token valide existe. Le credential rafraîchi est ensuite resauvegardé.

Si l’autorisation a expiré et qu’aucun refresh valide n’est disponible, la connexion doit être effectuée de nouveau.

Dépôts autorisés

La liste des dépôts provient de l’installation GitHub associée à l’utilisateur. Le client récupère jusqu’à 100 dépôts par page et parcourt actuellement au maximum 10 pages.

OrbitWake applique ensuite sa propre portée github.repositories. La connexion créée actuellement utilise *, ce qui signifie que la portée OrbitWake accepte les dépôts rendus disponibles par l’installation GitHub.

L’interface Settings affiche jusqu’à 20 dépôts dans la liste visuelle, avec le nom complet, la visibilité et la branche par défaut lorsqu’elles sont disponibles.

Le bouton Manage repositories ouvre la gestion des installations GitHub afin de modifier les dépôts exposés par GitHub.

Actions de lecture

Les actions de lecture utilisent la permission read, autorisée par défaut dans la politique Connectors actuelle.

Actions d’écriture

Les écritures utilisent la permission write. La politique par défaut est ask : l’action attend donc une approbation avant d’être exécutée.

Création et mise à jour de fichiers

Les actions create_file et update_file travaillent directement avec l’API Contents de GitHub. Elles ne reproduisent pas un workflow local git add → git commit → git push.

Une écriture réussie crée directement un commit distant dans le dépôt GitHub ciblé.

Pour une mise à jour, le SHA courant du fichier est obligatoire. Si le fichier a changé depuis la dernière lecture, GitHub peut refuser l’écriture au lieu d’écraser silencieusement un état plus récent.

Pull requests

OrbitWake peut ouvrir une PR avec un titre, une branche source, une branche cible, un corps optionnel et un indicateur draft.

La création de PR est une action write et reste donc soumise à approbation par défaut.

L’ouverture d’une PR ne remplace pas les protections GitHub : reviews, checks CI, règles de branche et validations configurées sur le dépôt continuent de s’appliquer côté GitHub.

Merge de pull request

github.merge_pull_request est classée sensitive. Avec la politique par défaut, elle nécessite une approbation explicite.

L’action actuelle cible une PR par son numéro et appelle l’endpoint de merge GitHub sans imposer un merge method personnalisé dans cette implémentation.

Le merge doit rester la dernière étape après revue du contenu et validation des checks exigés par le dépôt.

Approbations exactes

Une approbation est liée au connecteur, au nom de l’action et au hash des paramètres exacts. Modifier le dépôt, la branche, le fichier, le contenu ou le numéro de PR produit une autre entrée et invalide l’approbation précédente pour cette nouvelle opération.

Une approbation expire après 10 minutes et ne peut être consommée qu’une fois.

État de la connexion

La surface de statut vérifie le runtime de l’utilisateur puis exécute github.list_repositories. Elle retourne notamment l’état connecté, les dépôts disponibles et l’activité générée pendant cette vérification.

Si la connexion existe mais que la lecture GitHub échoue, l’interface peut rester marquée comme connectée tout en affichant une erreur. Si le credential est invalide ou le runtime ne peut plus charger la connexion, le statut peut demander une reconnexion.

Déconnecter GitHub

Le bouton Disconnect supprime le compte connecteur GitHub enregistré dans le workspace OrbitWake de l’utilisateur.

Cette opération retire les credentials et empêche le runtime OrbitWake d’enregistrer le connecteur GitHub pour cet utilisateur.

Elle ne doit pas être confondue avec la suppression de l’installation GitHub App depuis les paramètres GitHub. La gestion de l’installation elle-même reste côté GitHub.

Erreurs de connexion courantes

Limites actuelles

Le connecteur actuel ne fournit pas un client Git complet : pas de clone local, staging, rebase, cherry-pick, stash, tags ou résolution visuelle de conflits.

read_file est destiné aux fichiers renvoyés avec un encodage GitHub base64 et décodables en UTF-8 ; un répertoire n’est pas accepté comme fichier.

Les listes de branches, PR et issues utilisent actuellement une seule page de résultats. La liste des dépôts parcourt au maximum 10 pages de 100 dépôts.

La gestion fine des dépôts exposés se fait aujourd’hui principalement via l’installation GitHub ; la connexion OrbitWake créée par défaut stocke une portée github.repositories = ["*"].

Workflow recommandé

Étapes suivantes

Les pages Services Google et Intégrations externes seront publiées lorsqu’un runtime vérifiable sera réellement disponible pour ces fournisseurs. Elles ne sont pas documentées comme actives aujourd’hui.