# Workers et execution

Connexion worker, workspaces temporaires, config Playwright generee, logs, etapes et echecs.

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](/fr/docs/workers-and-pool#worker-setup) : 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`](/fr/docs/workers-and-pool#headless-and-advanced) 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](/fr/docs/workers-and-pool#worker-management) 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: 1`
- `retries: 0`
- `trace: '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](/fr/docs/automation-sdk) 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](/fr/docs/workers-and-pool#setup-recovery) 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.

**Pourquoi `test.step` est important**

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](/fr/docs/workers-and-pool#current-limitations).