quest'n'click 4.5.0 · r1

Construite pour quest'n'click 4.5.0, révision r1. Si elle est publiée, et laquelle est la courante, est dit par publication.json.

L'essayer en local avec compose.yml

English · Type : tutoriel · Public : administrateur · Contexte : Studio hébergé · Statut : prête · S'applique depuis : 4.2.3

Le Studio Server (Studio d'équipe hébergé) · contrat : expérimental · vérifié par la CI (matrice de support de la 4.4.0, 2026-10-23) : Postgres, S3 et Keycloak en CI ; Chromium et Firefox (job studio-hosted) ; WebKit sous macOS, à la main seulement · vérifications automatiques : jobs studio-hosted, studio-install-smoke ; plan de CI studioHosted ; 3 fichiers de tests · passes humaines : studio-hosted pas faite (#149), studio-collab pas faite (#150), studio-preview pas faite (#166), studio-assets-hosted pas faite (#167), studio-mcp-remote pas faite (#196), studio-oidc-generic pas faite (#197) · limites connues : no-oidc-mode, compose-not-verified

Vous voulez voir le Studio Server fonctionner avant de l'héberger. En dix minutes, sur votre machine, vous allez le lancer dans son mode le plus simple (sans connexion, avec SQLite et un dossier), importer un jeu, écrire par son API, regarder le journal, et réexporter le jeu. Ensuite, vous verrez ce qu'apporte ops/studio/compose.yml pour essayer le mode équipe complet.

Ce que vous allez faire

Un Studio Server sur 127.0.0.1:8787 qui tient un jeu à la révision 1, puis 2 après votre première écriture, et un dossier avec ce jeu exporté à sa tête. Chaque étape affiche quelque chose que vous pouvez vérifier.

Ce qu'il vous faut

Étapes

  1. Écrivez une configuration sans oidc : le serveur est alors le serveur local, sur la boucle locale seulement, avec SQLite et un dossier pour les contenus. Enregistrez-la sous /tmp/studio-try/studio.config.json :

    {
  "publicUrl": "http://127.0.0.1:8787",
  "playUrl": "http://127.0.0.1:8788",
  "game": "template",
  "workDir": "/tmp/studio-try/work",
  "host": "127.0.0.1",
  "port": 8787,
  "store": { "kind": "sqlite", "file": "/tmp/studio-try/work/journal.sqlite" },
  "blobs": { "kind": "fs", "dir": "/tmp/studio-try/work/blobs" }
}

    playUrl doit être une autre origine que publicUrl, même ici. Créez ensuite le dossier :

    # n'importe où
mkdir -p /tmp/studio-try/work

  1. Importez un jeu.

    # dans le dépôt du moteur
npm run studio-server -- import games/_template --config /tmp/studio-try/studio.config.json

    Vous voyez {"event":"imported","game":"template","revision":1}.

  1. Démarrez le serveur (il reste au premier plan ; prenez un second terminal pour la suite) :

    # dans le dépôt du moteur
npm run studio-server -- serve --config /tmp/studio-try/studio.config.json

    Vous voyez {"event":"lease-taken",…} puis {"event":"listening","host":"127.0.0.1","port":8787,…}.

  1. Demandez-lui comment il va.

    # n'importe où sur la machine
curl http://127.0.0.1:8787/readyz
curl http://127.0.0.1:8787/api/revision

    Vous voyez {"ok":true,"writes":"served"} (cette instance sert les écritures) et {"epoch":"…","revision":1}.

  1. Écrivez par l'API, avec un identifiant d'opération, deux fois :

    # n'importe où sur la machine
curl -i -X POST -H 'content-type: application/json' -H 'x-studio-op: try-local-0001' \
  -d '{"text":"hello from curl"}' http://127.0.0.1:8787/api/notes
curl -i -X POST -H 'content-type: application/json' -H 'x-studio-op: try-local-0001' \
  -d '{"text":"hello from curl"}' http://127.0.0.1:8787/api/notes

    Vous voyez la première réponse avec x-studio-revision: 2 ; la seconde, la même réponse avec x-studio-replayed: 1 : l'écriture n'a été appliquée qu'une fois.

  1. Lisez le journal et le diff.

    # n'importe où sur la machine
curl "http://127.0.0.1:8787/api/ops?after=1"
curl http://127.0.0.1:8787/api/diff/1..2

    Vous voyez l'opération 2 qui écrit notes.json, et le diff qui nomme les champs de la note ajoutés.

  1. Arrêtez le serveur avec Ctrl+C dans son terminal. Vous voyez {"event":"stopping","signal":"SIGINT"}.

  1. Exportez le jeu à sa tête :

    # dans le dépôt du moteur
npm run studio-server -- export /tmp/studio-try/exported --config /tmp/studio-try/studio.config.json

    Vous voyez {"event":"exported","revision":2,"files":…}, et /tmp/studio-try/exported/export-manifest.json avec l'empreinte de chaque fichier. Supprimez /tmp/studio-try quand vous avez fini.

Limite · no-oidc-mode Sans OIDC, il n'y a ni connexion, ni membre, ni rôle : tout ce qui atteint la boucle locale écrit. C'est pourquoi le serveur refuse toute autre adresse que la boucle locale. Il n'y a ni pans, ni baux, ni commentaires, ni aperçus, ni builds publiés (ils demandent un Studio d'équipe), et la page du Studio dans le navigateur demande une connexion que ce mode n'a pas : utilisez l'API ici, et npm run studio pour un Studio local dans le navigateur.

Le mode équipe complet avec compose.yml

ops/studio/compose.yml démarre, sur la boucle locale seulement, Postgres (127.0.0.1:55432, utilisateur studio), MinIO, un stockage S3 (127.0.0.1:59000), et Keycloak (127.0.0.1:58080) avec le realm de test web-scumm et un utilisateur de test, lea@example.org, mot de passe lea-local-only, email vérifié :

# dans le dépôt du moteur
docker compose -f ops/studio/compose.yml up -d

C'est un point de départ, pas une installation clé en main. Par-dessus, il faut encore :

Limite · compose-not-verified Ce mode local complet n'est pas exercé de bout en bout par les tests du projet : l'e2e hébergé de la CI lance le serveur avec un fournisseur de test dans son propre processus. Les navigateurs gardent inégalement les cookies Secure en http sur la boucle locale (WebKit n'en garde aucun) ; l'e2e sert Firefox et WebKit en https avec un certificat fait pour l'occasion. Le déploiement de référence est Clever Cloud : voir Premier déploiement.

Ce que vous avez appris

Pour aller plus loin

Modifier la source de cette page · Signaler une erreur