Pas seulement sur master, sur toutes les branches à tous les commits pushés.
Je ne sais pas, j’ai fait ce qu’il me semblait le plus simple, si vous avez des suggestions pour simplifier tout ça, vous pouvez porposer, mais ça ne me semble pas prioritaire. Bootstrapper un réseau reste une tache de mainteneur uniquement, donc il ne fait mettre trop d’énergie à essayer de la rendre plus “accessible”.
Sur dockerhub sur le compte duniterteam. Mais je ne sais pas ce que tu veux voir exactement.
Les dockerfile sont tous dans le dossier docker/ du dépôt, il n’y en a que 2.
Un client n’est jamais sans runtime, c’est impossible. Tout client contient à minima 1 runtime “natif” pour chaque type de runtime (gdev/gtest/g1 selon rust features activées).
Un client peut en plus contenir des embedded raw specs, qui contiennent alors le bytecode d’un ou plusieurs runtime(s).
Toutes les images docker contiennent le client, donc un seul fichier binaire, qui embarque toujours au moins un runtime “natif”, et éventuellement d’autres runtimes selon le code compilé.
Via le call RPC author_rotateKeys sru l’api RPC privée du nœud, ça peut être fait avec curl, avec un script, via polkadotjs, qu’importe.
Le nom et le tag de l’image docker qu’ils doivent utiliser. cette image docker doit contenir un binaire qui embarque les raw chains spec définitives du nouveau réseau.
Dans le genesis state (qui est inclus dans les raw chain spec).
Avant l’appel aux smiths, il maque une étape: publier un nouveau client (et son image docker) qui embarque les raw chain spec définitives de ce nouveau réseau.