# Variables runtime

Comment les variables projet deviennent des variables d'environnement Playwright et comment les jobs les utilisent.

Les variables runtime permettent a un projet de fournir des valeurs a une execution Playwright sans les coder en dur dans le script. Elles conviennent aux cles API, IDs de file, IDs projet, noms de tenant, hosts cibles ou flags utilises pendant l'execution.

## Fonctionnement de l'injection

Consultez le schéma ou le tableau sur la page de documentation liée.

Au moment du dispatch, le backend lit `project_variables` pour le projet. Les variables simples sont copiees directement. Les variables secretes sont dechiffrees seulement si l'appelant est autorise a utiliser les variables. Le backend envoie les valeurs resolues au worker dans `env_vars`, avec `secret_env_keys` pour la redaction.

Le worker demarre Playwright avec ces valeurs dans l'environnement du processus enfant. Le script les lit via `process.env`.

```ts
const PROJECT_ID = requiredEnv('HAPPY_PATH_QUEUE_PROJECT_ID');
const QUEUE_ID = requiredEnv('HAPPY_PATH_QUEUE_ID');
const API_KEY = requiredEnv('HAPPY_PATH_QUEUE_API_KEY');

function requiredEnv(name: string) {
  const value = process.env[name]?.trim();
  if (!value) throw new Error(`Missing required runtime variable: ${name}`);
  return value;
}
```

## Contrat cote job

Consultez le schéma ou le tableau sur la page de documentation liée.

Une variable est disponible uniquement dans le processus Node qui lance Playwright. Elle n'est pas automatiquement disponible dans le JavaScript de l'application chargee dans Chromium, Firefox ou WebKit.

Si la page navigateur a besoin de la valeur, transmettez-la explicitement :

```ts
const tenant = requiredEnv('TEST_TENANT');

await page.evaluate((tenantName) => {
  window.localStorage.setItem('tenant', tenantName);
}, tenant);
```

## Noms et prefixes reserves

Les variables du bridge SDK natif utilisent l'espace reserve `BERNOPS_` et sont injectees puis renouvelees par le worker. Les jobs ne doivent pas les definir ni les copier. Consultez la [selection de transport du SDK](/fr/docs/automation-sdk#choose-a-transport).

Les noms utilisent la syntaxe des variables d'environnement : lettres majuscules, chiffres et underscores, sans commencer par un chiffre.

Bons exemples :

- `HAPPY_PATH_QUEUE_API_KEY`
- `HAPPY_PATH_QUEUE_ID`
- `TARGET_TENANT`
- `CHECKOUT_REGION`

N'utilisez pas les noms ou prefixes reserves comme `PATH`, `HOME`, `AB_LOG_URL`, `BERNOPS_*`, `SUPABASE_*`, `NEXT_PUBLIC_*`, `PLAYWRIGHT_*`, `npm_*` ou `npm_config_*`.

## Comportement des secrets

Les secrets sont stockes chiffres et sont write-only dans l'interface. Pendant l'execution, BernOps les dechiffre pour le processus worker, enregistre leurs valeurs dans le redacteur du worker et evite d'exposer la valeur secrete dans les metadonnees d'execution.

**Ce que les utilisateurs peuvent voir**

Les metadonnees d'execution enregistrent les noms de variables resolues, si chaque variable est secrete et sa version. Elles ne stockent pas le plaintext secret.


## Modele de permission

Les executions lancees avec un JWT utilisateur recoivent les variables projet non secretes par defaut. Les secrets sont injectes pour les admins projet seulement si la requete definit explicitement `include_secret_variables: true`. Les executions de jobs enregistres lancees par cle API recoivent automatiquement les secrets quand la cle a `variables:use`, sauf si la requete definit explicitement `include_secret_variables: false`.

C'est important pour l'execution de jobs enregistres depuis la CI. Si le script appelle `requiredEnv('HAPPY_PATH_QUEUE_API_KEY')`, une cle appelante avec `variables:use` recoit ce secret autorise par defaut. Une cle sans `variables:use`, ou une requete qui desactive explicitement les secrets, demarre sans ce secret et le script echoue avec l'erreur de variable manquante.

## Variables d'URL de base

`BASE_URL` et `TARGET_URL` sont speciales. Si la requete d'execution ne fournit pas d'URL de base, BernOps cherche d'abord ces noms dans les variables runtime. Sinon, il utilise `http://localhost:3000`.

Le worker force aussi `BASE_URL` et `TARGET_URL` vers l'URL finale resolue pour que les jobs puissent utiliser l'un ou l'autre nom.

## Diagnostiquer une variable manquante

Quand un job signale `Missing required runtime variable`, verifiez dans cet ordre :

1. La variable existe sur le bon projet.
2. Le nom correspond exactement, underscores inclus.
3. L'appelant peut utiliser les secrets : admin projet pour un JWT, ou `variables:use` pour une cle API.
4. Le nom n'est pas reserve et a ete accepte a l'enregistrement.
5. L'execution utilise le projet attendu, pas un autre projet avec un job similaire.