GitHub lance Evergreen pour automatiser la révision d’accès et l’archivage des dépôts

Présentation

Evergreen est une GitHub App interne conçue pour maintenir la propreté d’une organisation partagée. Elle cible deux problèmes récurrents : la révision trimestrielle des collaborateurs externes et la détection des dépôts inactifs qui doivent être archivés. Le principe « fail secure » garantit que, en l’absence de réponse, les accès sont révoqués, tandis que la règle « never destroy anything » empêche toute suppression définitive de dépôt.

Architecture et mécanismes

Le cœur d’Evergreen est un petit serveur webhook écrit en Go et exécuté dans un conteneur Docker. La logique d’automatisation repose exclusivement sur des fonctionnalités natives de GitHub : une GitHub App, des GitHub Actions planifiées, des événements repository_dispatch, des webhooks d’issues, des propriétés personnalisées et des fichiers stockés dans un dépôt de contrôle. Quatre workflows GitHub Actions, déclenchés chaque trimestre, envoient des repository_dispatch qui réveillent l’application.

Chaque dépôt possède un fichier d’état JSON placé sous state/repos/<repo_id>.json dans le dépôt contrôleur. Ce fichier consigne le snapshot des collaborateurs, la date d’ouverture de la révision, la date limite, les décisions prises et les actions exécutées. Parce que l’état réside dans Git, le git log fournit un audit trail complet sans base de données supplémentaire.

Gestion des accès et archivage

Lorsqu’une révision démarre, Evergreen crée automatiquement une issue de checklist dans le dépôt concerné. Les responsables cochent les cases des collaborateurs à conserver, ferment l’issue, puis le webhook issues.closed déclenche la révocation des comptes non cochés. Si un utilisateur non autorisé ferme l’issue, l’application la rouvre et ajoute un commentaire explicatif, assurant que seules les personnes désignées (les « Hubbers ») peuvent valider les changements.

Pour l’archivage, les dépôts sans activité humaine pendant une période configurable sont marqués, reçoivent un commentaire de rappel, puis, après le délai, sont archivés. L’archivage conserve le dépôt en lecture seule et reste réversible, conformément au principe de non‑destruction.

Déploiement et limites

Le lancement dans une organisation de plus de 1 400 Hubbers a été précédé d’un mode DRY_RUN qui consigne chaque modification sans l’appliquer, permettant de valider les décisions avant le premier cycle réel. Les logs structurés, envoyés à Splunk, ont permis d’identifier des cas limites : listes de collaborateurs vides, permissions atypiques ou dépôts avec les issues désactivées. Evergreen ne supprime jamais de dépôts et ne crée pas de nouvelles entités, ce qui limite les risques de perte de données, mais dépend entièrement de la disponibilité des API GitHub ; des erreurs transitoires entraînent un état « pending » et un nouveau retry lors du cycle suivant.