Seed sur staging

Actions → Seed staging (manual) → Run workflow. Le workflow est staging uniquement. Il valide les mêmes entrées que la CLI, lit DATABASE_URL et le certificat CA depuis Scaleway Secret Manager, et publie les credentials plus le seed résolu dans le résumé du run. En ligne de commande avec gh :

gh workflow run staging-seed.yml \
  -f command=account -f email=demo@akord-securite.fr \
  -f source=archetype -f archetype=hotel -f size=m \
  -f clear=false -f dry_run=false -f assets=upload

gh run watch "$(gh run list --workflow=staging-seed.yml --limit=1 --json databaseId -q '.[0].databaseId')"

Pas de groupe de concurrency : GitHub ne garde qu’un run en attente par groupe et annulerait les autres. Les seeds peuvent tourner en parallèle — le seeder prend un verrou d’avis Postgres par organisation, donc deux écritures sur le même tenant attendent au lieu d’être tuées.

Nouveau compte généré

Entrée	Valeur
`command`	`account`
`email`	la connexion à créer
`source`	`archetype`
`archetype`	`hotel`, `centre_commercial`, `ehpad`, `logistique`, `bureaux`, `etablissement_scolaire`
`size`	`s`, `m` ou `l`
`dry_run`	`false`
`assets`	`upload`

Le résumé du run affiche le mot de passe, l’id d’organisation et le seed.

Nouveau compte de démonstration

source=blueprint et blueprint=<nom> (un dossier de apps/api/src/seed/demo). Le compte est alors identique à chaque run, PDF compris.

Remettre une organisation à zéro

Dry run

command=reset, dry_run=true, plus la source. Le résumé affiche le plan résolu et les compteurs de suppression, sans rien écrire, et donne l’id d’organisation exact.

Rejouer avec l'id

Même run avec dry_run=false et confirm_organization_id=<UUID affiché>.

reset supprime les données du tenant staging. Il préserve la connexion ciblée, l’organisation, le propriétaire structurel et les rôles système. Sans confirm_organization_id exact, le run échoue.

Toutes les entrées

Entrée	Requis	Défaut	Rôle
`command`	oui	—	`account` (nouvelle organisation) ou `reset` (organisation existante)
`email`	oui	—	connexion à créer, ou connexion propriétaire de l’organisation à remettre à zéro
`source`	oui	`archetype`	`archetype` (généré) ou `blueprint` (écrit à la main)
`archetype`	non	`hotel`	avec `source=archetype`
`size`	non	`s`	avec `source=archetype`
`blueprint`	non	—	avec `source=blueprint`, nom du dossier sous `apps/api/src/seed/demo`
`name`	non	partie locale de l’e-mail	nom affiché (`account`)
`org_name`	non	nom du blueprint	nom de l’organisation
`org`	non	résolu depuis `email`	UUID exact de l’organisation (`reset`)
`seed`	non	généré et affiché	entier pour un contenu reproductible
`as_of`	non	aujourd’hui	ancre d’horloge `YYYY-MM-DD`, en UTC
`e2e`	non	`false`	overlay de couverture, `source=archetype` uniquement
`confirm_organization_id`	non	—	requis avec `reset` hors dry run : l’UUID exact affiché
`dry_run`	oui	`false`	affiche le plan résolu sans écrire
`assets`	oui	`upload`	`upload` (fichiers réels) ou `none` (smoke DB seule)

Le job ne définit que DATABASE_URL et DATABASE_CA_CERT ; toutes les autres variables sont des placeholders inatteignables. Pointer l’une des deux ailleurs que sur la base staging écrirait dans cette autre base.

Une taille l est un long enchaînement d’insertions séquentielles contre une base distante : le job a un budget de 300 minutes, prévoir des heures et non des minutes.

Onboarding

Architecture

DevOps

Module

Nouveau compte généré

Nouveau compte de démonstration

Remettre une organisation à zéro

Toutes les entrées

​Nouveau compte généré

​Nouveau compte de démonstration

​Remettre une organisation à zéro

​Toutes les entrées

Nouveau compte généré

Nouveau compte de démonstration

Remettre une organisation à zéro

Toutes les entrées