Workers et execution
Connexion worker, workspaces temporaires, config Playwright generee, logs, etapes et echecs.
Sur cette page
Les workers fournissent la capacité d'exécution des runs BernOps. Le backend gère l'ordonnancement et la persistance ; les workers gèrent le processus navigateur local et l'exécution Playwright.
Connexion du worker
Un worker se connecte au WebSocket backend ${ORCHESTRATOR_URL}/ws/worker avec son WORKER_ID inscrit, son nom d'affichage et son identifiant d'accès individuel lié à un espace de travail. Il n'existe pas de secret commun au pool, et un hôte personnel d'agent de code n'ajoute pas de capacité worker.
Pour un nouveau worker, suivez Connecter un worker : installez le bootstrap privé approuvé, puis lancez bernops setup et choisissez 3 (worker d'automatisation) ou 4 (les deux). Le menu propose par défaut l'authentification seule, qui n'installe aucun worker. L'assistant gère la connexion plateforme partagée, vérifie une version worker immuable signée compatible SDK et la disponibilité réelle SDK/navigateur, puis demande l'approbation distincte de l'espace. Aucun téléchargement public, build depuis un checkout, création manuelle d'identifiant ou bernops auth login préalable n'est requis. La connexion plateforme seule n'inscrit jamais d'hôte ni de worker et sa session OAuth n'est pas transmise au conteneur. L'assistant exige une connexion confirmée du worker, à l'état prêt ou occupé, pas seulement un conteneur actif ou une image vérifiée.
La cible suit l'identité enregistrée, puis le journal, puis le bootstrap, sauf choix explicite. En développement local, ./dev.sh install-cli active le bootstrap à cible locale, puis lancez simplement bernops setup ; --target local explicite reste disponible. Secret Service natif est le stockage des identifiants plateforme par défaut en local/cloud ; le fichier est un choix explicite non chiffré pour une nouvelle identité. Utilisez --no-browser pour approuver à distance. L'alternative de bas niveau bernops worker setup est différente : cloud par défaut, aucune authentification plateforme de CLI et un parcours source/image contrôlé par l'opérateur, pas la configuration unifiée par versions signées.
Le backend suit les workers connectés et réserve un worker compatible de l'espace du run quand la capacité le permet. Sans worker correspondant ou capacité de scope disponible, l'exécution reste pending jusqu'à son affectation. Consultez l'inventaire via l'engrenage du worker ou Espace de travail > Workers, et les commandes de gestion locale pour le statut, le démarrage, l'arrêt, le redémarrage et les logs du superviseur.
Payload reçu par le worker
Pour les exécutions Playwright, le backend envoie un RunTestsPayload contenant :
| Champ | Rôle |
|---|---|
test_files | Noms et code source des fichiers à écrire dans un dossier temporaire. |
base_url | URL de base finale utilisée par la configuration Playwright générée. |
env_vars | Variables runtime projet plus variables d'exécution forcées. |
secret_env_keys | Noms des variables dont les valeurs doivent être masquées. |
project_id | Identifiant projet exposé sous BERNOPS_PROJECT_ID. |
Workspace temporaire
Le worker crée un dossier temporaire, écrit chaque fichier de test avec un nom de base sécurisé, lie node_modules et génère playwright.config.js. La configuration générée définit :
workers: 1retries: 0trace: 'on'screenshot: 'on'video: 'retain-on-failure'- arguments Chromium adaptés à Docker
Le worker lance ensuite npx playwright test --config=<temp config> depuis la racine du worker.
Construction de l'environnement
L'environnement du processus enfant est volontairement filtré. Le worker conserve une petite liste de variables autorisées de son propre environnement, ajoute les variables autorisées du payload et force des variables BernOps comme AB_LOG_URL, BERNOPS_RUN_ID et BERNOPS_PROJECT_ID.
Les noms de variables du payload doivent figurer dans la liste autorisée du worker. Les noms et préfixes réservés sont bloqués pour éviter qu'une variable projet remplace des valeurs critiques du processus.
Logs, étapes et traces
Le SDK d'automatisation privé peut envoyer logs structurés, étapes imbriquées, métriques, progression et pièces jointes acquittées via le bridge local authentifié, tout en laissant le worker propriétaire du cycle de vie.
La configuration unifiée d'un nouveau worker obtient une version signée compatible SDK avec l'artéfact privé exact déjà intégré et exige native_bridge_v1. N'installez et ne montez pas le SDK séparément dans un job enregistré. Les anciens workers ne sont pas actualisés silencieusement ; le seul remplacement de l'image n'étend pas les capacités approuvées de leur identifiant. Consultez la reprise de configuration pour worker_sdk_upgrade_required et les workers remplaçants approuvés séparément.
BernOps installe un reporter Playwright personnalisé. La sortie du reporter est émise avec un préfixe structuré, analysée par le worker, expurgée des secrets puis renvoyée au backend sous forme d'étapes d'exécution.
Stdout et stderr bruts sont aussi envoyés comme logs d'exécution. Après la fin du processus, le worker analyse results.json, examine les traces et ajoute un contexte d'échec utile.
Le reporter voit les étapes Playwright. Des noms d'étapes clairs deviennent des chronologies lisibles dans les exécutions, plus faciles à déboguer que des logs bruts seuls.
Gestion des échecs
Le worker signale un échec quand Playwright termine avec un code non nul, quand l'analyse des résultats échoue ou quand la préparation de l'exécution lève une erreur. Le message est expurgé des secrets avant d'être envoyé.
Si aucun worker n'est connecté, l'exécution reste pending dans le backend avant qu'un payload atteigne un worker. Les échecs côté backend passent toujours le run en error.
La retransmission des résultats terminaux utilise une file d'envoi en mémoire ; elle peut reprendre après une interruption de connexion si le processus worker survit, pas après sa perte. L'inscription du worker persiste séparément. L'ordonnancement exige toujours une seule passerelle active ; consultez les limites actuelles du pool.