- Accès aux dépôts
- Suit les dépôts que vous sélectionnez
- Exécution des exécuteurs
- En service pour les dépôts d’organisation
- Dépôts de compte personnel
- Non pris en charge · utilisez une organisation
- Portées d’organisation
- Gérer les exécuteurs autohébergés · Lire les membres
- Fonctions d’écriture de l’IA
- Accès anticipé, désactivées par défaut
Disponibilité
Mis à jour le 21 octobre 2026 : Runzivo ne prend en charge que les dépôts d'organisation et ne demande pas la permission Administration. Cela remplace l'énoncé précédent selon lequel la prise en charge des dépôts personnels était prévue.
Après la connexion avec GitHub, associez une organisation GitHub dont vous êtes propriétaire, y compris une organisation GitHub Free, et sélectionnez les dépôts que vous voulez utiliser.
Les étiquettes d'exécuteur actuellement admissibles sont rzv-ubuntu-24.04-x64-2vcpu-8gb, rzv-ubuntu-24.04-x64-4vcpu-16gb, rzv-ubuntu-24.04-x64-6vcpu-24gb, rzv-ubuntu-24.04-x64-8vcpu-32gb, rzv-ubuntu-24.04-x64-16vcpu-64gb, rzv-ubuntu-24.04-x64-32vcpu-128gb. Créer un espace de travail n'ajoute pas d'accès aux dépôts : sélectionnez chaque dépôt pendant l'association de l'application GitHub partagée Runzivo.
L'association de l'installation, le provisionnement des exécuteurs JIT et les transitions du cycle de vie des exécuteurs prennent en charge le parcours GitHub Actions disponible.
Runzivo exécute des tâches pour des dépôts appartenant à des organisations GitHub. Les dépôts appartenant à un compte personnel ne sont pas pris en charge : GitHub ne permet à une application d'enregistrer un exécuteur sur un dépôt personnel que si elle détient Administration : lecture et écriture, et Runzivo ne demande pas cette permission. Pour utiliser Runzivo avec un dépôt personnel, créez une organisation GitHub gratuite et déplacez-y le dépôt, ou dupliquez-le (fork) dans cette organisation.
Le créateur de pipelines IA et l'agent de correction de CI sont conçus et en accès anticipé. Ils sont désactivés et ne sont pas offerts à la clientèle tant qu'ils ne sont pas activés pour un espace de travail.
Cette page décrit le contrat de permissions demandé. Une permission demandée n'est pas la preuve qu'une inscription réelle de l'application l'a reçue.
Permissions de dépôt demandées
- Metadata : lecture. Prend en charge la configuration de l'application GitHub, la réception signée et l'autorisation des dépôts sélectionnés.
- Actions : lecture et écriture. Prend en charge l'admission des tâches mises en file, les transitions du cycle de vie des tâches, l'historique des exécutions et les journaux de tâches.
- Contents : lecture et écriture. Le créateur de pipelines et l'agent de correction de CI, en accès anticipé, lisent les fichiers du dépôt et écrivent les modifications de flux de travail dans une nouvelle branche.
- Workflows : écriture. Le créateur de pipelines et l'agent de correction de CI, en accès anticipé, modifient les fichiers de flux de travail.
- Pull requests : lecture et écriture. Le créateur de pipelines et l'agent de correction de CI, en accès anticipé, livrent leurs modifications sous forme de demandes de tirage.
- Checks : lecture et écriture. L'agent de correction de CI, en accès anticipé, lit les vérifications échouées qu'on lui demande de corriger.
- Issues : lecture. Demandée pour un contexte d'assistant prévu ; aucune fonctionnalité disponible ne l'utilise.
Permissions d'organisation demandées
- Self-hosted runners : lecture et écriture. La réservation, l'enregistrement JIT et le retrait des exécuteurs de l'organisation utilisent cet accès. Le lien avec une même tâche reste non résolu.
- Members : lecture. La gestion prévue des changements d'adhésion a besoin des identifiants minimaux d'organisation, de membre, d'équipe et de changement d'adhésion.
Portée de l'installation
Pendant l'installation, la clientèle choisit « Only select repositories ». Ce choix limite les permissions de dépôt aux dépôts sélectionnés, et la clientèle peut ajouter ou retirer des dépôts plus tard dans les paramètres d'installation de l'application GitHub.
L'accès aux dépôts sélectionnés ne limite pas les permissions d'organisation distinctes. « Self-hosted runners » et « Members » sont des portées au niveau de l'organisation, demandées aux fins décrites ci-dessus. Runzivo ne demande pas les permissions Administration, Secrets, Variables, Environments, Packages ni Deployments.
Les installations existantes ne reçoivent pas automatiquement une nouvelle permission. Si Runzivo en demande une un jour, GitHub exige que chaque propriétaire d'installation l'approuve avant que Runzivo puisse l'utiliser.
Pourquoi ces permissions sont demandées
Les permissions demandées couvrent le parcours d'exécuteur disponible ainsi que le créateur de pipelines et l'agent de correction de CI en accès anticipé. Runzivo ne demande pas Administration. GitHub accorde avec cette permission un vaste contrôle sur les paramètres du dépôt, la protection des branches, les collaborateurs et les clés de déploiement, ce dont un service d'exécuteurs n'a pas besoin.
Si les permissions demandées changent à l'avenir, GitHub ou la clientèle pourrait exiger une nouvelle approbation. Runzivo ne présumera pas qu'une approbation antérieure vaut pour des changements de permissions ultérieurs.
Écritures et contrôle des flux de travail
Les écritures sur Contents, Workflows et Pull requests permettent au créateur de pipelines et à l'agent de correction de CI de livrer des modifications de flux de travail. Les deux sont en accès anticipé et ne sont pas encore offerts à la clientèle. L'agent de correction de CI ne modifie que des fichiers de CI, ouvre une demande de tirage à partir d'une nouvelle branche, ne pousse jamais vers une branche existante et ne fusionne jamais.
Runzivo enregistre les exécuteurs au niveau de l'organisation avec la permission « Self-hosted runners ». Comme elle ne détient pas Administration, elle ne peut pas modifier les paramètres du dépôt, la protection des branches, les collaborateurs ni les clés de déploiement.
Toute future écriture initiée par un client exige une action authentifiée du client, des vérifications du locataire et du dépôt sélectionné, et un jeton d'installation limité à l'opération, restreint au dépôt et aux permissions là où GitHub permet la restriction. Les écritures dans le dépôt se limitent à une branche et à une demande de tirage dans le dépôt autorisé, sans contournement de la protection des branches ni des ensembles de règles. Une seule exception : le propriétaire d'un espace de travail peut autoriser le créateur de pipelines à valider directement un fichier de flux de travail, toujours sous réserve de la protection des branches.
Un exécuteur exécute le flux de travail qu'un client sélectionne dans GitHub Actions. Les étapes d'un flux de travail peuvent lire ou modifier les données du dépôt, accéder aux secrets que GitHub rend disponibles à cette tâche et déclencher des actions avec les identifiants propres au flux de travail. Les permissions de l'application n'accordent pas directement l'accès à l'environnement d'une tâche en cours, au jeton de la tâche ni aux secrets Actions stockés. Les secrets présents dans le code, les journaux, les artefacts ou le contenu modifié d'un flux de travail demeurent un risque.
Contrôles et registres de la clientèle
La clientèle contrôle l'accès aux dépôts dans les paramètres d'installation de l'application GitHub en ajoutant ou en retirant des dépôts sélectionnés. Suspendre ou désinstaller l'application arrête les nouvelles demandes d'exécuteur. Un dépôt révoqué ou non sélectionné est refusé par la frontière d'autorisation.
Les corps bruts des webhooks ne sont conservés qu'en mémoire, le temps de vérifier la signature et d'acheminer une livraison. Ils ne sont ni journalisés ni conservés. Les accusés de réception d'événements prévus ne conservent rien. Le traitement actuel des tâches mises en file ne conserve que l'identifiant de livraison, la tâche, l'installation et les identifiants de dépôt, l'action, les étiquettes, la décision d'admission, le motif et l'horodatage. Il ne conserve pas les charges utiles brutes.
La table d'audit des livraisons actuelle n'a aucune purge. Le travail de conservation et de suppression approuvé par le locataire est un bloquant de lancement pour l'intégration et le traitement. Avant d'activer une collecte future, Runzivo doit appliquer la conservation et la suppression approuvées par le locataire aux données de webhooks, d'adhésion, de discussions de demandes de tirage ou de tickets, de métadonnées d'exécution, de journaux et de métriques.
L'avis de confidentialité est une version de travail pour les renseignements sur l'infolettre et l'accès anticipé. Il ne fixe ni durée de conservation ni processus de suppression pour les audits de livraison de l'application GitHub. Cette page indique le traitement actuel des registres de l'application GitHub et le bloquant de lancement ; communiquez avec Runzivo pour toute question sur la version de travail de l'avis.