Skip to content

FR Reference Variables D Environnement

Jump to bottom
wanoo edited this page Oct 23, 2026 · 1 revision

Variables d’environnement

English · Type : référence · Public : auteur, administrateur, contributeur · Contexte : dépôt du moteur, projet créé, Studio hébergé, Reality Bridge · Statut : prête · S'applique depuis : 4.5.0

Toutes les variables d’environnement que lit quest-n-click, et celles que Clever Cloud et ses add-ons donnent au Studio hébergé. Chacune a sa propre section : liez-la sous la forme reference.environment-variables.md#studio-session-key (le nom en minuscules, _ écrit -).

Comment lire cette page

  • Origine dit qui pose la variable : vous (le code la lit), la construction, la plateforme (Clever Cloud, GitHub Actions, npm, le système), un add-on Clever Cloud, ou un workflow de CI. Une variable qu’une commande de quest-n-click pose elle-même le dit : vous ne la posez pas.
  • Secret : lue une fois au démarrage du Studio Server, puis retirée de son environnement, pour qu’aucun processus enfant n’en hérite ; jamais écrite dans un journal. Chaque secret peut aussi venir d’un fichier : STUDIO_SESSION_KEY_FILE=/run/secrets/session lit la clé dans ce fichier, lisible par son seul propriétaire (mode 0600) sous Linux et macOS. Le fichier passe avant la variable.
  • Lue par renvoie aux fichiers du code qui la lisent, dans la version documentée.
  • Sur Clever Cloud, posez une variable avec clever env set NOM valeur sur la bonne application ; clever env affiche en entier les valeurs sur plusieurs lignes, filtrez sa sortie avant de la partager.

Limite · generated-scope Les sections qui suivent sont générées depuis wiki/data/env.json et depuis le code : ce que lisent process.env, import.meta.env, os.environ en Python, les scripts shell de ops/ et clevercloud/, et les workflows de .github/workflows/ (leurs blocs env:, ${{ env.X }}, $GITHUB_ENV et leur shell). Une variable lue seulement par une bibliothèque tierce (les OTEL_* standard, NODE_OPTIONS, PG*) n’y figure pas.

Studio Server (Studio hébergé)

Ce que lit l’application studio-server : sur Clever Cloud, posez-les avec clever env set sur l’application studio, jamais sur le worker. Chaque secret peut venir d’un fichier (<NOM>_FILE, mode 0600), et quitte l’environnement une fois lu.

GIT_DIR

Pas prise dans votre environnement : le Studio Server construit l’environnement de ses propres commandes git, y pose GIT_DIR sur le dépôt du jeu, et la retire pour git init. Une GIT_DIR à vous ne leur parvient jamais.

STUDIO_BACKUP_CRON

1 active la sauvegarde quotidienne vers le bucket que clevercloud/cron.json lance à 03:17 UTC (ops/studio/backup-cron.sh). À poser sur l’application studio seulement, jamais sur le worker.

STUDIO_BACKUP_KEEP

Le nombre de sauvegardes que la sauvegarde quotidienne garde dans le bucket (--keep) ; 14 quand elle n’est pas posée.

STUDIO_CONFIG

Le chemin du fichier de configuration, lu quand aucun --config <fichier> n’est donné. Il passe avant STUDIO_CONFIG_JSON.

STUDIO_CONFIG_JSON

Toute la configuration en JSON sur une ligne, pour une plateforme qui ne donne pas de fichier (Clever Cloud). Elle ne contient aucun secret ; le chargeur refuse une clé inconnue.

STUDIO_DATABASE_URL

L’URI de connexion PostgreSQL (store.kind: postgres). Sur Clever Cloud, ne la posez pas : la variable POSTGRESQL_ADDON_URI de l’add-on lié est lue à sa place. Pour un exercice de restauration, faites-la pointer vers la base vide de l’exercice, jamais vers la production.

  • Origine : vous la posez ; le code la lit.
  • Secret : oui, lue une fois au démarrage, puis retirée de l’environnement ; jamais journalisée.
  • Depuis un fichier : STUDIO_DATABASE_URL_FILE nomme un fichier où la lire à la place (mode 0600 sous Linux et macOS).
  • Lue par : studio-server/src/server/config.ts.

STUDIO_GIT_KEY

Facultative (4.2.3) : la clé de déploiement SSH du dépôt Git du jeu (git.remote). Inutile pour un dépôt public en https.

  • Origine : vous la posez ; le code la lit.
  • Secret : oui, lue une fois au démarrage, puis retirée de l’environnement ; jamais journalisée.
  • Depuis un fichier : STUDIO_GIT_KEY_FILE nomme un fichier où la lire à la place (mode 0600 sous Linux et macOS).
  • Lue par : studio-server/src/server/config.ts.

STUDIO_METRICS_TOKEN

Facultative (4.2.3) : le jeton bearer de GET /metrics, 32 caractères ou plus. Sans elle, la route /metrics n’existe pas (404).

  • Origine : vous la posez ; le code la lit.
  • Secret : oui, lue une fois au démarrage, puis retirée de l’environnement ; jamais journalisée.
  • Depuis un fichier : STUDIO_METRICS_TOKEN_FILE nomme un fichier où la lire à la place (mode 0600 sous Linux et macOS).
  • Lue par : studio-server/src/server/config.ts.

STUDIO_OIDC_CLIENT_SECRET

Le secret du fournisseur OpenID pour le client studio. Obligatoire quand la configuration a oidc.

  • Origine : vous la posez ; le code la lit.
  • Secret : oui, lue une fois au démarrage, puis retirée de l’environnement ; jamais journalisée.
  • Depuis un fichier : STUDIO_OIDC_CLIENT_SECRET_FILE nomme un fichier où la lire à la place (mode 0600 sous Linux et macOS).
  • Lue par : studio-server/src/server/config.ts.

STUDIO_S3_KEY_ID

L’identifiant de clé d’accès S3 (Cellar) du bucket (blobs.kind: s3). Sur Clever Cloud, CELLAR_ADDON_KEY_ID de l’add-on est lue quand elle n’est pas posée.

  • Origine : vous la posez ; le code la lit.
  • Secret : oui, lue une fois au démarrage, puis retirée de l’environnement ; jamais journalisée.
  • Depuis un fichier : STUDIO_S3_KEY_ID_FILE nomme un fichier où la lire à la place (mode 0600 sous Linux et macOS).
  • Lue par : studio-server/src/server/config.ts.

STUDIO_S3_KEY_SECRET

La clé secrète S3 (Cellar) du bucket. Sur Clever Cloud, CELLAR_ADDON_KEY_SECRET de l’add-on est lue quand elle n’est pas posée.

  • Origine : vous la posez ; le code la lit.
  • Secret : oui, lue une fois au démarrage, puis retirée de l’environnement ; jamais journalisée.
  • Depuis un fichier : STUDIO_S3_KEY_SECRET_FILE nomme un fichier où la lire à la place (mode 0600 sous Linux et macOS).
  • Lue par : studio-server/src/server/config.ts.

STUDIO_SESSION_KEY

Les clés qui scellent les cookies de session des membres : une clé, ou plusieurs séparées par des virgules, chacune de 32 caractères ou plus (openssl rand -base64 48). La première scelle ; toutes celles de la liste ouvrent. Pour la faire tourner, mettez la nouvelle clé en tête et gardez l’ancienne dans la liste jusqu’à l’expiration des sessions qu’elle a scellées ; retirer une clé déconnecte les sessions scellées avec elle. Obligatoire avec oidc.

  • Origine : vous la posez ; le code la lit.
  • Secret : oui, lue une fois au démarrage, puis retirée de l’environnement ; jamais journalisée.
  • Depuis un fichier : STUDIO_SESSION_KEY_FILE nomme un fichier où la lire à la place (mode 0600 sous Linux et macOS).
  • Lue par : studio-server/src/server/config.ts.

STUDIO_WORKER_KEY

La clé privée Ed25519 (PEM) qui signe les jobs envoyés au worker ; les retours à la ligne peuvent s’écrire \n. Produite par npm run studio-server -- worker-keys --out <dossier>. Obligatoire avec un worker.

  • Origine : vous la posez ; le code la lit.
  • Secret : oui, lue une fois au démarrage, puis retirée de l’environnement ; jamais journalisée.
  • Depuis un fichier : STUDIO_WORKER_KEY_FILE nomme un fichier où la lire à la place (mode 0600 sous Linux et macOS).
  • Lue par : studio-server/src/server/config.ts.

WEB_SCUMM_STUDIO_CLIENT

Le dossier de la page du Studio construite que le serveur sert, quand la configuration n’a pas de clientDir ; .cache/studio-client à côté du moteur par défaut. Le lanceur de l’archive de publication la pose.

Worker du Studio

Ce que lit le worker de traitement (npm run studio-worker). Il ne détient aucun secret : seulement la clé publique qui vérifie les jobs que le Studio signe.

WORKER_INSTANCE

Le nom du seul Studio dont ce worker exécute les jobs : le même que worker.instance dans la configuration du Studio.

WORKER_PUBLIC_KEY

La clé publique Ed25519 (PEM) qui vérifie les jobs signés du Studio : le contenu de studio-worker.pub.

WORKER_PUBLIC_KEY_FILE

Un fichier qui contient la clé publique, lu à la place de WORKER_PUBLIC_KEY quand elle est posée.

WORKER_PYTHON_PATH

L’endroit où le hook de construction a installé les paquets Python des outils d’images ; .python dans le dossier du worker quand elle n’est pas posée.

Posées par Clever Cloud et ses add-ons

Clever Cloud les donne à une application, ou les lit lui-même pour la construire et la lancer. Les variables d’un add-on n’arrivent à l’application studio que si l’add-on lui est lié.

APP_FOLDER

À ne pas poser : les deux applications se construisent depuis la racine du dépôt. Une application qui a contenu un autre projet peut encore en avoir une (clever env rm APP_FOLDER).

  • Origine : posée par vous ; Clever Cloud la lit.
  • Lue par : aucun fichier du code ; la plateforme la lit.

APP_HOME

Le dossier de l’application sur l’instance ; la sauvegarde quotidienne s’y lance (cd "$APP_HOME" dans une session clever ssh aussi).

CC_HEALTH_CHECK_PATH

Le chemin que Clever Cloud sonde avant d’envoyer du trafic à une nouvelle instance : /startz sur l’application studio.

  • Origine : posée par vous ; Clever Cloud la lit.
  • Lue par : aucun fichier du code ; la plateforme la lit.

CC_NODE_DEV_DEPENDENCIES

À poser à install sur les deux applications : le serveur tourne depuis le dépôt avec tsx, une dépendance de développement.

  • Origine : posée par vous ; Clever Cloud la lit.
  • Lue par : aucun fichier du code ; la plateforme la lit.

CC_POST_BUILD_HOOK

Une commande que Clever Cloud lance après la construction : npm run studio-client sur l’application studio ; celle du worker installe les paquets Python de ops/studio/worker-requirements.lock.

  • Origine : posée par vous ; Clever Cloud la lit.
  • Lue par : aucun fichier du code ; la plateforme la lit.

CC_RUN_COMMAND

La commande qui lance l’application : npm run studio-server -- serve sur l’application studio, npm run studio-worker sur le worker.

  • Origine : posée par vous ; Clever Cloud la lit.
  • Lue par : aucun fichier du code ; la plateforme la lit.

CELLAR_ADDON_KEY_ID

L’identifiant de clé de l’add-on Cellar, lu quand STUDIO_S3_KEY_ID n’est pas posée.

  • Origine : injectée par l’add-on Cellar de Clever Cloud.
  • Secret : oui, lue une fois au démarrage, puis retirée de l’environnement ; jamais journalisée.
  • Lue à la place de STUDIO_S3_KEY_ID quand STUDIO_S3_KEY_ID n’est pas posée.
  • Lue par : studio-server/src/server/config.ts.

CELLAR_ADDON_KEY_SECRET

La clé secrète de l’add-on Cellar, lue quand STUDIO_S3_KEY_SECRET n’est pas posée.

  • Origine : injectée par l’add-on Cellar de Clever Cloud.
  • Secret : oui, lue une fois au démarrage, puis retirée de l’environnement ; jamais journalisée.
  • Lue à la place de STUDIO_S3_KEY_SECRET quand STUDIO_S3_KEY_SECRET n’est pas posée.
  • Lue par : studio-server/src/server/config.ts.

INSTANCE_NUMBER

Le numéro de l’instance de l’application. La sauvegarde quotidienne ne tourne que sur l’instance 0, pour que deux instances ne sauvegardent pas toutes les deux.

PORT

Le port d’écoute. Clever Cloud la donne aux applications studio et worker ; ailleurs, 8080 quand elle n’est pas posée. Un port dans la configuration du Studio passe avant.

POSTGRESQL_ADDON_URI

L’URI de connexion de l’add-on PostgreSQL. Le Studio Server la lit quand STUDIO_DATABASE_URL n’est pas posée.

  • Origine : injectée par l’add-on PostgreSQL de Clever Cloud.
  • Secret : oui, lue une fois au démarrage, puis retirée de l’environnement ; jamais journalisée.
  • Lue à la place de STUDIO_DATABASE_URL quand STUDIO_DATABASE_URL n’est pas posée.
  • Lue par : studio-server/src/server/config.ts.

ROOT

Le dossier de l’application, utilisé par clevercloud/cron.json (les crons veulent des chemins absolus) et par le script de sauvegarde quand APP_HOME manque.

Moteur, Studio local et outils

Lues par les commandes du moteur, le Studio local et son serveur MCP, dans le dépôt du moteur ou dans un projet créé.

ASSETS_DIR

Le dossier des images et sons construits livrés, à la place de public/assets (les fichiers propres à une fixture de test).

  • Origine : vous la posez ; le code la lit.
  • Lue par : tools/game.ts.

DIST_DIR

Le dossier construit que mesure npm run weight ; dist quand elle n’est pas posée.

FURNACE_BIN

Le chemin de l’exécutable Furnace avec lequel la chaîne audio fait son rendu, quand il n’est pas là où python -m mdpipe setup l’a mis.

GAME

Le jeu de games/ sur lequel travaillent les commandes du dépôt du moteur (GAME=reference npm run validate). Sans elle, le dernier jeu choisi (npm run game -- <id>), puis config.game de package.json, puis demo.

GAME_DIR

Le dossier de jeu sur lequel travaillent les outils, n’importe où sur le disque. Posée, c’est toujours le dossier lu, quoi que dise GAME, à la place de games/<GAME> ou du game/ d’un projet créé ; sans GAME, l’identifiant du jeu est le nom du dossier.

PROOF_CACHE

0 coupe le cache des résultats du solveur pour une exécution (comme --no-cache).

PROOF_CACHE_DIR

L’endroit où vit le cache des résultats du solveur ; .cache/proofs du projet quand elle n’est pas posée.

PYTHON

L’interpréteur Python que lance quest-n-click assets ; python3 quand elle n’est pas posée.

WEB_SCUMM_ALLOW_CUSTOM_PROVIDER

1 permet à l’Assistant du Studio d’appeler une URL de fournisseur que vous saisissez vous-même ; refusé sinon.

WEB_SCUMM_DEV_URL

Le serveur de développement qu’ouvre l’outil MCP screenshot ; http://localhost:5173/ quand elle n’est pas posée.

WEB_SCUMM_LAN

1 fait écouter le serveur de développement et le Studio local sur le réseau local, derrière un jeton. npm run dev:lan et studio:lan la posent.

WEB_SCUMM_PROJECT

Le projet créé sur lequel travaillent les outils du moteur. La commande quest-n-click la pose sur le dossier où elle tourne ; vous ne la posez pas vous-même.

WEB_SCUMM_STUDIO_HOSTS

Les noms d’hôte auxquels répond le Studio local en mode réseau local, séparés par des virgules ; tout autre Host est refusé. studio:lan la pose d’après les adresses de la machine.

WEB_SCUMM_STUDIO_TOKEN

Le jeton que demande le Studio local en mode réseau local. studio:lan en tire un au hasard sauf si vous la posez.

Construction des pages

Lues quand Vite construit le jeu, le Studio ou une prévisualisation. Les scripts npm posent la plupart d’entre elles ; VITE_*, BASE_URL et DEV finissent dans la page construite.

BASE_PATH

Le sous-chemin sous lequel le jeu est servi (/<dépôt>/ sur GitHub Pages) ; / quand elle n’est pas posée.

BASE_URL

La base pour laquelle la page a été construite, tirée de BASE_PATH.

DEV

Vrai sous le serveur de développement (npm run dev), faux dans une version construite.

  • Origine : posée par Vite (lue à la construction de la page ou du paquet).
  • Lue par : src/main.ts.

STUDIO

1 construit ou sert les pages du Studio à côté du jeu (npm run studio, le Studio de démonstration).

STUDIO_CLIENT

1 ne construit que la page du Studio hébergé (npm run studio-client).

  • Origine : posée par npm run studio-client (lue à la construction de la page ou du paquet).
  • Lue par : vite.config.ts.

VITE_STUDIO_DEMO

1 construit le Studio de démonstration, qui tourne dans le navigateur sans serveur (npm run build:studio-demo).

VITE_STUDIO_HOSTED

1 construit le Studio pour un Studio Server (npm run studio-client).

  • Origine : posée par npm run studio-client (lue à la construction de la page ou du paquet).
  • Lue par : src/studio/main.ts.

VITE_STUDIO_PREVIEW

1 dans la prévisualisation d’une révision, que le worker construit avec les outils d’édition ; 0 dans une version publiée.

Reality Bridge

Lues par quest-n-click-bridge (ou npm run bridge dans le dépôt du moteur).

BRIDGE_STORE

Le stockage du Bridge quand aucun --store= n’est donné : jsonl, sqlite, sqlite:<fichier> ou une URL postgres://. Elle passe avant store de config.json.

BRIDGE_STORE_FILE

Un fichier qui contient l’URL du stockage, lu quand BRIDGE_STORE est vide, pour qu’un mot de passe de base soit monté en fichier secret et n’apparaisse jamais dans une liste de processus.

OTEL_EXPORTER_OTLP_ENDPOINT

L’adresse où le Bridge exporte ses mesures en OTLP, quand @opentelemetry/sdk-node est installé à côté ; rien n’est exporté sinon. Le SDK lit lui-même les autres variables OTEL_* standard.

Tests, CI et versions du moteur

Lues seulement par les scripts de test, de CI et de publication du dépôt du moteur. Un projet créé n’en a jamais besoin.

BRIDGE_PG_MODULE

Le module pg qu’importe tools/backup-memory.ts, quand ce n’est pas celui du dépôt.

BRIDGE_PG_URL

Une URL PostgreSQL sur laquelle les tests font tourner le stockage du Bridge et les mutations ; ces tests sont sautés sans elle.

CONSUMER_PG_URL

Une URL PostgreSQL sur laquelle npm run external-consumer fait aussi tourner le Bridge installé.

E2E_BROWSER

Le navigateur dans lequel tourne un test de bout en bout (chromium, firefox, webkit) ; Chromium quand elle n’est pas posée.

E2E_CPU

Un facteur de ralentissement du processeur pour les tests de bout en bout sous Chromium (4 tourne quatre fois plus lentement).

E2E_DEBUG

Toute valeur fait afficher au test de bout en bout du Studio hébergé ce qu’il fait.

E2E_INPUT

keyboard joue la soluce de bout en bout au clavier au lieu de touchers.

E2E_OUT

L’endroit où un test de bout en bout écrit ses captures et ses rapports.

E2E_WEIGHT_DEBUG

Toute valeur fait afficher à e2e:weight les requêtes qu’il a comptées.

GH_TOKEN

Le jeton GitHub de la commande gh. tools/release/run-jobs.mjs la lit avant GITHUB_TOKEN ; npm run wiki -- publish ne la lit que si GITHUB_TOKEN n’est pas posée.

GITHUB_TOKEN

Un jeton GitHub pour les outils de publication et de documentation. npm run wiki -- publish la lit avant GH_TOKEN (après la clé de déploiement WIKI_DEPLOY_KEY) ; tools/release/run-jobs.mjs ne la lit que si GH_TOKEN n’est pas posée. Sur un runner, GitHub Actions la donne.

MUTATION_SET

L’ensemble de tests qui juge un mutant (core, reality…) ; core quand elle n’est pas posée. npm run test:mutation:* la pose.

NEEDS

Les résultats des jobs d’un workflow, en JSON, que lit le verdict du candidat. Le workflow la pose.

QUALIFY_APP

Posée par npm run ops:qualify pour ops/qualify/compose.yml : l’arbre commité que lit le worker des speedruns.

QUALIFY_BUILD

Posée par npm run ops:qualify pour ops/qualify/compose.yml : le dossier du contexte de construction de l’image du Bridge.

QUALIFY_DATA

Posée par npm run ops:qualify pour ops/qualify/compose.yml : le dossier des données des deux tenants.

QUALIFY_GID

Posée par npm run ops:qualify pour ops/qualify/compose.yml : l’identifiant de groupe des conteneurs (1000 par défaut).

QUALIFY_MODULES

Posée par npm run ops:qualify pour ops/qualify/compose.yml : les modules installés montés à côté.

QUALIFY_PORT

Posée par npm run ops:qualify pour ops/qualify/compose.yml : le port local du proxy (8443 par défaut).

QUALIFY_PORT_1

Posée par npm run ops:qualify pour ops/qualify/compose.yml : le deuxième port local du proxy (8444 par défaut).

QUALIFY_PORT_2

Posée par npm run ops:qualify pour ops/qualify/compose.yml : le troisième port local du proxy (8445 par défaut).

QUALIFY_PORT_3

Posée par npm run ops:qualify pour ops/qualify/compose.yml : le quatrième port local du proxy (8446 par défaut).

QUALIFY_SECRETS

Posée par npm run ops:qualify pour ops/qualify/compose.yml : le dossier du mot de passe de la base et de l’URL du stockage.

QUALIFY_UID

Posée par npm run ops:qualify pour ops/qualify/compose.yml : l’identifiant d’utilisateur des conteneurs (1000 par défaut).

SHIP_PIDS

Le dossier où npm run ship écrit ses identifiants de processus ; .cache/pids quand elle n’est pas posée.

SHIP_TRAILERS

Des lignes de pied supplémentaires que npm run ship ajoute à un commit de fusion, après Agent: Claude.

STUDIO_TEST_S3

Le point d’accès S3, les identifiants et le bucket du stockage objet de la CI, en une URL, pour les tests du Studio hébergé.

WEB_SCUMM_REPO

Le dépôt GitHub sur lequel travaillent les outils de publication ; wanoo/quest-n-click quand elle n’est pas posée.

WIKI_DEPLOY_KEY

La clé de déploiement SSH qui pousse la documentation vers le wiki GitHub (npm run wiki -- publish) ; GITHUB_TOKEN sert sans elle.

Posées par le système, npm ou GitHub Actions

Personne ne les pose à la main : le système, npm, Vitest ou un runner GitHub s’en charge. Le code se contente de les lire.

GITHUB_ACTIONS

true sur un runner GitHub : les tests et les cliquets adaptent leur sortie et leurs limites.

GITHUB_API_URL

L’adresse de l’API GitHub sur un runner.

GITHUB_ENV

Le fichier auquel une étape ajoute des lignes NOM=valeur, pour les étapes suivantes de son job.

GITHUB_OUTPUT

Le fichier où une étape écrit ses sorties.

GITHUB_STEP_SUMMARY

Le fichier où un job écrit son résumé ; npm run ci:plan y écrit le plan.

HOME

Le dossier personnel de l’utilisateur. Le script de la chaîne A7 le refuse comme dossier de sortie ; le Studio Server donne à ses propres commandes git un HOME dans son dossier de travail, jamais le vôtre.

ImageOS

L’image du runner, notée à côté d’une mesure.

PATH

Le chemin de recherche du système. Le Studio Server et le worker la passent à leurs processus enfants, et rien d’autre de l’environnement.

PWD

Le dossier courant du shell.

RUNNER_OS

Le système du runner, noté à côté d’une mesure.

SystemRoot

Le dossier de Windows ; les outils y trouvent tar.exe.

VITEST

Posée pendant que Vitest tourne : le plugin du Studio local ne lance alors rien.

npm_lifecycle_event

Le script npm en cours ; un outil qui écrit le jeu l’enregistre comme auteur du changement.

Dans les workflows de CI

Posées et lues seulement par les workflows de .github/workflows/ : une entrée passée au shell d’une étape par env:, ou une valeur qu’une étape laisse à la suivante dans $GITHUB_ENV. Rien à poser à la main.

ALL

ci : true quand tous les contrôles tournent (un push, ou une pull request étiquetée full-ci).

ARCHIVE

docs-publish : le chemin de l’archive à publier.

ARCHIVE_SHA

docs-publish : le sha256 de cette archive.

CALLED

docs-publish : true quand release.yml l’appelle, avec une archive vérifiée.

CANDIDATE

docs-publish : le lancement candidat dont le rapport de tests est lu.

DISPATCHED_MODE

docs-publish : le mode choisi à la main (revision, rollback, promote, preview).

DOCS_ARCHIVE

release : l’archive de documentation de la version, quand elle en a une.

EXTRA_ASSETS

release : les autres fichiers déposés avec la version.

FILE

mutation : un seul fichier à muter, choisi à la main.

FULL

ci : false dans un lancement Pages seulement, qui saute alors ses autres étapes.

IN_CANDIDATE

docs-publish : le lancement candidat que passe release.yml.

IN_REVISION

docs-publish : la révision de documentation que passe release.yml (r1).

IN_SHA

docs-publish : le commit du tag que passe release.yml.

IN_SHA256

docs-publish : le sha256 de l’archive vérifiée par ship verify.

IN_TAG

docs-publish : le tag de version que passe release.yml.

MODE

docs-publish : le mode décidé pour le lancement, laissé aux étapes suivantes.

MUTATION

ci : true quand une pull request étiquetée full-ci lance aussi les tests de mutation.

NPM_PUBLISH_NODE

release : la version de Node.js sur laquelle tourne la publication npm.

NPM_PUBLISH_NPM

release : la version de npm qui publie.

P

release : le préfixe des noms de fichiers de la version (quest-n-click).

PAGES_ONLY

ci : true pour un lancement Pages seulement, qui reconstruit le site et /docs/ et rien d’autre.

POSTGRES_DB

La base du conteneur de service PostgreSQL.

POSTGRES_PASSWORD

Le mot de passe du conteneur de service PostgreSQL, pour la CI seulement.

POSTGRES_USER

L’utilisateur du conteneur de service PostgreSQL, lu par son image.

PRODUCT_TAG

docs-publish : le tag du produit que décrit la documentation.

PROFILE

candidate : le profil du test de déploiement, full lancé à la main, short sinon.

RELEASE_TAG

docs-publish : la version GitHub qui porte l’archive (v<v> ou docs-v<v>-r<n>).

REMIX_ASSETS

release : les fichiers de remix ajoutés à la version, quand il y en a.

REPO

Le dépôt où tourne le workflow (propriétaire/nom), pour ses appels à gh.

REUSED

docs-publish : true quand une version déjà créée par un lancement précédent est réutilisée.

REVISION

docs-publish : la révision de documentation publiée (r1, r2…).

RUN

ci : si le plan demande les jobs Reality.

RUN_ID

docs-publish : l’identifiant de ce lancement, l’identifiant de construction de l’archive.

RUN_REF

docs-publish : la ref sur laquelle tourne le lancement, vérifiée selon son mode.

SET

mutation : l’ensemble de mutation choisi à la main.

SHA

release : le commit qu’a testé le lancement candidat.

STORE

candidate : le stockage que mesure tools/backup-memory.ts, sqlite ou une URL PostgreSQL.

STUDIO_TEST_CAPTURES

ci : 1 garde les captures du test du Studio hébergé.

STUDIO_TEST_KEYCLOAK

ci : le service Keycloak avec lequel se connecte le test de bout en bout du Studio hébergé.

STUDIO_TEST_KEYCLOAK_ADMIN

ci : l’administrateur de ce Keycloak, pour la CI seulement.

STUDIO_TEST_PG_URL

ci : le service PostgreSQL qu’utilisent les tests du Studio hébergé.

TAG

release : le tag publié.

TARGET

docs-publish : le <version>[-r<n>] que vise un retour arrière ou une promotion.

VERSION

docs-publish : la version du produit à publier (son entrée version).

WANT

candidate : le SHA complet qu’un lancement à la main doit tester (son entrée sha).

Modifier la source de cette page · Signaler une erreur

Generated publication · publication générée — current documentation · documentation courante: quest'n'click 4.4.0 r1, documentation revision · révision de la documentation 8dc717c69acb62c4742b69c54a7e7dfb620f75d8. Earlier versions and permalinks · versions précédentes et liens permanents: https://wanoo.github.io/quest-n-click/docs/ An edit made in this wiki is overwritten at the next publication · une modification faite dans ce wiki est écrasée à la publication suivante. Edit the source · Modifier la source · Report an error · Signaler une erreur

Accueil

Index (6)
Démarrer (6)
Jouer (9)
Installer (17)
Créer un jeu (55)
Moteur (4)
Studio local (24)
Studio d'équipe (21)
Clever Cloud (23)
Reality Bridge et connecteurs (16)
Contribuer (25)
Référence (7)

Clone this wiki locally