ÉpingléCatalogue d’équipement

il y a 45 j

La synchronisation nocturne des données Warframe

Framelab · Équipe

Équipement, la Forge, les palettes Fashion, Helminth, les ennemis du Lab mission et la plupart des icônes d’objets sont reconstruits depuis wiki.warframe.com. Les textures préfèrent l’export public Digital Extremes quand un objet a un uniqueName Lotus ; le wiki complète les icônes d’aptitudes et le reste. Les images vont sur Cloudflare R2 derrière un Worker CDN signé, et le JSON du catalogue est publié sur le site live.

Warframe change souvent, qu’il s’agisse des armes, des mods, des Primes, des textes de capacités, des ennemis du Lab, des palettes, de l’Incarnon ou des armes exaltées. La synchronisation depuis le wiki public (et les textures DE) garde Framelab à jour sans recopier des milliers de lignes à la main après chaque mise à jour.

Quand elle tourne

Chaque nuit vers 00:00 UTC, un job automatique sonde les tampons des modules wiki et le pin DE PublicExport. Si les deux correspondent déjà à ce que nous avons publié, la reconstruction est sautée — pas d’envoi catalogue ni d’images. Quand nous déclenchons une sync à la main (workflow_dispatch ou sommeil FORCE_CATALOG_SYNC), une synchronisation complète tourne toujours.

Même les nuits wiki+DE calmes, un job léger rafraîchit encore la carte id→nom Overframe utilisée par Capture, pour que les nouveaux mods Primed restent résolus sans JSON édité à la main. Comment Capture s’en sert, du clic Importer jusqu’au placement en Forge : Comment fonctionnent l’import Overframe et la sync des ids.

Le job tourne hors du site live. Framelab reste en ligne pendant que les nouvelles données catalogue et images sont publiées sur notre CDN. Nous n’ouvrons pas de page de maintenance pour cette sync nocturne habituelle.

Le mode sommeil (courte page « Framelab dort ») est séparé et rare — seulement pour une reconstruction lourde sur serveur. Le sommeil rejoue toujours les ids Overframe, puis le même pipeline wiki+DE+WFCD si le catalogue doit être rafraîchi.

Le pipeline

wiki.warframe.com  +  content.warframe.com (ExportManifest)
        │
        ▼
  Sync id→nom Overframe (chaque nuit / chaque sommeil)
        │
        ▼
  Probe fraîcheur wiki + DE + WFCD (rebuild sauté si tout est inchangé)
        │
        ▼
  Reconstruction du catalogue (JSON)   ← seulement si nécessaire ou forcé
        │
        ├─ Texture DE par uniqueName si disponible
        ├─ sinon wiki imageinfo (avec redirections)
        ├─ déjà sur R2 ? → pas de téléchargement
        └─ manquante → télécharger → envoyer sur R2 → supprimer en local
        │
        ▼
  Fetch du pack UI Framelab (cadres de mods, polarités, icônes de set, shards)
        │  déjà sur R2 ? → ignorer
        │  sinon wiki (ou URL Framelab) → public/ → envoi avec les assets
        │
        ▼
  Envoi du JSON catalogue vers Cloudflare R2
        │
        ▼
  Publication du catalogue mis à jour (site resté en ligne)

Trois emplacements comptent après une synchronisation.

Quoi Où Rôle
Données catalogue Site live + CDN Cloudflare Noms, stats, index, mods, Helminth, Lab, liens exaltés, etc.
Images objets et mods R2 Cloudflare via Worker signé Icônes dans l’app ; pas conservées sur le serveur après une sync
Cadres de cartes de mods & polarités R2 (mod-components/, focus-schools/, …) Cadres Forge / viewer ; clés Framelab, remplies depuis le wiki
Fonctions de l’app Mises à jour normales Non touchées par le job data

Étape par étape

1. Ids Overframe (toujours)

Capture importe les builds Overframe via des ids numériques de mods. Ces ids ne sont pas dans le wiki. Chaque nuit (et en sommeil) nous tirons les bases items/mods statiques d’Overframe et les fusionnons dans notre carte hors-ligne. Les ids déjà récoltés sont conservés ; le nom le plus long gagne. Les trous encore absents de la base statique Overframe attendront la sync suivante ou une récolte Capture.

2. Probe wiki + DE + WFCD (nuits calmes sautées)

Le job planifié compare touched/lastrevid des modules MediaWiki, l’entrée d’index DE ExportManifest, et le dernier commit WFCD warframe-items sur data/json aux pins commités (wiki-freshness.json, de-freshness.json, wfcd-freshness.json). Les nuits inchangées sautent reconstruction et envoi — elles ont quand même synchronisé la carte Overframe.

Module:Missions/data est dans le pin wiki pour que les changements MissionTable reconstruisent les tips farm craft.

3. Reconstruire depuis le wiki (+ textures DE)

Le pipeline de build, simplifié :

  1. Miroir des modules Lua du wiki dont nous dépendons
  2. Application des overrides curatés Framelab, pour ce que le wiki n’encode pas comme nous en avons besoin (par ex. Arquebex→Voidrig si Users manque)
  3. Bundles des items, mods, arcanes, cosmétiques Fashion, Helminth, liens d’armes exaltées, conflits de mods, armes modulaires, Incarnon, palettes et ennemis du Lab
  4. Enrichissement des cartes de navigation et comblement des manques
  5. Build recipes + resource-farm depuis WFCD, puis tips wiki #Farming_Locations quand les drops officiels sont vides
  6. Sync DE ExportManifest, puis téléchargement uniquement des images absentes de R2 (DE d’abord, wiki en secours)
  7. Fetch du pack UI Framelab (section suivante) pour toute clé encore absente de R2
  8. Écriture de manifest.json et validation des bundles

Les liens exaltés viennent des armes wiki en Class = Exalted Weapon (et griffes type Garuda présentes dans le catalogue exalté) plus leur champ Users. Les exaltées Warframe restent sur les frames (Glory→Jade). Les exaltées Necramech restent sur les mechs (Arquebex→Voidrig, Ironbride→Bonewidow). Le bruit non exalté comme Mausolon est retiré des tableaux exalted. Voir aussi les loadouts Necramech.

Les faits de jeu viennent du wiki. Les binaires livrés vivent sur Cloudflare R2 ; le Worker assets signe des URL courtes pour garder le bucket privé.

4. Les images, en incrémental

Pour chaque image référencée par le nouveau catalogue :

  1. Lister les clés déjà présentes sous notre préfixe R2 images.
  2. Déjà dans le bucket, donc pas de téléchargement, et suppression de toute copie locale restante.
  3. Manquante, donc résoudre une URL (texture DE par uniqueName, sinon wiki imageinfo), télécharger, envoyer sur R2, puis supprimer du disque.

Une nuit normale vérifie le bucket et ne télécharge que les nouvelles icônes. Elle ne re-télécharge pas tout le set d’art.

public/warframe/images/ n’est que du staging. Il est gitignoré et vidé avant la fin du runner ; la production ne sert pas ces fichiers depuis le checkout GitHub.

5. Pack UI Framelab (cartes de mods, polarités, shards)

Les icônes d’objets et les cadres de cartes de mods sont des jobs distincts. Les images catalogue suivent DE/uniqueName et wiki imageinfo pour chaque ligne Équipement. Le pack UI utilise des conventions de chemins Framelab (cadres de rareté sous mod-components/, glyphes de polarité sous focus-schools/, en-têtes de set, symboles de dégâts, tuiles de shards Archon, badges d’emplacement) dans lib/warframe/catalog/ui-pack.ts et ui-assets.ts. Les titres File wiki sont découverts à la sync depuis Module:Polarity (+ images de la page Polarity), la page Rarity (Common→bronze→préfixes Bronze), allimages pour ces préfixes, la recherche SetIcon, et intitle:Symbol.png pour les glyphes de dégâts — sans listes Impact/Heat/… éditées à la main. Les clés destinées à l’app restent liées à getModAssetUrl / allowlists de polarité.

Ce qui clochait avant : upload-assets pouvait supprimer le pack UI local après un envoi, mais rien dans le pipeline nocturne ne re-téléchargeait ces clés. Si R2 ne les avait jamais eues (ou qu’elles avaient été effacées), les cadres de mods et polarités de la Forge restaient en 404 même quand les icônes d’objets allaient bien.

Comment Framelab synchronise le pack UI maintenant :

  1. fetch-ui-pack découvre les candidats wiki, puis liste R2 sous mod-components/, focus-schools/, mod-set-icons/, icons/, img/ et ui/.
  2. Les clés déjà sur R2 sont ignorées.
  3. Les clés manquantes se résolvent depuis le wiki public (titres File découverts → dests Framelab, p. ex. wiki *SetIcon.png → *Header*.png) ou depuis des URL Framelab directes pour shards / badges d’emplacement.
  4. Les fichiers arrivent sous public/ (staging gitignoré), puis upload-assets les pousse vers R2 et peut nettoyer le local.
  5. Les clés requises du pack UI (cadres de mods + polarités) font échouer le job s’il en manque encore après le fetch — nous ne livrons pas un bucket à moitié vide en silence.

Les opérateurs peuvent aussi lancer le pack UI seul : pnpm framelab data run fetch-ui-pack, puis pnpm framelab data upload.

6. Envoyer le JSON catalogue vers R2

Le même job pousse les bundles JSON publiés vers R2 pour aligner les chemins CDN et edge avec git. Le JSON reste aussi dans le dépôt afin que les déploiements et le pnpm local puissent lire le catalogue sans tirer chaque objet du bucket.

7. Publier sur le site live

Quand le catalogue a vraiment changé, le job publie les nouvelles données pour que le site live et le CDN servent le nouvel index, les stats et les icônes. Le code de l’app n’est jamais réécrit par ce job.

8. Ce que vous voyez ensuite

Après publication, votre visite suivante charge le nouvel index, les stats et les icônes. Les icônes se chargent toujours progressivement au défilement, comme décrit dans la note sur le chargement des icônes.

Ce que vous pouvez remarquer

  • Pas de coupure nocturne habituelle en production — la sync tourne hors app pendant que Framelab sert les pages.
  • De nouvelles entrées Équipement, textes, chiffres du Lab ou liens exaltés après un patch Warframe, en général lors de la prochaine nuit qui synchronise réellement plutôt qu’immédiatement.
  • Capture qui reste à jour sur les nouveaux ids Overframe même après une nuit wiki calme, parce que cette carte a quand même été rafraîchie.
  • De nouvelles icônes qui apparaissent pour la première fois, celles qui manquaient à R2.
  • Les icônes existantes qui restent rapides, parce qu’elles étaient déjà sur le CDN et ont été ignorées.
  • Des icônes qui suivent les mises à jour de textures DE même si les modules Lua wiki n’ont pas changé cette nuit-là.
  • Des cadres de mods et polarités qui se rétablissent à la sync suivante après un trou de pack UI, parce que le fetch du pack UI fait partie du même pipeline.

Ce qui n’est pas synchronisé ainsi

  • Vos builds, looks Fashion, commentaires, votes Arène et données de compte. Tout cela vit dans notre base de données, pas dans le job wiki.
  • Les éléments d’interface ponctuels hors pipeline catalogue Warframe.
  • Les correctifs manuels parfois appliqués au contenu curaté quand le wiki est faux ou incomplet. Ils passent par la même étape d’overrides du build.
  • Avatars et cadres de profil (cosmétiques) — chemin d’upload séparé, pas le job Équipement nocturne.

Si quelque chose ne va pas

  • Un catalogue clairement bloqué sur d’anciennes données le lendemain d’une grosse mise à jour, via Feedback avec le nom de l’objet.
  • Une icône cassée en permanence après plusieurs secondes, via Feedback avec le nom de l’objet ou du mod. Il s’agit d’un vrai défaut, pas du bref clignotement au défilement.
  • Cadres de mods ou polarités vides alors que les icônes d’objets chargent encore — Feedback avec « cadres de mods » ; la prochaine sync forcée doit remplir R2 depuis le wiki via fetch-ui-pack.
  • Un import Capture qui manque un mod Primed tout nouveau le jour même de son apparition sur Overframe, via Feedback — la sync d’ids de la nuit suivante le rattrape en général.
  • Un site bloqué sur la page de maintenance Framelab dort pendant une reconstruction lourde, via Feedback. Elle doit se lever à la fin du travail, ou au plus tard en environ 45 minutes.

Framelab