Skip to content

Latest commit

 

History

History
75 lines (46 loc) · 4.12 KB

File metadata and controls

75 lines (46 loc) · 4.12 KB

Installation et maintenance

Utilisateurs Nuvio

Choisissez le manifest adapté :

  • général — VF, VOSTFR, VO et autres langues : https://raw.githubusercontent.com/niakw/NiakVIO/refs/heads/main/manifest.json ;
  • francophone — VF/VOSTFR : https://raw.githubusercontent.com/niakw/NiakVIO/refs/heads/main/vf/manifest.json ;
  • général sans providers orientés anime : https://raw.githubusercontent.com/niakw/NiakVIO/refs/heads/main/no-anime/manifest.json ;
  • francophone sans providers orientés anime : https://raw.githubusercontent.com/niakw/NiakVIO/refs/heads/main/vf-no-anime/manifest.json.

Dans un client Nuvio compatible :

  1. ouvrir la gestion des plugins/providers ;
  2. ajouter/importer l'URL voulue ;
  3. actualiser le repository.

Les URL restent stables. Les versions, bundles, domaines et états d'activation évoluent derrière elles.

Mainteneurs

Prérequis : Node.js 24+ et Python 3.12 recommandé.

Installation reproductible :

npm ci --ignore-scripts --no-audit --no-fund

Validation locale minimale :

npm test
node engine_v2/tests/provider-catalog.test.mjs

Diagnostics :

npm run diagnostics

Publication

Il n'existe qu'un orchestrateur de production : Niakvio provider pipeline (.github/workflows/sync.yml).

Il expose deux profondeurs :

  • quick : maintenance courante, repair-first, capable de publier une amélioration prouvée sans attendre Deep ;
  • deep : reconstruction et preuve large pour changements structurels, nouvelles intégrations et apprentissage/persistance des recipes.

Ne modifiez pas manuellement manifest.json et vf/manifest.json comme deux sources autonomes. La source publiée canonique est provider_catalog.json ; les manifests sont des projections rendues et revalidées depuis ce catalogue dans la transaction de publication.

Le pipeline régénère également les versions, projections de langue, provenance, LKG et empreintes (FILE-HASHES.json, SHA256SUMS.json, PATCH-SHA256SUMS.txt) avant un commit atomique. Les bundles providers hashés sont immuables ; leur historique suit une rétention glissante de 10 générations par provider, sans supprimer une génération encore référencée par un manifest, le LKG ou la provenance publiée.

Vérification runtime

Une modification du chemin de playback partagé doit être suivie des preuves natives appropriées :

  • NuvioTV / Android TV + Nuvio Mobile Android : .github/workflows/native-mobile-android-reader.yml ;
  • Nuvio Mobile iOS : .github/workflows/native-mobile-ios-reader.yml ;
  • Nuvio Desktop macOS/Windows : .github/workflows/native-desktop-reader-acceptance.yml ;
  • corpus natif ciblé : .github/workflows/native-corpus-device-targeted.yml.

Le corpus de référence est versionné dans .github/triggers/nuvio-client-lab.json. Le Lab standard utilise au maximum une fixture film, une fixture série et une fixture anime par provider selon ses types déclarés ; les autres œuvres restent disponibles pour les diagnostics ciblés. Les Labs utilisent les dépôts clients Nuvio officiels uniquement comme baselines de lecture : NiakVIO ne modifie pas ces dépôts. Les preuves natives lourdes s'exécutent sur main ou manuellement et ne constituent pas un verrou de publication.

Maintenance GitHub Actions

.github/workflows/purge-actions-history.yml effectue chaque semaine une maintenance automatique : les runs terminés de plus de 7 jours sont supprimés avec leurs artifacts. Le workflow conserve aussi un mode manuel pour une purge ponctuelle des logs seuls ou des runs complets.

Les artifacts temporaires des Labs natifs sont conservés 1 jour. Le cache Gradle est désactivé sur les Labs natifs afin de préserver le quota de cache GitHub Actions ; les snapshots AVD TV/Mobile restent conservés lorsqu'ils apportent un gain de démarrage significatif.

Règle de maintenance

Une correction générique appartient à ARCHI 2. Les scripts historiques encore présents ne sont que des primitives de compatibilité derrière le plan de contrôle V2 ; ils ne doivent pas recréer un second pipeline, un second manifest canonique ou une politique d'activation concurrente.