Bien demarrer

Utilisez ce parcours quand vous démarrez avec un compte vide. BernOps commence au niveau de l'espace de travail, puis chaque ressource d'automatisation se trouve dans un projet.

Créer un espace

Ouvrez Accueil et choisissez Créer un espace de travail. Un espace de travail est le conteneur principal pour vos projets et vos futurs accès en équipe.

Si vous avez déjà un espace, ouvrez-le depuis la section Vos espaces de travail. La page de l'espace montre la santé globale des exécutions et le portefeuille de projets de cet espace.

Connecter un worker

Cliquez sur l'engrenage du worker ou sur Espace de travail > Workers pour ouvrir la page Workers. Une liste vide est normale avant l'inscription ; les outils de démonstration locale peuvent déjà avoir provisionné leur propre worker. Aucun projet n'a besoin d'être sélectionné pour ajouter un worker.

Sur un hôte Docker Linux/amd64 pris en charge, installez le bootstrap privé approuvé par l'opérateur en suivant le guide des prérequis et d'installation de la CLI. Aucun téléchargement public ni nom d'installation npm n'est pris en charge. Puis lancez :

bernops setup

Choisissez 3 (worker d'automatisation), ou 4 (les deux) pour ajouter aussi un agent de code personnel. Le menu propose par défaut 1 (authentification plateforme uniquement), qui n'installe aucun worker. L'assistant gère la connexion plateforme, vérifie Docker et obtient une version worker immuable signée avec le SDK privé intégré, sans checkout source ni build Docker manuel. Il vérifie la disponibilité SDK/navigateur avant de demander l'approbation distincte de l'espace. Comparez l'empreinte de l'ordinateur, choisissez l'espace comme propriétaire ou administrateur et approuvez l'exécution de ses tâches.

La CLI sépare la session plateforme de l'identifiant worker limité à l'espace ; elle ne transmet jamais l'OAuth personnel au conteneur. Attendez que l'assistant indique le worker prêt avec une connexion confirmée, puis vérifiez-le sur la page Workers. Un conteneur actif seul ne suffit pas. Le nom est celui conservé par l'assistant, sinon le nom d'hôte normalisé ; --worker-name est facultatif.

Aucune commande préalable bernops auth login n'est requise : elle effectue uniquement l'authentification et n'inscrit jamais d'hôte ni de worker. Choisissez l'agent dans CLI d'agent de code pour une approbation hôte distincte, la connexion Codex si nécessaire, l'accès au repository et la vérification du service utilisateur connecté. Le choix worker seul ne configure aucun de ces composants agent.

L'assistant utilise l'identité enregistrée, puis son journal, puis la cible du bootstrap, sauf cible explicite. En développement local, ./dev.sh install-cli active un bootstrap à cible locale, puis utilisez simplement bernops setup ; --target local reste disponible. Cela n'installe pas NVM. Consultez Développement local uniquement pour les prérequis. Linux Secret Service natif est le stockage local/cloud par défaut ; --credential-store file accepte explicitement un stockage non chiffré pour une nouvelle identité. Pour approuver à distance, utilisez --no-browser, pas --headless réservé à l'agent.

Créer un projet

Dans un espace de travail, créez un projet pour l'application ou le périmètre opérationnel à automatiser. Les projets délimitent les jobs, exécutions, variables, files, déclencheurs et clés API.

Utilisez un projet par application ou frontière d'environnement. Les clés API et variables runtime restent ainsi limitées au plus petit périmètre utile.

Ajouter un job Playwright

Ouvrez le tableau de bord du projet et choisissez Nouveau job. Collez une spec Playwright qui peut s'exécuter depuis un worker sans dépendre d'un état de navigateur local.

Commencez avec des validations explicites et des étapes lisibles :

import { test, expect } from "@playwright/test";
 
test("la page d'accueil repond", async ({ page }) => {
  await test.step("ouvrir l'application", async () => {
    await page.goto(process.env.BASE_URL ?? "https://example.com");
  });
 
  await test.step("verifier le chargement", async () => {
    await expect(page.locator("body")).toBeVisible();
  });
});

Utilisez les variables runtime quand des valeurs comme BASE_URL, des identifiants ou des IDs tenant doivent changer par projet.

Exécuter et inspecter

Lancez le job enregistré depuis le tableau de bord du projet. BernOps envoie l'exécution à un worker connecté, enregistre les logs et les étapes, puis fournit un lien vers la page de détail de l'exécution.

Si le run reste pending, vérifiez qu'un worker compatible est connecté à cet espace et que les limites de concurrence permettent son démarrage. Créer un job ne provisionne pas automatiquement un worker.

Utilisez la page de détail de l'exécution pour inspecter :

• Le statut final et la durée.
• La chronologie des étapes et les logs.
• Les captures, traces et pièces jointes quand le job en produit.
• Les signaux réseau et console pour les échecs d'exécution dans le navigateur.

Automatiser ensuite

Après une première exécution manuelle valide, choisissez le chemin d'automatisation qui correspond à votre flux :

• Lisez Jobs Playwright pour améliorer la structure des jobs et les rapports.
• Connectez un ordinateur avec la CLI d'agent de code pour les sessions Pi appartenant au créateur.
• Créez des clés API pour CI, runners externes ou agents de style MCP.
• Utilisez les files quand des jobs doivent produire et consommer des unités de travail.
• Utilisez la Référence API pour les schémas d'endpoints et les requêtes d'essai.