Vue d'ensemble plateforme
Le modele technique des projets, workers, orchestration et frontieres.
Sur cette page
BernOps est une plateforme d'automatisation limitee par projet. Un projet represente une application ou une surface operationnelle, et chaque job, execution, trigger, file, cle API, variable et job externe appartient a ce perimetre projet.
Modele mental
Le produit a trois plans :
| Plan | Role | Code principal |
|---|---|---|
| Plan de controle | Interface navigateur pour espaces de travail, projets, jobs, files, variables, executions et cles. | frontend |
| Plan d'orchestration | API REST Go, controles d'auth, dispatch des executions, gateway WebSocket worker, ecritures base. | backend |
| Plan d'execution | Worker Node qui recoit les payloads d'execution et lance Playwright. | worker |
Le frontend est une application Next statique. Il ne possede pas de routes API. Le code navigateur appelle le backend Go via lib/api-client.ts, et l'authentification est geree par Supabase PKCE dans le navigateur.
Hierarchie des ressources
La hierarchie est volontairement stricte :
- Les espaces de travail contiennent des projets.
- Les projets contiennent jobs, variables, files, triggers, executions, jobs et cles API.
- Les cles API sont limitees a un projet et ne traversent pas vers un autre projet.
- L'execution worker est assignee par execution, pas par projet.
La plupart des automatisations n'ont donc besoin que de trois valeurs : un ID projet, l'ID de la ressource a manipuler et un bearer token avec le scope requis.
Chemin d'execution
Requete d'execution
Un utilisateur, une cle API, un declencheur ou un job enregistre lance une execution.
Dispatch
Le backend enregistre l'execution et reserve un worker connecte.
Espace temporaire
Le worker ecrit les fichiers de test et une configuration Playwright generee.
Telemetrie
Logs, steps, traces, captures et resultats reviennent vers BernOps.
Quand une execution demarre, le backend cree une ligne test_executions, resout les variables runtime du projet, choisit un worker disponible et envoie un message WebSocket run_tests. Le worker ecrit les fichiers Playwright dans un dossier temporaire, genere une configuration Playwright, puis lance npx playwright test.
Les resultats reviennent sous forme de logs et d'etapes structures. Le backend les persiste pour que la page de detail affiche timeline, console, reseau, captures, pieces jointes et statut final.
Principaux d'authentification
BernOps reconnait deux types d'appelants :
| Principal | Cas ideal | Notes |
|---|---|---|
| JWT utilisateur | Actions de gestion authentifiees dans le navigateur. | Herite du role espace de travail/projet de l'utilisateur connecte. |
| Cle API projet | CI, runners externes, workers de file, execution de jobs enregistres, ingestion. | Limitee a un projet et a une liste de scopes. |
Utilisez un JWT utilisateur pour les actions admin comme creer des projets ou gerer les cles. Utilisez une cle API projet quand une machine ou un systeme externe a besoin d'un acces repetable.
Frontieres techniques
Le frontend est deployee en export statique. Il ne faut pas attendre des routes frontend qu'elles executent du code serveur, lisent des cookies cote serveur ou exposent des handlers app/api. Le runtime doit passer par le backend Go.
La source de verite des routes backend est backend/main.go. Les payloads du protocole worker sont miroirs entre backend/protocol et worker/src/protocol/types.ts; quand les champs changent, les deux cotes doivent rester synchronises.
Suite conseillee
- Lisez Jobs Playwright pour comprendre comment ecrire les jobs.
- Lisez Variables runtime pour passer des valeurs projet aux executions.
- Lisez Cles API et scopes avant de donner acces a des systemes externes.
- Consultez Utilisation efficace des outils agent pour la découverte selon la version, la sélection compacte, les lots sûrs et la vérification de préparation.
- Utilisez la Reference API separee pour les chemins, schemas de requete et outils try-it.